From SRS0=ykDZ=ZB=acm.org=bmoeller@srs.kundenserver.de Tue Apr 1 07:15: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 0EBF51A0737 for ; Tue, 1 Apr 2014 07:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 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, SPF_HELO_PASS=-0.001, 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 HsNXOjzIba07 for ; Tue, 1 Apr 2014 07:14:59 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9131A06BE for ; Tue, 1 Apr 2014 07:14:59 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0MZbAH-1Wlgpc3lJF-00LHCo; Tue, 01 Apr 2014 16:14:54 +0200 Received: by mail-yk0-f169.google.com with SMTP id 142so7611905ykq.0 for ; Tue, 01 Apr 2014 07:14: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=VHhq4MHVQVN3speYE3AdjZgkA+6Y6MUHGj68NEqX4go=; b=LDBt09zGeUnCX7kHSGPru+AqLNUhVVn0IcRZX9VGKAprpLFS/UTOxeorhR3vRGZ+B9 pJTk/AjHNTGRkjWrD9g2qhXANqRowaLjdwiTFDEvyoqfR0bA2Z6NOoKblvV3tUkOMpJZ fCtkZB/7UyOe/d8ZYttlMjHeBRezIQWeSBnpLh+VG8SIJ5T78ZlpsdtGD6A2vBIpP9Zk 3lvRoAT4wLtBKf4L+O2zLiBMIHN/yZ7RkhgPCrGm3/ML7mDptx7eY2Nyhtyiee6NAt7i ZVSBeYSuYr9jR8CcmsSrEmUJRz2ZQdKziY5UJYd644fbbeAtGQ93e4dgLSxztbolT3dj wuWw== MIME-Version: 1.0 X-Received: by 10.236.166.169 with SMTP id g29mr3494579yhl.135.1396361692920; Tue, 01 Apr 2014 07:14:52 -0700 (PDT) Received: by 10.170.78.5 with HTTP; Tue, 1 Apr 2014 07:14:52 -0700 (PDT) In-Reply-To: <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> References: <53397B6F.9050806@mykolab.com> <53397E0C.9000504@mykolab.com> <53397F7C.2060603@mykolab.com> <53398AB3.9090102@gmail.com> <4564B6F0-EAE8-457F-8698-ED929F4DDA01@pahtak.org> Date: Tue, 1 Apr 2014 16:14:52 +0200 Message-ID: From: Bodo Moeller To: Stephen Checkoway Content-Type: multipart/alternative; boundary=20cf303f6cb2af424b04f5fbca80 X-Provags-ID: V02:K0:4RhL8/sNG6Qow9wKeVseGUXvBBbni08C2/ExghgdEZB SckUrIKW5x4SCqxSawadeVDvpOl0+JKEK0pD+eePfuNKsF3b7W e8T3rig0RRSHyjRWJ4aO/MPVwbIhVWqaW7YYHhX7rTMU437CzD +q0uO7q/hpV4vPkkcw5Cr9f40wFKGjvmyDInqx5X7zu59u0rIE U11CE4Dd4KNd5i9oflGz3cwLuY6HGtF/20Ev7WeZD0axj+znee L6h55H8kkmhvfo8KbpL6LRqOV7tVn63zCdgl+7gCbPMY8QiQja d8Gni2/1+646rIKp62XiUFJJ+PZP2dF1DgttW4bpv0kkIH0EII /2Xgp8UjbfASGn+gBL/vI9q0/q+WYMbiBQE08u762F0/Grgde4 2STBbcTqiqdfpYfMJdL2uf6jkkDdPr6jf3kJHT9HzHo3GfSwjv N3n2z Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZkCUZNe_WQcGYiVFftDR5bOIeOs 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 14:21:23 -0000 --20cf303f6cb2af424b04f5fbca80 Content-Type: text/plain; charset=ISO-8859-1 Stephen Checkoway : 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, < > http://tools.ietf.org/html/draft-hoffman-tls-additional-random-ext-01> 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 < > http://tools.ietf.org/html/rfc6358>, that I missed. > I think that's essentially one family of Internet-Drafts, finally resulting in the RFC 6358 framework. A missing link is http://tools.ietf.org/html/draft-solinas-tls-additional-prf-input-01. http://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-input-00 - Rescorla/Salter, 2006 http://tools.ietf.org/html/draft-rescorla-tls-extended-random-02 - Rescorla/Salter, 2009 http://tools.ietf.org/html/draft-solinas-tls-additional-prf-input-01 - Solinas/Hoffman, 2009 http://tools.ietf.org/html/draft-hoffman-tls-additional-random-ext-01 with http://tools.ietf.org/html/rfc6358 - Hoffman, 2010/2012 --20cf303f6cb2af424b04f5fbca80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Step= hen Checkoway <s@pahtak.org>:
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, <http://tools.ietf.org/html/draft-hoffman-tls-additio= nal-random-ext-01> is quite similar.

The idea of adding more random bits seems to have been fairly popular in th= e 2006-2010 timeframe.

There may be more proposals to do this, for example using <http://tools.ietf.org/h= tml/rfc6358>, that I missed.

I t= hink that's essentially one family of Internet-Drafts, finally resultin= g in the RFC 6358 framework. =A0A missing link is http://tools.ietf.o= rg/html/draft-solinas-tls-additional-prf-input-01.

--20cf303f6cb2af424b04f5fbca80-- From nobody Tue Apr 1 10:24: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 9AF4C1A09C1 for ; Tue, 1 Apr 2014 10:24:20 -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 1tQHEw1SM3Xr for ; Tue, 1 Apr 2014 10:24:17 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7A41A09BD for ; Tue, 1 Apr 2014 10:24:17 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B43D450A84; Tue, 1 Apr 2014 13:24:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: Date: Tue, 1 Apr 2014 11:24:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <361499D3-CFC6-45CA-B8F8-03C835DF009E@iii.ca> References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> To: Watson Ladd X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QHaldo_JwnSTlR54C6_0nDOQcSc 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: Tue, 01 Apr 2014 17:24:20 -0000 On Mar 28, 2014, at 7:40 PM, Watson Ladd wrote: > Write one. It's your problem, not mine. Given IETF is a volunteer organization, people that think we should have = a draft on X generally need to get together and write a draft on X. = Asking the people that are happy with draft Y to write on draft on X is = unlikely to get it done.=20 From nobody Tue Apr 1 12:26: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 47E7B1A09DF for ; Tue, 1 Apr 2014 12:26: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 TVgu3cJ-6kP6 for ; Tue, 1 Apr 2014 12:26:17 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB751A09E1 for ; Tue, 1 Apr 2014 12:26:16 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 822482005D10C for ; Tue, 1 Apr 2014 12:26: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=IWDrD44xXgvaIiDMg8oL ZRh/y+s=; b=h/RZ4ggLVBlzIsEF1S8yZYS/QmXTxvTqlTwsa38z1AHKOUdepmLx r+Gm4pf/YbUrLdxz1YKAJyTIRxOebOECsL4YGjhiBhcqfmIl6aKypMpRJrgo/H72 hfcXNxeArIAxKYwpG1KU8HzpxZYQCDQ0k+P4rDJ0iFnNuDPOh3C9AR4= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 3502D2005D10A for ; Tue, 1 Apr 2014 12:26:11 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so8007741wgh.29 for ; Tue, 01 Apr 2014 12:26: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=jfs9Lp+ANi5Ht8VBvdKDk/UmY3FiiMRpWUj9zsUAPwo=; b=URf+jnHCnMVNuDJjZpiORf0S0zZHsmrsDSxhJzRv/oWHWtNAJODEfiSTQsJMkuy3jB kyCMNmlSE/YLibf5VQIcSZ1QtG5sFNKJZ9xhuqZ7qrQ+xxqGEd3BC1F1FJ4DEzjRSIiK wxurZpHT0HrrTers/yet4h+pFAnqseNshzveBgD6/pSucN75uTQGJuHkGc6DMrmM8LUc obDKgy0xbHVu9RwTBvboemej1XYGsJw0cndKOWAvSqCzKL+Kb62TiRB6a7n164j+aFui ij3UiJzSzVH/QdtM+U05HKBtCV93YiliH+9lvu7ODXPvgR3WCLR3V4XC4FRtXPVs080J qk3Q== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr23740542wjq.40.1396380369964; Tue, 01 Apr 2014 12:26:09 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 1 Apr 2014 12:26:09 -0700 (PDT) In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Tue, 1 Apr 2014 14:26:09 -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/Orpe1q-uWoK9TT4UQxcw95h6WTI 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: Tue, 01 Apr 2014 19:26:18 -0000 On Fri, Mar 28, 2014 at 4:49 PM, Watson Ladd wrote: > On Fri, Mar 28, 2014 at 3:53 PM, wrote: >> 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. Also, the server's need to store a password equivalent is troublesome. Nico -- From nobody Tue Apr 1 12: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 D29421A09DF for ; Tue, 1 Apr 2014 12:31:04 -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 0ilikTLSrcAt for ; Tue, 1 Apr 2014 12:31:04 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2562C1A09C0 for ; Tue, 1 Apr 2014 12:31:04 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BD6C9B8072 for ; Tue, 1 Apr 2014 12:31: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=9JbPobrGBZJF14mXYtcW SyDzZ5k=; b=o1HpRYFqWLTqMRjt72o71xZQXxsej2mGpqUYzVR/bDKCuPY2Aw3I +rnoB8ZrSmz7IMYNNMUu47lj5p+xYYOjPd42pi2Qg7Ki7S/zmTO5WqkDwL3Fi0QY b4o69fhqEBYaBo2CnqhDeOUWeq3MDrGtBRokOEirQjcl3mQaRH7ExnQ= 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 7046FB806D for ; Tue, 1 Apr 2014 12:31:00 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so5823086wib.2 for ; Tue, 01 Apr 2014 12:30:59 -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=kjG7uhmETWmERHJlS491ZNdPQCW0Ss8fbsoNSuOyR+Y=; b=Ks8HKudfRpvOCzunotLLY++3/RZu74py1ZoIkrf9QsXXmqri2Vv3bWcul/B0Wj/gOd l2Ecip4WzFX77y0mz7UD0v9VQKloF6snMRJ6Izy5P6XJF6mYq6TiZGZp8lnRkNK5wAf1 3nHq8MytACIv1EgWXlPBmVOfXypaAJ9vExMbmL7C6yjlNjfyilpExyilT1cK2egCDfrl QTh/FV/nAo5M764CkOYiUDlWXFUwp/shIWxcpqYzfGutk5Thn8BAbsgXVjKq3t4lSyNn 0PR+NDql8z2stTb+oYaDZNcu7Oeslp9T+XtJLGSPyfiA8Bh9m9emjvRBMAsejMA7RQEE AhkA== MIME-Version: 1.0 X-Received: by 10.194.191.195 with SMTP id ha3mr14908167wjc.69.1396380659107; Tue, 01 Apr 2014 12:30:59 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 1 Apr 2014 12:30:59 -0700 (PDT) In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Tue, 1 Apr 2014 14:30:59 -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/KCUCGFw5g-FwyWB6IkbVG8UtFJw 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: Tue, 01 Apr 2014 19:31:05 -0000 On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd wrote: > PSK has no security? That's ridiculous: if high-entropy keys are used > it is fairly easy to see it is secure. TLS-PSK did not specify a PBKDF either, so it can't be used with passwords, therefore we might as well assume high-quality keys for TLS-PSK. Therefore you're quite right. Even if the server must store a password-equivalent I'd still want a decent PBKDF to be used for any protocol that derives keying material from passwords! Nico -- From nobody Tue Apr 1 12:35: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 D59431A09AD for ; Tue, 1 Apr 2014 12:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kLlBPgOAHsXU for ; Tue, 1 Apr 2014 12:35:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 937B91A06BC for ; Tue, 1 Apr 2014 12:35:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s31JZdCA007237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Apr 2014 19:35:39 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s31JZdR1029287 for ; Tue, 1 Apr 2014 19:35:39 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from [10.145.239.205] (dhcp-whq-twvpn-1-vpnpool-10-159-156-15.vpn.oracle.com [10.159.156.15]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built Jan 22 2014)) with ESMTPA id <0N3D00G1JAFD2C00@gotmail.us.oracle.com> for tls@ietf.org; Tue, 01 Apr 2014 12:35:38 -0700 (PDT) Date: Tue, 01 Apr 2014 12:35:38 -0700 From: Chris Newman To: tls@ietf.org Message-id: X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M3voNUOek5o6RguVlpeD9tROwNA Subject: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 19:35:45 -0000 Is there a TLS Alert type that can be used by a TLS server to reject a TLS client connection based on a per-IP-address connection limit? The idea would be to have the server reject the connection before spending cycles on the TLS negotiation. But it's important to inform the client why the connection is rejected in order to reduce the number and severity of support calls that might be generated by such a limit if the connections were silently dropped. Another case that's interesting is when the server is temporarily overloaded and wants to reserve CPU cycles for existing connections rather than spending cycles accepting new connections. Again, it's desirable to indicate to the client the cause of this connection failure in an attempt to reduce the number and severity of support calls and also desirable not to spend unnecessary server time on the TLS negotiation. With the STARTTLS model, applications could just reject at the banner with a text error message. But with the separate-port-for-TLS model, this needs to be done in the TLS layer. I didn't see appropriate alerts in RFC 5246 section 7.2. Could alerts for these two cases be added as an extension or a TLS 1.3 feature? - Chris From nobody Tue Apr 1 12:57: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 866781A0A0E for ; Tue, 1 Apr 2014 12:57: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 ujvzS68imPZV for ; Tue, 1 Apr 2014 12:57:47 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E44151A09E2 for ; Tue, 1 Apr 2014 12:57:45 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 64ABA2005D107 for ; Tue, 1 Apr 2014 12:57:42 -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=rsy5A4A1TOKv47Wb6Wrs xYBjvOk=; b=CsUgJj3YV+oh10kVGFfNp+VnLd3BjrkC5RW+iJKHLc6/f4r9z8oH 5T7QAYbBUbwqOIpl1fZEcShtd4zdm85XNT5sJwLd/yKR9mDai2yAcLDklnLnKXNE BSIs8TsoksA+WOBO1XYsYsqeyXmQGLiFo7RzSsSXRKYObgexI4OGDts= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 1A0672005D100 for ; Tue, 1 Apr 2014 12:57:41 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so6690491wes.22 for ; Tue, 01 Apr 2014 12:57:40 -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=6S+I3YNzZON0IQn1wKU9xH95Jrh8AUZYNe6UeN0XkBE=; b=b3ZPeP3f12AVi777N2XpWqRJTm28NIdhGJlCgZZsC+e814y+5Sf+0hJL25MzFiPKZK /Tn7cDNQ4dDSu1b5JxPjMTPjvrXorOZ6RmqZyCWNEVmy9BUsvzFnk9Xl4k0oyglD6p4o xWNqDNwmrP88Qd3S+WnFVKyxG9K5YsAgx50GpGhG2LMisdKpCjRh/1gIFsJh5EopX2sK a7cy8GTsBaaoZIXRhIODlulL8je76Qb9Kb6/Eeph0910SyyI/UXmBTv23Y2VRTYARKIi xuX77SOpyDkl+F+zvuWNSlFEez4FNjEWHiDNOsM7EZtifwg3kzeZr8NeJzKaMnYR+D+6 nUSw== MIME-Version: 1.0 X-Received: by 10.194.57.239 with SMTP id l15mr23928998wjq.40.1396382260857; Tue, 01 Apr 2014 12:57:40 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 1 Apr 2014 12:57:40 -0700 (PDT) In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Tue, 1 Apr 2014 14:57:40 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sjEzpVD03E56LxJOQ2hsEandA80 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: Tue, 01 Apr 2014 19:57:48 -0000 On Fri, Mar 28, 2014 at 7:07 PM, Dan Harkins wrote: >> 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. IMO: - user authentication generally belongs at the app layer, with channel binding to TLS, however - since there are applications where having userauth in lower layers is convenient, it's OK to have this option in TLS, but - we should use an augmented ZKPP for this. If that means extra round-trips or starting sooner (in the client's first message), so be it. We shouldn't be so constrained by the "TLS state machine" that we make no real progress. Finally: - we should use well-understood, well-aged, believed-secure protocols. We are constrained here by IPR, but there are protocols which can reasonably cut through IPR FUD (e.g., J-PAKE). Nico -- From nobody Tue Apr 1 13:59:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C579E1A0A00 for ; Tue, 1 Apr 2014 13:59:14 -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 6vy8qf-jME_F for ; Tue, 1 Apr 2014 13:59:13 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 082921A09FC for ; Tue, 1 Apr 2014 13:59:13 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 46A6DA888016; Tue, 1 Apr 2014 13:59:09 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Apr 2014 13:59:09 -0700 (PDT) Message-ID: <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> In-Reply-To: References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> Date: Tue, 1 Apr 2014 13:59:09 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" 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/ewS7spJsPyCHjgdO2GzuZNPryk8 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: Tue, 01 Apr 2014 20:59:15 -0000 On Tue, April 1, 2014 12:30 pm, Nico Williams wrote: > On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd > wrote: >> PSK has no security? That's ridiculous: if high-entropy keys are used >> it is fairly easy to see it is secure. > > TLS-PSK did not specify a PBKDF either, so it can't be used with > passwords, therefore we might as well assume high-quality keys for > TLS-PSK. Therefore you're quite right. There is nothing in the protocol that prevents it from being used with passwords. You're not only assuming something about the nature of the PSK, you're assuming something about the people that use the protocol and that is quite naive. Furthermore making assumptions about the nature of the PSK does not change the fact that TLS-PSK has a defect: the advantage an attacker gains is through computation and not interaction. And for the non-DHE ciphersuites, that defect can be exploited through passive attack! > Even if the server must store a password-equivalent I'd still want a > decent PBKDF to be used for any protocol that derives keying material > from passwords! Why? Deterministically hashing a secret 1000 times or 4000 times does not increase the entropy in the secret. A PBKDF is just supposed to increase the work factor of the attacker, it does nothing to the resulting keying material. Wi-Fi specifies a PBKDF when using a PSK and the exchange is essentially the same as the non-DHE TLS-PSK ciphersuites. That protocol is horribly broken and tools exist on the Internet to attack it. And guess what? People still use it with weak, low-entropy PSKs in spite of assumptions to the contrary. Dan. From nobody Tue Apr 1 14:16: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 E7FD41A09F2 for ; Tue, 1 Apr 2014 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 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, 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 QB0KPvhpvuIU for ; Tue, 1 Apr 2014 14:16:45 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7137D1A08C1 for ; Tue, 1 Apr 2014 14:16:45 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id AA34F350084; Tue, 1 Apr 2014 14:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QYOgbcg5/J2vm7 KU1S1nPi8XmE0=; b=s2TSa0hJ1KVAi5+VOj7W+hfDnxUR/mySg4g6GSIFJon4MW 0VkWTURYGWZkBD+E+8WBs9CnykSEisH2KMIPW6JpvvBTEdTx9/A2x6WLLa2v/KEr edgTLKq7Fc/HSnLeQxqYQ47Nu1rUI6xT1bG/1jj1jjyoCHoxnAbvYV1pepNfY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 50D5335007A; Tue, 1 Apr 2014 14:16:41 -0700 (PDT) Date: Tue, 1 Apr 2014 16:16:40 -0500 From: Nico Williams To: Dan Harkins Message-ID: <20140401211637.GA21606@localhost> References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jUjgSvxioPwjUJiclQghmwzxYa0 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: Tue, 01 Apr 2014 21:16:47 -0000 On Tue, Apr 01, 2014 at 01:59:09PM -0700, Dan Harkins wrote: > On Tue, April 1, 2014 12:30 pm, Nico Williams wrote: > > On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd > > wrote: > >> PSK has no security? That's ridiculous: if high-entropy keys are used > >> it is fairly easy to see it is secure. > > > > TLS-PSK did not specify a PBKDF either, so it can't be used with > > passwords, therefore we might as well assume high-quality keys for > > TLS-PSK. Therefore you're quite right. > > There is nothing in the protocol that prevents it from being used with > passwords. You're not only assuming something about the nature of the > PSK, you're assuming something about the people that use the protocol > and that is quite naive. PSK requires pre-sharing the secret key. If such presharing involves a password then the secret key must be derived from said password. How? Well, the two peers have to agree. How? Well, it's not specified! If there interoperable TLS-PSK w/ password implementations, then there's a missing standard. I have no knowledge of such implementations. Without any further input the only reasonable conclusion is that TLS-PSK does not support passwords. Evidence to the contrary would be welcomed. > Furthermore making assumptions about the nature of the PSK does not > change the fact that TLS-PSK has a defect: the advantage an attacker > gains is through computation and not interaction. And for the non-DHE > ciphersuites, that defect can be exploited through passive attack! Only if they are password-derived keys, otherwise no. > > Even if the server must store a password-equivalent I'd still want a > > decent PBKDF to be used for any protocol that derives keying material > > from passwords! > > Why? Deterministically hashing a secret 1000 times or 4000 times > does not increase the entropy in the secret. A PBKDF is just supposed > to increase the work factor of the attacker, it does nothing to the > resulting keying material. Because verifier databases get compromised regularly. Just point your browser to your favorite news site and wait a few weeks, you'll see. > Wi-Fi specifies a PBKDF when using a PSK and the exchange is > essentially the same as the non-DHE TLS-PSK ciphersuites. That > protocol is horribly broken and tools exist on the Internet to attack > it. And guess what? People still use it with weak, low-entropy PSKs > in spite of assumptions to the contrary. My concern is not eavesdroppers in this case. See above. Nico -- From nobody Tue Apr 1 15:30: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 DB8201A08EB for ; Tue, 1 Apr 2014 15:30:36 -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 fcawgzonDkGI for ; Tue, 1 Apr 2014 15:30:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 160CA1A08DE for ; Tue, 1 Apr 2014 15:30:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 645F0A888016; Tue, 1 Apr 2014 15:30:31 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Apr 2014 15:30:31 -0700 (PDT) Message-ID: In-Reply-To: <20140401211637.GA21606@localhost> References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> <20140401211637.GA21606@localhost> Date: Tue, 1 Apr 2014 15:30:31 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" 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/NEExI7nUKqiSA-XDtxwdzrAWX2o 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: Tue, 01 Apr 2014 22:30:37 -0000 On Tue, April 1, 2014 2:16 pm, Nico Williams wrote: > On Tue, Apr 01, 2014 at 01:59:09PM -0700, Dan Harkins wrote: >> On Tue, April 1, 2014 12:30 pm, Nico Williams wrote: >> > On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd >> > wrote: >> >> PSK has no security? That's ridiculous: if high-entropy keys are used >> >> it is fairly easy to see it is secure. >> > >> > TLS-PSK did not specify a PBKDF either, so it can't be used with >> > passwords, therefore we might as well assume high-quality keys for >> > TLS-PSK. Therefore you're quite right. >> >> There is nothing in the protocol that prevents it from being used with >> passwords. You're not only assuming something about the nature of the >> PSK, you're assuming something about the people that use the protocol >> and that is quite naive. > > PSK requires pre-sharing the secret key. If such presharing involves a > password then the secret key must be derived from said password. How? > Well, the two peers have to agree. How? Well, it's not specified! No, the secret key IS the password, it's not derived from the password. > If there interoperable TLS-PSK w/ password implementations, then there's > a missing standard. I have no knowledge of such implementations. > > Without any further input the only reasonable conclusion is that TLS-PSK > does not support passwords. Evidence to the contrary would be welcomed. Try openssl. It has an artificial hex checker for PSK inputs but make your PSK be "bad" without the quotes. Works just fine. The presence of implementations is somewhat irrelevant since the point is that the _specification_ allows for a PSK to be anything, it just needs to be identical on both sides. >> Furthermore making assumptions about the nature of the PSK does not >> change the fact that TLS-PSK has a defect: the advantage an attacker >> gains is through computation and not interaction. And for the non-DHE >> ciphersuites, that defect can be exploited through passive attack! > > Only if they are password-derived keys, otherwise no. No, that is wrong. Just because something is a number, or is taken from a large space of numbers does not change the fact that the adversary gains advantage through computation. It either passively observes a single TLS-PSK exchange (if non-DHE) or it performs a single active attack on a TLS-PSK user (if DHE) and then goes offline and crunches numbers until it determines the PSK. Using a "high quality key" just makes that number crunching take more time, it does not change the fundamental nature of the number crunching. And therein lies the flaw of the TLS-PSK ciphersuites. A protocol that requires the adversary to gain advantage through interaction and not through computation is vastly superior because excessive unsuccessful interaction can be detected. >> > Even if the server must store a password-equivalent I'd still want a >> > decent PBKDF to be used for any protocol that derives keying material >> > from passwords! >> >> Why? Deterministically hashing a secret 1000 times or 4000 times >> does not increase the entropy in the secret. A PBKDF is just supposed >> to increase the work factor of the attacker, it does nothing to the >> resulting keying material. > > Because verifier databases get compromised regularly. Just point your > browser to your favorite news site and wait a few weeks, you'll see. But that has nothing to do with how a protocol derives keying material. >> Wi-Fi specifies a PBKDF when using a PSK and the exchange is >> essentially the same as the non-DHE TLS-PSK ciphersuites. That >> protocol is horribly broken and tools exist on the Internet to attack >> it. And guess what? People still use it with weak, low-entropy PSKs >> in spite of assumptions to the contrary. > > My concern is not eavesdroppers in this case. See above. So what? It's an example of a protocol that uses a PBKDF being trivially and successfully attacked. The result of the attack is that the PSK. If the attacker chooses to use that knowledge to further eavesdrop it's up to him. Regardless of your concern, your belief in the power of a PBKDF seems a bit misplaced. Dan. From nobody Tue Apr 1 21:28: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 80CA21A0120 for ; Tue, 1 Apr 2014 21:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_Ma7IADwqhM for ; Tue, 1 Apr 2014 21:28:44 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3372A1A011D for ; Tue, 1 Apr 2014 21:28:44 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so10068596yha.31 for ; Tue, 01 Apr 2014 21:28:40 -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=Yfutz/3stomzToBD9Tb06icCLPqLyMdIy+Az9uJLm5I=; b=xJoghtNxIVKopcJyF/O12xoXDeT3KTaUwsEJUWwkJ5w69MC2+ctf73EFgriTA7edH8 KAkPmM07CNeqV+fPVeBsTq4wqln2i1WZ1Jlt4TBvzUHZL5AIs2WHOnOqC/+nvzQHahnh 1oLZTNR0FtJ7A8w2x0r9JZMbnDlM5SNFFw+dGm2oNqg5MoTRW0gwoBm7FeQjHuiek0eI t0y3+0h5LG7Q+eIy8tKPptmSswKOL4pyOXSCaL5YMqbrSciRc4+2h1xzcRNpg2s9JwTv wogDpDDJhxPLdSod30R1rlgO+fzfW9cxpYzXmledNOOC7P72naakUU087nuKG3ug9ALG SlGA== MIME-Version: 1.0 X-Received: by 10.236.140.16 with SMTP id d16mr50973863yhj.55.1396412920395; Tue, 01 Apr 2014 21:28:40 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 1 Apr 2014 21:28:40 -0700 (PDT) Date: Tue, 1 Apr 2014 21:28:40 -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/ZWivv4Ssc6QJiANFeEQFIoX0LgY Cc: "tls@ietf.org" Subject: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 04:28:45 -0000 Dear all, I'm afraid that several important points and quite a bit of history has been missing from the recent exchange concerning Dragonfly in TLS. Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE has a patent that expires in 2016, and a security proof in the ROM under a DH style assumption and a reasonable ideal/real attack model. Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to authenticate nodes in a mesh network. It has no security proof despite efforts to try and find one. The intended usecase is provisioning of constrained devices. While one could include a 128 bit key on each device and have users type it in (as they do for Xbox Live and Windows verification: 25 letters and numbers from a 32 bit alphabet) it was felt that this was a bit much. PSK will not work with anything that isn't a key, because offline attack works beautifully. Nico's concerns about key database compromise, etc, are ignoring the realities of this setting: the password is the least valuable thing on the device, and since it was not entered by the user (as the device has no user interaction capability) unlikely to be reused. Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010. There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE is not specified on ECC groups, but this is easy to fix. (It's also ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are not on the agenda because of a rather heated controversy about how Dragonfly got (seeming) CFRG approval, but there is a good case for including them. On the web we have more of a problem due to the UI issues that made client certificates a nonstarter. Sincerely, Watson Ladd From nobody Tue Apr 1 22:44:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7C1A0134 for ; Tue, 1 Apr 2014 22:44:38 -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 LTyW4B3k76wK for ; Tue, 1 Apr 2014 22:44:34 -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 250F71A0133 for ; Tue, 1 Apr 2014 22:44:33 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so10982423vcb.41 for ; Tue, 01 Apr 2014 22:44:30 -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=4EC/bDyrqAW6n6/LHIV4bMnBT7pH6DyKSLotyB+WZCc=; b=imng/5r1d2damalvONpt/27R0tDIYZGMVnqPb2MNnLjGNHidiOZRywNuq6au0jvX0f YgGgmLRMxiqtMGLFLLCfw0DKrGMobcxaftZ6XHFgtZ+q8xX4zn8D/bUKX/i1b0v0E9td bjnqpN11dPElckgGbxOFhS0ShUlkzgrWW6GROudUe5rST/cP4REXHr+kBpUto8fTGDcz D+94L3CsNSP0jZA8STBhWvMgPeUxYLwQwvmIG/I0vX8KLygVJNF8Q6SibCS03hQRA8o6 DPlETF3wAC3BoLvOShydKsHQNTHQ4hbJ0u++21nDaMtYtdlBIyMvWicnuZ2dzyME2Ip/ Y+jg== MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr5717726vdc.34.1396417470077; Tue, 01 Apr 2014 22:44:30 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Tue, 1 Apr 2014 22:44:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 22:44:29 -0700 X-Google-Sender-Auth: A4gmLMwwCvFHvAq0lw8Eft9Uawk Message-ID: From: Erik Nygren To: Chris Newman Content-Type: multipart/alternative; boundary=089e0153686443223004f608c70f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FG4MhdEnBi0npte1CZgyyZjWt48 Cc: "tls@ietf.org" Subject: Re: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 05:44:38 -0000 --089e0153686443223004f608c70f Content-Type: text/plain; charset=ISO-8859-1 Along these lines, it would be worth discussing an optional proof-of-work extension such that the server could introduce an extra RT by pose a problem back to the client under certain overload circumstances and then wait for a successful response from the client before performing additional cryptographic operations. This would be something that would normally only be used when the server is under attack to help it selectively raise the bar. (Clients could also chose to abandon the connection.) For example, a server under attack could propose back to clients: { partial_value, num_bits, SHA256(full_value) } where the first num_bits of full_value have been zeroed out. The client must respond back with full_value before the the server will spend additional CPU time on the negotiation. This also lets the server select different values for num_bits depending on how much load it is intending to shed (or perhaps based on how many connections have come in from that particular client recently). While not necessarily being "fair" to low-powered devices, it would be extremely valuable for allowing servers to selectively shed load by controlling how symmetric the workload for a given set of clients must be. Erik On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman wrote: > Is there a TLS Alert type that can be used by a TLS server to reject a TLS > client connection based on a per-IP-address connection limit? > > The idea would be to have the server reject the connection before spending > cycles on the TLS negotiation. But it's important to inform the client why > the > connection is rejected in order to reduce the number and severity of > support > calls that might be generated by such a limit if the connections were > silently > dropped. > > Another case that's interesting is when the server is temporarily > overloaded > and wants to reserve CPU cycles for existing connections rather than > spending > cycles accepting new connections. Again, it's desirable to indicate to the > client the cause of this connection failure in an attempt to reduce the > number > and severity of support calls and also desirable not to spend unnecessary > server time on the TLS negotiation. > > With the STARTTLS model, applications could just reject at the banner with > a > text error message. But with the separate-port-for-TLS model, this needs > to be > done in the TLS layer. > > I didn't see appropriate alerts in RFC 5246 section 7.2. > > Could alerts for these two cases be added as an extension or a TLS 1.3 > feature? > > - Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0153686443223004f608c70f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Along these lines, it would be worth d= iscussing an optional proof-of-work extension such that the server could in= troduce an extra RT by pose a problem back to the client under certain over= load circumstances and then wait for a successful response from the client = before performing additional cryptographic operations.=A0 This would be som= ething that would normally only be used when the server is under attack to = help it selectively raise the bar.=A0 (Clients could also chose to abandon = the connection.)

For example, a server under attack could propose back to clients:= =A0

=A0 =A0 =A0 =A0 =A0=A0 { partial_value, num_bits, SHA256(full_v= alue) }

where the first num_bits of full_value have been zeroe= d out.=A0 The client must respond back with full_value before the the serve= r will spend additional CPU time on the negotiation.=A0 This also lets the = server select different values for num_bits depending on how much load it i= s intending to shed (or perhaps based on how many connections have come in = from that particular client recently).=A0

While not necessarily being "fair" to low-powered= devices, it would be extremely valuable for allowing servers to selectivel= y shed load by controlling how symmetric the workload for a given set of cl= ients must be.

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


On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman <chris.newman@oracle.com> wrote:
Is there a TLS Alert type that can be used b= y a TLS server to reject a TLS
client connection based on a per-IP-address connection limit?

The idea would be to have the server reject the connection before spending<= br> cycles on the TLS negotiation. But it's important to inform the client = why the
connection is rejected in order to reduce the number and severity of suppor= t
calls that might be generated by such a limit if the connections were silen= tly
dropped.

Another case that's interesting is when the server is temporarily overl= oaded
and wants to reserve CPU cycles for existing connections rather than spendi= ng
cycles accepting new connections. Again, it's desirable to indicate to = the
client the cause of this connection failure in an attempt to reduce the num= ber
and severity of support calls and also desirable not to spend unnecessary server time on the TLS negotiation.

With the STARTTLS model, applications could just reject at the banner with = a
text error message. But with the separate-port-for-TLS model, this needs to= be
done in the TLS layer.

I didn't see appropriate alerts in RFC 5246 section 7.2.

Could alerts for these two cases be added as an extension or a TLS 1.3 feat= ure?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Chris

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

--089e0153686443223004f608c70f-- From nobody Tue Apr 1 23:20: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 0716A1A0140 for ; Tue, 1 Apr 2014 23:20:07 -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 3OhOZdUSEKR5 for ; Tue, 1 Apr 2014 23:20:00 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C31A013A for ; Tue, 1 Apr 2014 23:19:59 -0700 (PDT) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id 6E45460171 for ; Wed, 2 Apr 2014 07:19:55 +0100 (BST) Message-ID: <533BAC14.90803@akr.io> Date: Wed, 02 Apr 2014 07:20:04 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c4tq7ea6fZThWgD8Sbv6vCFASkw Subject: Re: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 06:20:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/04/2014 06:44, Erik Nygren wrote: > For example, a server under attack could propose back to clients: > > { partial_value, num_bits, SHA256(full_value) } > > where the first num_bits of full_value have been zeroed out. Otherwise known as "hashcash". It's been noted (by Satoshi Nakamoto, I think?) that you get better granularity with "here's an integer: find me a value that hashes to less than that" (given a particular form of integer representation<->octets). Of course, the server would have to spend cycles generating and validating challenges. Not as many as the clients, but still, cycles. I don't think this is necessarily useful. Might even make a DoS surface more visible. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTO6wUAAoJEOyEjtkWi2t6YpEP+wW2B23Ig8sBFV7pWnhowGLG dqYTEPDRYn0XPTKTqYm4Nmg+fZedfhiFj/T6jkN+gMV6hTUKYOpBRfX0u+1RLtDl zSHQ0T9n9Sf7oWbhSn6sgZ3iLDlLfelHm66iJCiBJqLXoWWBKBz1aFjiyzJkWSNP nBhY9BqGPVvR8LhT5Yzz9Lrg5PSh2eQ3BoJvZMssp6VvMcIEkzDwC1wDRaWBBUCS 6h2Jksj67CyKG5v/uC7S9PVUFvdB+CbJanT75Jua5tXcAVFixBfXuXcjA6TAUPeb y9KWcBD6n3uvKgF3onrcBYKb16cxh3bS8spATy/l59m3MewQsTBqIjpOrP5jjPMl 8cLlGwrGFEaHPnJytWfcxjih1gIs4KqtT7SS6MvB2Mmp2uLQiuA7qF3sQHCNLO8g fWT2YGQ6qACXT8nBdZyTvKjJlEb6SoT39btk/w7fdWDjepDcaIjIWPV+8KNoPbAS ybv/7YPmKxV8LytcPDZpGwwCYz6K4Ru5Lo1/XrHtYyuy6RZ3lG7/Fdr85NaYHQDM d7jYENHNak3FoB3PqktuqIr1A7LwCPvbg5BcVtrzfDqEftWfdBkIbUgK1W0EjI1h HuOYjSuCknK4TonRcdqkAejhN33LNBtFjU20h0QMLPQOD/lCLQAnscP1NjENtMuW qEVTCggR64L9Ntv8JRlb =3YuW -----END PGP SIGNATURE----- From nobody Tue Apr 1 23:23: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 CB2D71A0141 for ; Tue, 1 Apr 2014 23:23:25 -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 Zhciwur30I6w for ; Tue, 1 Apr 2014 23:23:21 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 352321A0149 for ; Tue, 1 Apr 2014 23:23:21 -0700 (PDT) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id 1807960171 for ; Wed, 2 Apr 2014 07:23:17 +0100 (BST) Message-ID: <533BACDD.5050904@akr.io> Date: Wed, 02 Apr 2014 07:23:25 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <533BAC14.90803@akr.io> In-Reply-To: <533BAC14.90803@akr.io> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_NzhjYCw4FHYx7l6_DW_WbRKTi8 Subject: Re: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 06:23:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/04/2014 07:20, Alyssa Rowan wrote: > Otherwise known as "hashcash". [Ugh, shouldn't post before breakfast, mistake. It's not hashcash, although it is kinda like it. Reverse hashcash, maybe.] It'd have to remember full_value under overload conditions, though. Unless that's shared, that's memory (stored) or CPU (generated). - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTO6zdAAoJEOyEjtkWi2t6UiYP+wawQNs3Y1jWl/IPCngGKISe TjW4zbSI8zOjbk6gCrkI3tMnUHIchWMR972EaFNqDBGT9LIMir4ak1vpD/m+g7pG 1F4KgVH+b7iJ/Z/ZfISNNjXx6MoqDmWjLVoxbiHghjTEkf0ElinNNsOu7QE9znzd mRpfQofHf2V6xSZt4PmE/oLUtXjiEda2WG3AW8OhOLdjw+Ihgs4fN9SxsLjYq4/7 vznGO8qXQYAfh95XZQ1VsT9lf2mMASW/lH10czb4djXYrp7wNKQ2aG16PmSozZdr qnCYb4IZ3YciG16mQ5sBiPf0wtEu9tpc/BeYpGVFkm2c/chjS7jzoP4gjehyWihm eB8e/dO7HwIk+iaF1M+0VA4KkmcEqKHTFMsqyD0d0RR5J5ejbAn3T8Kae3OyNpUA 9t/4SdI/Wrt9o5r1hCS1p8LjeksmENJMjQE6Z21lPX5RkGJ2+F1Zk5ieNMjcFEOA UYXK5DWcs+Wofw3+dcR++zQyDgYSr3L8UgUZltOQIrESmrGq4bSeRXuPa2lwyOus /n3aSeuBqOAqbKfVFkCC6l86BJH2/GybEIsP70RHZgcWXdCpIWhitxD/jM8w2LUr biMVUzbGviDyo1S3JSCu82tQBqqzixD7UmCCRSKtmtwJjCtp39igKMtdKHIy6URo u4FgGxztq8HWjV30W323 =31sI -----END PGP SIGNATURE----- From nobody Tue Apr 1 23:31:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D63B1A0141 for ; Tue, 1 Apr 2014 23:31:11 -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 OMo42XRSw-C7 for ; Tue, 1 Apr 2014 23:31:07 -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 9B1F71A014D for ; Tue, 1 Apr 2014 23:31:04 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so8338661wgh.0 for ; Tue, 01 Apr 2014 23:31: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:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=VobyVB9cl/oIov4OhYbB7HX6PXVWkoWSJN8OYeHC8jM=; b=IZ/nIubEJwtNUvRPZrAavXh5B5/lvpDnP5AZEI/RGvd5qVHxV4aHhM977rcqc9OvqC 0hb1F4PBg5bqmdvCQhQtUWmJVDDocmPGXge7TVQSKZ1ncBAlqmubDJDmPoAtMMUVTI/m lfto8f5TZdt93/Pku6pMKRO5XseAkI3VxKYPfDg2wrchJrLNYbM1gDge07Y3Q5fLP/p0 jZELxWI7cfCrZaCfxcRpIC9Xfo1+poHcLfPe/qflXw4Zn3xRVgOZ58g+ZCht1tzbbaeu 0xr3KJ2NKPBeh+08gfYTDXQMtEH+bd8XfSRdeBFNUKiFbtIajwOJhFWM6w+9NnPGo4L6 YnfQ== X-Gm-Message-State: ALoCoQkE8NwhVxLoit+apZpDIxlG1veHb90HPdBm25O/ILljm+tOJ336hs5nVLiQXj1SA9otd3DS X-Received: by 10.180.84.73 with SMTP id w9mr25568542wiy.58.1396420260296; Tue, 01 Apr 2014 23:31:00 -0700 (PDT) Received: from [192.168.1.10] (AAubervilliers-651-1-161-84.w81-249.abo.wanadoo.fr. [81.249.172.84]) by mx.google.com with ESMTPSA id gx9sm2654237wib.13.2014.04.01.23.30.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 23:30:54 -0700 (PDT) From: "henry.story@bblfish.net" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <676D7423-514E-40A1-9CE5-DCBE3E5811FC@bblfish.net> Date: Wed, 2 Apr 2014 08:30:52 +0200 To: TLS Mailing List 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/GEy7EO1Np8gxHc3_osVE3qmFkNI Subject: [TLS] registering x-509 mime types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 06:31:11 -0000 Hi, The HTML5 keygen element [1] works by having the browser send a public = key to the server which can then return an X509 certificate back to the browser = using one of the following mime types [2] (a) application/x-x509-user-cert=20 (b) application/x-x509-ca-cert=20 (c) application/x-x509-email-cert This seems to work for most browsers - Safari, Chrome, Nescape, Opera - = and has been functioning like this since at least the year 2000 I think. The = keygen tag was only added to html officially a few years ago. What is missing though is that these mime types are not registered at = IANA. Is there anyone here ( or perhaps I should look somewhere else ) who = would like to register that at IANA? It would at least make it easier for = developers building web sites to work out what the correct mime type to use is. Perhaps one could also then get the html5 people to add a note about = this to their specification. =20 = http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/084613.html= Henry [1] = http://www.w3.org/html/wg/drafts/html/CR/forms.html#the-keygen-element [2] https://wiki.mozilla.org/CA:Certificate_Download_Specification [3] http://www.iana.org/assignments/media-types/media-types.xhtml Social Web Architect http://bblfish.net/ From nobody Tue Apr 1 23:35: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 75B7E1A00D9 for ; Tue, 1 Apr 2014 23:35:07 -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 5UZRhD9ijX6Z for ; Tue, 1 Apr 2014 23:35:03 -0700 (PDT) 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 675041A00DE for ; Tue, 1 Apr 2014 23:35:03 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so11319983vcb.35 for ; Tue, 01 Apr 2014 23:34:59 -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=N8nY40/R6jBNHZoJCszkueUCenprCPG/bBH/66hXizk=; b=nhefJ1QZ4yOgfFYz3xV4fL4MtHWueR2HTP76D7quQqQn7USW8kfVB14I1a/sQu6mmT 3UyCm56q4BjGh/uiLbhIXRsj1aeNzo0VmghFKykIcSm3gm5kZRdSqMzMCbOvYQL/7XFk q1zh7A5LEnI2IjGK+dqQdRwRZbXgjkicDNqXEPkRhzcMT9gzh5AIoUyF+uUffWgTxOX/ bmjHgzP65/emqBRX8McIzgTWsTVuLTFwObE3oVDZglk6N6dYlvg9uucMNsPy7VM2JWeZ onXVyJ7EA+k9UGnbOK4FWKnOnh2YBy5+P4VUS+cbqiPBqKDC49hamDHU/nlVSsrPG8x+ 3Pzw== MIME-Version: 1.0 X-Received: by 10.52.163.145 with SMTP id yi17mr186974vdb.46.1396420499377; Tue, 01 Apr 2014 23:34:59 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Tue, 1 Apr 2014 23:34:59 -0700 (PDT) In-Reply-To: <533BACDD.5050904@akr.io> References: <533BAC14.90803@akr.io> <533BACDD.5050904@akr.io> Date: Tue, 1 Apr 2014 23:34:59 -0700 X-Google-Sender-Auth: VgmLENnMZnMbaRGWCwMihIpkKGI Message-ID: From: Erik Nygren To: Alyssa Rowan Content-Type: multipart/alternative; boundary=001a11c2bb5ad296b304f6097ba7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wwyDADBOTHkGFDGRpARvy5Ry5j4 Cc: "tls@ietf.org" Subject: Re: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 06:35:07 -0000 --001a11c2bb5ad296b304f6097ba7 Content-Type: text/plain; charset=ISO-8859-1 > Of course, the server would have to spend cycles generating and > validating challenges. Not as many as the clients, but still, cycles. Of course, but considerably less (orders of magnitude less?). Very similar to the cycles used in syncookies. > It'd have to remember full_value under overload conditions, though. > Unless that's shared, that's memory (stored) or CPU (generated). Not necessarily. If structured right, the server could construct full_value from something like { HMAC-SHA256(key, nonce || client_ipaddr) || nonce } that could be reconstructed when the client returns. The server might then went to keep these around for a bit for *accepted* connections to avoid replay attacks. (Disclaimer: I'm not a cryptographer, so the example given was more a sample type of proof-of-work rather than a particular proposed implementation.) Erik On Tue, Apr 1, 2014 at 11:23 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/04/2014 07:20, Alyssa Rowan wrote: > > > Otherwise known as "hashcash". > > [Ugh, shouldn't post before breakfast, mistake. It's not hashcash, > although it is kinda like it. Reverse hashcash, maybe.] > > It'd have to remember full_value under overload conditions, though. > Unless that's shared, that's memory (stored) or CPU (generated). > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJTO6zdAAoJEOyEjtkWi2t6UiYP+wawQNs3Y1jWl/IPCngGKISe > TjW4zbSI8zOjbk6gCrkI3tMnUHIchWMR972EaFNqDBGT9LIMir4ak1vpD/m+g7pG > 1F4KgVH+b7iJ/Z/ZfISNNjXx6MoqDmWjLVoxbiHghjTEkf0ElinNNsOu7QE9znzd > mRpfQofHf2V6xSZt4PmE/oLUtXjiEda2WG3AW8OhOLdjw+Ihgs4fN9SxsLjYq4/7 > vznGO8qXQYAfh95XZQ1VsT9lf2mMASW/lH10czb4djXYrp7wNKQ2aG16PmSozZdr > qnCYb4IZ3YciG16mQ5sBiPf0wtEu9tpc/BeYpGVFkm2c/chjS7jzoP4gjehyWihm > eB8e/dO7HwIk+iaF1M+0VA4KkmcEqKHTFMsqyD0d0RR5J5ejbAn3T8Kae3OyNpUA > 9t/4SdI/Wrt9o5r1hCS1p8LjeksmENJMjQE6Z21lPX5RkGJ2+F1Zk5ieNMjcFEOA > UYXK5DWcs+Wofw3+dcR++zQyDgYSr3L8UgUZltOQIrESmrGq4bSeRXuPa2lwyOus > /n3aSeuBqOAqbKfVFkCC6l86BJH2/GybEIsP70RHZgcWXdCpIWhitxD/jM8w2LUr > biMVUzbGviDyo1S3JSCu82tQBqqzixD7UmCCRSKtmtwJjCtp39igKMtdKHIy6URo > u4FgGxztq8HWjV30W323 > =31sI > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c2bb5ad296b304f6097ba7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Of course, the server would have = to spend cycles generating and
> validating challenges. =A0Not as many as the clients, but still, cycle= s.

Of course, but considerably less (orders of magnitude less?).=A0 = Very similar to the cycles used in syncookies.

> It'd have to= remember full_value under overload conditions, though.
> Unless that's shared, that's memory (stored) or CPU (generated= ).

Not necessarily.=A0 If structured right, the server could c= onstruct full_value from something
like { HMAC-SHA256(key, nonce || clie= nt_ipaddr) || nonce }
that could be reconstructed when the client returns.=A0 The server mi= ght then went
to keep these around for a bit for *accepted* connections = to avoid replay attacks.

(Disclaimer:=A0 I'm not a cryptog= rapher, so the example given was more
a sample type of proof-of-work rather than a particular proposed implementa= tion.)

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

<= div>

=
On Tue, Apr 1, 2014 at 11:23 PM, Alyssa Rowan <akr@akr.io> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/04/2014 07:20, Alyssa Rowan wrote:

> Otherwise known as "hashcash".

[Ugh, shouldn't post before breakfast, mistake. It's not hash= cash,
=A0although it is kinda like it. Reverse hashcash, maybe.]

It'd have to remember full_value under overload conditions, though.
Unless that's shared, that's memory (stored) or CPU (generated).

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

iQIcBAEBCgAGBQJTO6zdAAoJEOyEjtkWi2t6UiYP+wawQNs3Y1jWl/IPCngGKISe
TjW4zbSI8zOjbk6gCrkI3tMnUHIchWMR972EaFNqDBGT9LIMir4ak1vpD/m+g7pG
1F4KgVH+b7iJ/Z/ZfISNNjXx6MoqDmWjLVoxbiHghjTEkf0ElinNNsOu7QE9znzd
mRpfQofHf2V6xSZt4PmE/oLUtXjiEda2WG3AW8OhOLdjw+Ihgs4fN9SxsLjYq4/7
vznGO8qXQYAfh95XZQ1VsT9lf2mMASW/lH10czb4djXYrp7wNKQ2aG16PmSozZdr
qnCYb4IZ3YciG16mQ5sBiPf0wtEu9tpc/BeYpGVFkm2c/chjS7jzoP4gjehyWihm
eB8e/dO7HwIk+iaF1M+0VA4KkmcEqKHTFMsqyD0d0RR5J5ejbAn3T8Kae3OyNpUA
9t/4SdI/Wrt9o5r1hCS1p8LjeksmENJMjQE6Z21lPX5RkGJ2+F1Zk5ieNMjcFEOA
UYXK5DWcs+Wofw3+dcR++zQyDgYSr3L8UgUZltOQIrESmrGq4bSeRXuPa2lwyOus
/n3aSeuBqOAqbKfVFkCC6l86BJH2/GybEIsP70RHZgcWXdCpIWhitxD/jM8w2LUr
biMVUzbGviDyo1S3JSCu82tQBqqzixD7UmCCRSKtmtwJjCtp39igKMtdKHIy6URo
u4FgGxztq8HWjV30W323
=3D31sI
-----END PGP SIGNATURE-----

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

--001a11c2bb5ad296b304f6097ba7-- From nobody Wed Apr 2 00:12: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 BE0E41A0022 for ; Wed, 2 Apr 2014 00:12:33 -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, FREEMAIL_FROM=0.001, 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 qjLS7RTVXqte for ; Wed, 2 Apr 2014 00:12:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5491A0013 for ; Wed, 2 Apr 2014 00:12:29 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8MyE-1XH0fl0hsI-00vv5Y; Wed, 02 Apr 2014 09:12:23 +0200 Message-ID: <533BB7E1.9060400@gmx.net> Date: Wed, 02 Apr 2014 09:10:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dan Harkins , Nico Williams References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> <20140401211637.GA21606@localhost> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ojXmX6bdkRNVqh9QVudxo8hWBE4i1r8DE" X-Provags-ID: V03:K0:BmlpvAmhKmOe5yp2Plb7lX/UxtMp+C0LqdjmlG0CzTPnjRdHDG3 cSTM97EYHLJ3dbkDwgESOw2+nulHds7k0IfneiC7D1TTBVRwhlohdYIO+u6F0Lm2L7H6049 s4NZZ7IjIm6jRKJBua/BpvzR9YWuwN92tzda7Fm+56RGoFAGNocivi8tAC57MQ+AuXQx2Xq GWT1a0J9I4YgBkMtN5uww== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xDZJVIurRS9tIIme6fol3ZDGHak Cc: "tls@ietf.org" Subject: [TLS] PSK has no security? ... was Re: 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: Wed, 02 Apr 2014 07:12:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ojXmX6bdkRNVqh9QVudxo8hWBE4i1r8DE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I just noticed this one sentence "PSK has no security?" and it caught my attention. I believe you guys are trying to misinterpet the TLS-PSK document. Maybe you are thinking about use cases we did not envision. TLS-PSK is not a password-based authentication mechanism for TLS! It was never meant to be one either. On the Web, already at that time, everyone was using passwords in forms rather than at a lower layer in the stack. This has not changed. (So, there was no need to standardize a password-based mechanism in TLS at that time.) There are very few people who are interested in using passwords in TLS and I don't think this is the direction where deployments are going. (Have a look at FIDO for a more promising approach of improving authentication on the Web.) [FWIW, I believe the strong password-based authentication and key exchange in TLS will not lead to an improvement in password practices on the Web.] As a co-author of the TLS-PSK RFC I can tell you that the work was motivated by activities in the 3GPP. The 3GPP had developed a Kerberos alike key management protocol. The fresh and unique session key (not password) would then be used as input to the TLS-PSK protocol. Now, it turns out that that 3GPP work didn't really go anywhere. What we hadn't anticipated at that time was the development on Internet of Things where it makes sense to provision symmetric keys (not passwords) on sensors for use with the TLS-PSK protocol. This is useful because of (a) the excellent performance of symmetric key cryptography and (b) the small code size. Ciao Hannes On 04/02/2014 12:30 AM, Dan Harkins wrote: >=20 > On Tue, April 1, 2014 2:16 pm, Nico Williams wrote: >> On Tue, Apr 01, 2014 at 01:59:09PM -0700, Dan Harkins wrote: >>> On Tue, April 1, 2014 12:30 pm, Nico Williams wrote: >>>> On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd = >>>> wrote: >>>>> PSK has no security? That's ridiculous: if high-entropy keys are us= ed >>>>> it is fairly easy to see it is secure. >>>> >>>> TLS-PSK did not specify a PBKDF either, so it can't be used with >>>> passwords, therefore we might as well assume high-quality keys for >>>> TLS-PSK. Therefore you're quite right. >>> >>> There is nothing in the protocol that prevents it from being used w= ith >>> passwords. You're not only assuming something about the nature of the= >>> PSK, you're assuming something about the people that use the protocol= >>> and that is quite naive. >> >> PSK requires pre-sharing the secret key. If such presharing involves = a >> password then the secret key must be derived from said password. How?= >> Well, the two peers have to agree. How? Well, it's not specified! >=20 > No, the secret key IS the password, it's not derived from the passwor= d. >=20 >> If there interoperable TLS-PSK w/ password implementations, then there= 's >> a missing standard. I have no knowledge of such implementations. >> >> Without any further input the only reasonable conclusion is that TLS-P= SK >> does not support passwords. Evidence to the contrary would be welcome= d. >=20 > Try openssl. It has an artificial hex checker for PSK inputs but make= > your PSK be "bad" without the quotes. Works just fine. >=20 > The presence of implementations is somewhat irrelevant since the poin= t is > that the _specification_ allows for a PSK to be anything, it just needs= to be > identical on both sides. >=20 >>> Furthermore making assumptions about the nature of the PSK does not= >>> change the fact that TLS-PSK has a defect: the advantage an attacker >>> gains is through computation and not interaction. And for the non-DHE= >>> ciphersuites, that defect can be exploited through passive attack! >> >> Only if they are password-derived keys, otherwise no. >=20 > No, that is wrong. Just because something is a number, or is taken > from a large space of numbers does not change the fact that the adversa= ry > gains advantage through computation. It either passively observes a > single TLS-PSK exchange (if non-DHE) or it performs a single active att= ack > on a TLS-PSK user (if DHE) and then goes offline and crunches numbers > until it determines the PSK. >=20 > Using a "high quality key" just makes that number crunching take more= > time, it does not change the fundamental nature of the number crunching= =2E > And therein lies the flaw of the TLS-PSK ciphersuites. >=20 > A protocol that requires the adversary to gain advantage through > interaction and not through computation is vastly superior because > excessive unsuccessful interaction can be detected. >=20 >>>> Even if the server must store a password-equivalent I'd still want a= >>>> decent PBKDF to be used for any protocol that derives keying materia= l >>>> from passwords! >>> >>> Why? Deterministically hashing a secret 1000 times or 4000 times >>> does not increase the entropy in the secret. A PBKDF is just supposed= >>> to increase the work factor of the attacker, it does nothing to the >>> resulting keying material. >> >> Because verifier databases get compromised regularly. Just point your= >> browser to your favorite news site and wait a few weeks, you'll see. >=20 > But that has nothing to do with how a protocol derives keying materia= l. >=20 >>> Wi-Fi specifies a PBKDF when using a PSK and the exchange is >>> essentially the same as the non-DHE TLS-PSK ciphersuites. That >>> protocol is horribly broken and tools exist on the Internet to attack= >>> it. And guess what? People still use it with weak, low-entropy PSKs >>> in spite of assumptions to the contrary. >> >> My concern is not eavesdroppers in this case. See above. >=20 > So what? It's an example of a protocol that uses a PBKDF being > trivially and successfully attacked. The result of the attack is that > the PSK. If the attacker chooses to use that knowledge to further > eavesdrop it's up to him. Regardless of your concern, your belief in > the power of a PBKDF seems a bit misplaced. >=20 > Dan. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --ojXmX6bdkRNVqh9QVudxo8hWBE4i1r8DE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO7fhAAoJEGhJURNOOiAtcMwH+wWpo88pgKSgjNnY5Ik7QXKp nGKhpHnFHtf9MQXYDtJvHh7+r50SZ2cPlPBLX99d3IJM5BSBFAoZ7a+pnLhGu9Yk VhM/w+XOtBdTK7/+vHUjLTKgJFQat9vnEZLCRUkQgRbCtcwkAdOIsnMz56uXFPnk dgX9PnzqGVt7P2oome3Bsx57L0acvzQEB2ck3tK+KtWqo/7YX7WeO6yVlwprvuyk xMZekYslmEtTBj6shoYZIgWzldHy7ecC1dtlTHiEhbnzvQgHVda3GWLCyWcfpz/j 6TxRXYJRmA08SBfDvpa1AE+7ydqH3AVzckQuOXpVjMlNytTqDIFZqoeJyyNdCfA= =6zcw -----END PGP SIGNATURE----- --ojXmX6bdkRNVqh9QVudxo8hWBE4i1r8DE-- From nobody Wed Apr 2 00: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 38A031A014D for ; Wed, 2 Apr 2014 00:24:10 -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 w0QnRzlBJYo3 for ; Wed, 2 Apr 2014 00:24:06 -0700 (PDT) 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 DDA361A006E for ; Wed, 2 Apr 2014 00:24:05 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so7444637wes.34 for ; Wed, 02 Apr 2014 00:24: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 :message-id:references:to; bh=qRHEiAcKZt4bGef8llzjEjiIQnZf6gRdODoLMu2OPdE=; b=MTCwuCxcc2Y0ejtdeJsFWmBog6V1xRigiIrWY17dFgCYwNcv7Dl6TbrmvnEgGQjDmN C5v4TsXvnaNEHBZC8Y8xy5pTrL5u0YNR+pkaVPKu51ntwEFAJotzqR26dqelLTOG/Cf1 oJC0FH5YSD8NbJTZSAgwZbzgTL/jWg3/kWh37+v0cb2UF5yCtwFhGLvuqnu/g/7LOHPc REPp5JpkA5HF+0zhC8DCV6D1FZlmM+HIz+4+8UE4TUraZ+kUTs4c0kX2LDjIBeo5TmLf JtH4DMApOgYJA6jV5Ke7Pa0WDB7L8bFQV+uQcP45CnesTraZeyewf/QW7lTGhbAtOthc IpYQ== X-Received: by 10.194.80.7 with SMTP id n7mr28990250wjx.8.1396423441672; Wed, 02 Apr 2014 00:24:01 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id x3sm2507905eep.17.2014.04.02.00.23.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 00:24:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCC40987-7BB6-4258-BC2B-F27C1F76AF02" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Wed, 2 Apr 2014 10:23:54 +0300 Message-Id: <7A0B56B8-8599-4042-A52D-DA6ECBF0BEC2@gmail.com> References: To: Erik Nygren X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FnATyl90MQh7QeqLo4W_GJo-i7U Cc: "tls@ietf.org" Subject: Re: [TLS] Alert type for connection limit or server busy? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 07:24:10 -0000 --Apple-Mail=_FCC40987-7BB6-4258-BC2B-F27C1F76AF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Erik I raised a similar idea on the SAAG mailing list and at the SAAG meeting = in London. This method is often called =93client puzzles=94. For me this = is interesting for both IKE and TLS. There is an issue that makes this a hard sell, and that is a patent. = See my post to SAAG: = http://www.ietf.org/mail-archive/web/saag/current/msg04579.html I=92ve asked some people who work for the patent owner, and am waiting = to hear from them. Yoav On Apr 2, 2014, at 8:44 AM, Erik Nygren wrote: > Along these lines, it would be worth discussing an optional = proof-of-work extension such that the server could introduce an extra RT = by pose a problem back to the client under certain overload = circumstances and then wait for a successful response from the client = before performing additional cryptographic operations. This would be = something that would normally only be used when the server is under = attack to help it selectively raise the bar. (Clients could also chose = to abandon the connection.) >=20 > For example, a server under attack could propose back to clients: =20 >=20 > { partial_value, num_bits, SHA256(full_value) } >=20 > where the first num_bits of full_value have been zeroed out. The = client must respond back with full_value before the the server will = spend additional CPU time on the negotiation. This also lets the server = select different values for num_bits depending on how much load it is = intending to shed (or perhaps based on how many connections have come in = from that particular client recently). =20 >=20 > While not necessarily being "fair" to low-powered devices, it would be = extremely valuable for allowing servers to selectively shed load by = controlling how symmetric the workload for a given set of clients must = be. >=20 > Erik >=20 >=20 >=20 > On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman = wrote: > Is there a TLS Alert type that can be used by a TLS server to reject a = TLS > client connection based on a per-IP-address connection limit? >=20 > The idea would be to have the server reject the connection before = spending > cycles on the TLS negotiation. But it's important to inform the client = why the > connection is rejected in order to reduce the number and severity of = support > calls that might be generated by such a limit if the connections were = silently > dropped. >=20 > Another case that's interesting is when the server is temporarily = overloaded > and wants to reserve CPU cycles for existing connections rather than = spending > cycles accepting new connections. Again, it's desirable to indicate to = the > client the cause of this connection failure in an attempt to reduce = the number > and severity of support calls and also desirable not to spend = unnecessary > server time on the TLS negotiation. >=20 > With the STARTTLS model, applications could just reject at the banner = with a > text error message. But with the separate-port-for-TLS model, this = needs to be > done in the TLS layer. >=20 > I didn't see appropriate alerts in RFC 5246 section 7.2. >=20 > Could alerts for these two cases be added as an extension or a TLS 1.3 = feature? >=20 > - Chris >=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 --Apple-Mail=_FCC40987-7BB6-4258-BC2B-F27C1F76AF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Erik

I raised a similar idea on the SAAG mailing list = and at the SAAG meeting in London. This method is often called =93client = puzzles=94. For me this is interesting for both IKE and = TLS.

There is an issue that makes this a hard = sell, and that is a patent.  See my post to SAAG: h= ttp://www.ietf.org/mail-archive/web/saag/current/msg04579.html

I=92ve asked some people who work for the patent = owner, and am waiting to hear from = them.

Yoav

On Apr 2, = 2014, at 8:44 AM, Erik Nygren <erik+ietf@nygren.org> = wrote:

Along these lines, it = would be worth discussing an optional proof-of-work extension such that = the server could introduce an extra RT by pose a problem back to the = client under certain overload circumstances and then wait for a = successful response from the client before performing additional = cryptographic operations.  This would be something that would = normally only be used when the server is under attack to help it = selectively raise the bar.  (Clients could also chose to abandon = the connection.)

For example, a server under attack could propose back to = clients: 

           { = partial_value, num_bits, SHA256(full_value) }

where the = first num_bits of full_value have been zeroed out.  The client must = respond back with full_value before the the server will spend additional = CPU time on the negotiation.  This also lets the server select = different values for num_bits depending on how much load it is intending = to shed (or perhaps based on how many connections have come in from that = particular client recently). 

While not necessarily being "fair" to low-powered = devices, it would be extremely valuable for allowing servers to = selectively shed load by controlling how symmetric the workload for a = given set of clients must be.
=

         = Erik



On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman = <chris.newman@oracle.com> wrote:
Is there a TLS Alert = type that can be used by a TLS server to reject a TLS
client connection based on a per-IP-address connection limit?

The idea would be to have the server reject the connection before = spending
cycles on the TLS negotiation. But it's important to inform the client = why the
connection is rejected in order to reduce the number and severity of = support
calls that might be generated by such a limit if the connections were = silently
dropped.

Another case that's interesting is when the server is temporarily = overloaded
and wants to reserve CPU cycles for existing connections rather than = spending
cycles accepting new connections. Again, it's desirable to indicate to = the
client the cause of this connection failure in an attempt to reduce the = number
and severity of support calls and also desirable not to spend = unnecessary
server time on the TLS negotiation.

With the STARTTLS model, applications could just reject at the banner = with a
text error message. But with the separate-port-for-TLS model, this needs = to be
done in the TLS layer.

I didn't see appropriate alerts in RFC 5246 section 7.2.

Could alerts for these two cases be added as an extension or a TLS 1.3 = feature?

                - Chris

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

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

= --Apple-Mail=_FCC40987-7BB6-4258-BC2B-F27C1F76AF02-- From nobody Wed Apr 2 00:31: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 30A291A00CF for ; Wed, 2 Apr 2014 00:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 7yU80dood7JB for ; Wed, 2 Apr 2014 00:31:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA61A001B for ; Wed, 2 Apr 2014 00:31:25 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1WKD1z2XJQ-00B3MG; Wed, 02 Apr 2014 09:31:19 +0200 Message-ID: <533BBC3C.6000704@gmx.net> Date: Wed, 02 Apr 2014 09:29:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Watson Ladd , Dan Harkins References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="choMUv1WQK00xso4FKhcfHvGxc275Dije" X-Provags-ID: V03:K0:AE+RtDtc5Nl7mnXFzXAW4FlISi9KfaY5U0v5qTLHkqkGQ/zUNHY 4yNDXKtOCvww7yhaCunWtrUSBM3rejdBsjmO9tG+95zkotQTEo5PwgbXRVg4PFKG2JcWrE8 RCDCdjQXAiCzOKGfZ3KpeudNM2gj0Zv2aoECOkwApYsef25J8TTaylIZhGYXc7QGdWuDvqx 5jeeVSQd37CSeMsxCN6mg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6IbmZy2PB4bL71I3U0_JKhIUdiA Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 07:31:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --choMUv1WQK00xso4FKhcfHvGxc275Dije Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Watson, I believe there are several aspects that need to be untangled here: a) Is there a problem where a strong password-based authentication and key exchange protocol can help? b) Since there are various protocol variants available, which one is the best for the job? Item (a) is about use cases and clearly the Web is not the use case. There are use cases documented in http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I personally don't quite buy them. The constrained device use case is, however, one that I ran into myself as well. It requires a bit more description since constrained device are used in various different ways. There are at least three different cases I have seen: 1) Device talks to the cloud infrastructure. For this case it is not a problem to use long symmetric keys since the is nothing for the user to type. 2) Device talks to another device. There are two variants to this: 2a) Pairing / Imprinting Here the pairing protocol typically runs a Diffie-Hellman and then you might have to confirm the initial set-up to avoid MITM attacks (via an out-of-band channel, such as a human entering something). There are obviously many ways to do this pairing procedures and I am sure you have used many of them already yourself. Ekr provided a good overview for a workshop: http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricR= escorla.pdf 2b) Key printed on the device itself I believe that this is the case you are talking about where you want to avoid having users enter too many numbers. Today, user's are often only required to scan a QR code instead of entering something but maybe there is something to standardize here. Regarding item (b) about the protocol choice. Given the use cases previously described I doubt that the "database leaking secrets" is a bit concern here in these environments. The database in most cases contains a single key (or a small number of them). A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC 6124) and we picked EKE because the publications reached their 20 year anniversary. Just something to think about. Ciao Hannes On 04/02/2014 06:28 AM, Watson Ladd wrote: > Dear all, >=20 > I'm afraid that several important points and quite a bit of history > has been missing from the recent exchange concerning Dragonfly in TLS. >=20 > Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE has > a patent that expires in 2016, and a security proof in the ROM under a > DH style assumption and a reasonable ideal/real attack model. > Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to > authenticate nodes in a mesh network. It has no security proof despite > efforts to try and find one. >=20 > The intended usecase is provisioning of constrained devices. While one > could include a 128 bit key on each device and have users type it in > (as they do for Xbox Live and Windows verification: 25 letters and > numbers from a 32 bit alphabet) it was felt that this was a bit much. > PSK will not work with anything that isn't a key, because offline > attack works beautifully. Nico's concerns about key database > compromise, etc, are ignoring the realities of this setting: the > password is the least valuable thing on the device, and since it was > not entered by the user (as the device has no user interaction > capability) unlikely to be reused. >=20 > Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010. > There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE > is not specified on ECC groups, but this is easy to fix. (It's also > ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are not > on the agenda because of a rather heated controversy about how > Dragonfly got (seeming) CFRG approval, but there is a good case for > including them. On the web we have more of a problem due to the UI > issues that made client certificates a nonstarter. >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --choMUv1WQK00xso4FKhcfHvGxc275Dije Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTO7w8AAoJEGhJURNOOiAtnisH/2/hhKW6vcXBJbVYH7oh8/g8 Z4aOwTgYH0tRsAFgEzfT+/MNdURAJNqqibMR1PpTswiqauC19DHQ1s+tSR9J/8ER O4xn9ttVlqIAGr2Avl81X3pxEah9RExHuwof8QTdfvWdlfF5jT9fGxMeGFAznBSk eFEKbHz+sqHZQgAomFP4a3fLs0Al5uyHmRZ/dvdRd9vvhsFKrmB1cjMS8iVqSjuL RD8K5skm9/FruiLQaMXRG8MoyUda4Lb40F8Q9PZUEBwcUyXJ9b8cSHvMDkkV/4d/ v7X4q76zaTXbBJMui6/RF8fnVgNb09/2UNMI0zpDIlo3yqI7pQHRu3vK4kRj6GI= =EAqR -----END PGP SIGNATURE----- --choMUv1WQK00xso4FKhcfHvGxc275Dije-- From nobody Wed Apr 2 00:42: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 EE1161A0027 for ; Wed, 2 Apr 2014 00:42:39 -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 ZuIrySgE4_yt for ; Wed, 2 Apr 2014 00:42:35 -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 7E0701A001B for ; Wed, 2 Apr 2014 00:42:35 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so5079177wib.11 for ; Wed, 02 Apr 2014 00:42:31 -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=ztfwhBcCaFJopBTB9kehf6R7S7x2s2NEPPct7uhjh8M=; b=zi08zVLWHtAcwrna3nIuCJi/+yHpTto9e4p+UNe2jQaU81r0XGLj5rycz6o1G6XnRG 1l7GBI6tEVLs1xjl9ll3Ey8Dd7cCNXUkLw2bJqt+VmBFQfffMnD+rVJYAzNWJChgs+3l 2Ww4NMG1p2L2sWVJ/+keEzBb5S8yANNWsoj/ixOzgiVT/LAvHq55KEB8epPm0V+6BQlD 91Q8eFdLmS3yoZv1vv4ohpqH75VrTGa6wab0175sQCPImhHjt0d0vyzhshmKoT2qbeiA c+2ZsnWo28XWHj+ygX6y5BX04eP5S/5s7g9NTQLmAMjwX45QHM6Ok7hcCq4kCQnbdsGV zeZQ== X-Received: by 10.194.57.38 with SMTP id f6mr20147974wjq.59.1396424551282; Wed, 02 Apr 2014 00:42:31 -0700 (PDT) Received: from [192.168.1.99] (40.247.130.77.rev.sfr.net. [77.130.247.40]) by mx.google.com with ESMTPSA id gr2sm1682625wjc.12.2014.04.02.00.42.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 00:42:30 -0700 (PDT) Message-ID: <533BBF61.6060307@gmail.com> Date: Wed, 02 Apr 2014 09:42:25 +0200 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: "henry.story@bblfish.net" , TLS Mailing List References: <676D7423-514E-40A1-9CE5-DCBE3E5811FC@bblfish.net> In-Reply-To: <676D7423-514E-40A1-9CE5-DCBE3E5811FC@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qzflmo2T4mjaYP6A_rC4B-kMY7E Subject: Re: [TLS] registering x-509 mime types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 07:42:40 -0000 Henry, There was a looooooooong discussion about these types in PKIX but the WG rejected supporting existing practices and insisted that those who "violate" the standard (which came much too late) should be punished. That is, there *are* already IANA definitions for certificate MIME types, but they are hardly ever used. AFAIK, the "x-" actually means non-standard. Anders On 2014-04-02 08:30, henry.story@bblfish.net wrote: > Hi, > > The HTML5 keygen element [1] works by having the browser send a public key to the > server which can then return an X509 certificate back to the browser using one of the > following mime types [2] > > (a) application/x-x509-user-cert > (b) application/x-x509-ca-cert > (c) application/x-x509-email-cert > > This seems to work for most browsers - Safari, Chrome, Nescape, Opera - and has > been functioning like this since at least the year 2000 I think. The keygen tag > was only added to html officially a few years ago. > > What is missing though is that these mime types are not registered at IANA. > Is there anyone here ( or perhaps I should look somewhere else ) who would like > to register that at IANA? It would at least make it easier for developers building > web sites to work out what the correct mime type to use is. > > Perhaps one could also then get the html5 people to add a note about this > to their specification. > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-April/084613.html > > > Henry > > > [1] http://www.w3.org/html/wg/drafts/html/CR/forms.html#the-keygen-element > [2] https://wiki.mozilla.org/CA:Certificate_Download_Specification > [3] http://www.iana.org/assignments/media-types/media-types.xhtml > > Social Web Architect > http://bblfish.net/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 2 09:13: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 283401A0309 for ; Wed, 2 Apr 2014 09:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjGqZ3c-UzDz for ; Wed, 2 Apr 2014 09:13:09 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E121F1A0348 for ; Wed, 2 Apr 2014 09:12:16 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 1F5A843807E for ; Wed, 2 Apr 2014 09:12: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=l5c9KTXQwAkAITVyiM6B gQrtz/s=; b=uWgyea/am2rK3DsidiAJiR37H3vXttT77hajZ13z4I2w0HpiKtSq ky11I7pV7KzuFvXQXyQn4F/yQJENix/rYagO9gPxooRqmLiXHta2k0l+WLVPz7gc VdHL2rwfOixQMyDklfedfgtXcfNN57EpDODBBEq1jQAcqvmTo9AzONs= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id C380043807C for ; Wed, 2 Apr 2014 09:12:12 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so489268wes.30 for ; Wed, 02 Apr 2014 09:12:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.191.195 with SMTP id ha3mr1879243wjc.69.1396455131444; Wed, 02 Apr 2014 09:12:11 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 09:12:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Apr 2014 11:12:11 -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/FB-m9PYdUICcul2_0OxkuhV3Ro4 Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 16:13:14 -0000 On Tue, Apr 1, 2014 at 11:28 PM, Watson Ladd wrote: > The intended usecase is provisioning of constrained devices. While one > could include a 128 bit key on each device and have users type it in > (as they do for Xbox Live and Windows verification: 25 letters and > numbers from a 32 bit alphabet) it was felt that this was a bit much. > PSK will not work with anything that isn't a key, because offline > attack works beautifully. Nico's concerns about key database > compromise, etc, are ignoring the realities of this setting: the > password is the least valuable thing on the device, and since it was > not entered by the user (as the device has no user interaction > capability) unlikely to be reused. Ah, thanks for clarifying the context. I agree that in this context a ZKPP, unaugmented, is just fine. If I had to build one today I'd use EKE with a DJB cuve and Elligator: no patents apply and none are likely to apply (EKE's patent is expired, and it seems exceedingly unlikely that any patent covers the rest). Nico -- From nobody Wed Apr 2 09:14: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 D27251A0987 for ; Mon, 31 Mar 2014 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ydttgqOD2_jh for ; Mon, 31 Mar 2014 02:47:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6402B1A0901 for ; Mon, 31 Mar 2014 02:47:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4E4247FC387; Mon, 31 Mar 2014 02:46:58 -0700 (PDT) To: rohit@4K-associates.com, lawrence@agranat.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20140331094658.4E4247FC387@rfc-editor.org> Date: Mon, 31 Mar 2014 02:46:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0EoxaLXNFv_AmOCy2daSvqvmuq4 X-Mailman-Approved-At: Wed, 02 Apr 2014 09:14:25 -0700 Cc: rfc-editor@rfc-editor.org, fl.borchert@gmail.com, tls@ietf.org Subject: [TLS] [Editorial Errata Reported] RFC2817 (3941) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 09:47:03 -0000 The following errata report has been submitted for RFC2817, "Upgrading to TLS Within HTTP/1.1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2817&eid=3941 -------------------------------------- Type: Editorial Reported by: Florian Borchert Section: 3.1 Original Text ------------- Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be supplied within a Connection header field (section 14.10) Corrected Text -------------- The hyperlink (http://tools.ietf.org/html/rfc2817#section-14.10) to section 14.10 does not work, it should refer to RFC2616: http://tools.ietf.org/html/rfc2616#section-14.42 Notes ----- 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. -------------------------------------- RFC2817 (draft-ietf-tls-http-upgrade-05) -------------------------------------- Title : Upgrading to TLS Within HTTP/1.1 Publication Date : May 2000 Author(s) : R. Khare, S. Lawrence Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 2 09:39: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 8026F1A026D for ; Wed, 2 Apr 2014 09:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 pGRUd-c2f5qw for ; Wed, 2 Apr 2014 09:39:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4FB1A0232 for ; Wed, 2 Apr 2014 09:39:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2DA51A888016; Wed, 2 Apr 2014 09:38:59 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 09:38:59 -0700 (PDT) Message-ID: <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> In-Reply-To: <533BBC3C.6000704@gmx.net> References: <533BBC3C.6000704@gmx.net> Date: Wed, 2 Apr 2014 09:38:59 -0700 (PDT) From: "Dan Harkins" To: "Hannes Tschofenig" 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/Kg-59nF-owRIrh2gjBcFC8sj13s Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 16:39:07 -0000 Hi Hannes, On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote: > Hi Watson, > > I believe there are several aspects that need to be untangled here: > > a) Is there a problem where a strong password-based authentication and > key exchange protocol can help? > > b) Since there are various protocol variants available, which one is the > best for the job? > > Item (a) is about use cases and clearly the Web is not the use case. > There are use cases documented in > http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I > personally don't quite buy them. > > The constrained device use case is, however, one that I ran into myself > as well. It requires a bit more description since constrained device are > used in various different ways. There are at least three different cases > I have seen: > > 1) Device talks to the cloud infrastructure. For this case it is not a > problem to use long symmetric keys since the is nothing for the user to > type. From what authenticated source does this long symmetric key come? > 2) Device talks to another device. There are two variants to this: > > 2a) Pairing / Imprinting > > Here the pairing protocol typically runs a Diffie-Hellman and then you > might have to confirm the initial set-up to avoid MITM attacks (via an > out-of-band channel, such as a human entering something). The "something" the user enters is a simple, low-entropy, easy-to-enter key. That key authenticates a PAKE exchange. > There are obviously many ways to do this pairing procedures and I am > sure you have used many of them already yourself. > > Ekr provided a good overview for a workshop: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf And the use of PAKEs is mentioned there. The downside to PAKEs, according to Eric, is use of public key cryptography with a constrained device that is assumed to have limited CPU power. And that's why ECC support in a PAKE is so crucial. > 2b) Key printed on the device itself > > I believe that this is the case you are talking about where you want to > avoid having users enter too many numbers. Today, user's are often only > required to scan a QR code instead of entering something but maybe there > is something to standardize here. Putting a symmetric key in a QR code is a bad idea. Anybody who sees the QR code can determine the secret. As Eric said in the paper you referred to above, "The primary concern with a secret value system is that the value must be kept secret or an attacker can impersonate the base station to the device and vice versa." Indeed. Putting a public key in a QR code is a much better idea (and, again, ECC support is crucial because the x-coordinate of a point on a 256-bit curve produces a usable QR code while a 4096-bit RSA key does not-- too big, too dense, hard-to-impossible to scan). For many devices, though, this only provides one way authentication (not mutual) because the device that scanned the QR code knows definitely it is talking to the device whose QR code was scanned, but the device with the QR code has no idea who it is communicating with. Using a short, easy-to-enter key with a PAKE provides good mutual authentication. Also not every constrained device has a camera interface to scan QR codes with, while many of them do have some limited UI from which the user can enter a short key. > Regarding item (b) about the protocol choice. Given the use cases > previously described I doubt that the "database leaking secrets" is a > bit concern here in these environments. The database in most cases > contains a single key (or a small number of them). Yes, that is correct. A large password database is not envisioned by this use case. In fact, as The whole benefit of an augmented PAKE-- a protected password database-- is not applicable to this use case. > A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC > 6124) and we picked EKE because the publications reached their 20 year > anniversary. I remember it well. I wrote EAP-pwd (dragonfly) and Yaron followed with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followed with an EKE exchange (which was later abandoned). One of the problems with EKE is that using it with ECC opens the exchange up to a partitioning attack. regards, Dan. > Just something to think about. > > Ciao > Hannes > > > On 04/02/2014 06:28 AM, Watson Ladd wrote: >> Dear all, >> >> I'm afraid that several important points and quite a bit of history >> has been missing from the recent exchange concerning Dragonfly in TLS. >> >> Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE has >> a patent that expires in 2016, and a security proof in the ROM under a >> DH style assumption and a reasonable ideal/real attack model. >> Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to >> authenticate nodes in a mesh network. It has no security proof despite >> efforts to try and find one. >> >> The intended usecase is provisioning of constrained devices. While one >> could include a 128 bit key on each device and have users type it in >> (as they do for Xbox Live and Windows verification: 25 letters and >> numbers from a 32 bit alphabet) it was felt that this was a bit much. >> PSK will not work with anything that isn't a key, because offline >> attack works beautifully. Nico's concerns about key database >> compromise, etc, are ignoring the realities of this setting: the >> password is the least valuable thing on the device, and since it was >> not entered by the user (as the device has no user interaction >> capability) unlikely to be reused. >> >> Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010. >> There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE >> is not specified on ECC groups, but this is easy to fix. (It's also >> ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are not >> on the agenda because of a rather heated controversy about how >> Dragonfly got (seeming) CFRG approval, but there is a good case for >> including them. On the web we have more of a problem due to the UI >> issues that made client certificates a nonstarter. >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From nobody Wed Apr 2 09: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 471951A0298 for ; Wed, 2 Apr 2014 09:43:53 -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 Kneyr45Xpcw1 for ; Wed, 2 Apr 2014 09:43:47 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id D83A71A0254 for ; Wed, 2 Apr 2014 09:43:46 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 84F191C21B1; Wed, 2 Apr 2014 18:43:41 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 4561A1FE0215; Wed, 2 Apr 2014 18:43:41 +0200 (CEST) Date: Wed, 2 Apr 2014 18:43:40 +0200 From: Kurt Roeckx To: Simon Josefsson Message-ID: <20140402164340.GA14790@roeckx.be> References: <87ob3456s1.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ob3456s1.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WTS_7-VBcqt5DDWewrU0iDNlU9k Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 02 Apr 2014 16:43:53 -0000 On Wed, Jan 22, 2014 at 05:18:54PM +0100, Simon Josefsson wrote: > > 1) Curve25519 for TLS. This was the original scope of the draft. The > URL is: . As > far as I know, there are no outstanding issues, and it is possible to > implement and deploy Curve25519 in TLS following the draft. Please > prove me wrong with comments or preferrably patches to the draft. So what's the status of this? Kurt From nobody Wed Apr 2 09:46: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 271B91A0242 for ; Wed, 2 Apr 2014 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 GvsqNaeXSIXW for ; Wed, 2 Apr 2014 09:45:56 -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 969F81A0232 for ; Wed, 2 Apr 2014 09:45:56 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so429025yks.19 for ; Wed, 02 Apr 2014 09:45: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; bh=kDhdcthnKDHjSCJoHSmnM1b/eE0vygMVN0LouIlIudo=; b=g+GF1rxmSuB3j4eyX7LxGz7vGIM6bysGsCBXIliICRixuQFxb/wM1wF+Qco+je8HxG yHqPDoFCog573JLWAozdJYIRvINag6b2oVV9JA+v+NUavL4OS2QccFu50jhuXSHDl/Ub oQvKFkjBUeHD0DOIzuSN4ecMM7rnf8ahqYOqyPlhySOLS1//Sp5IMmy0p0rgn2Hr8Pd7 TVUP95XCkCzcrYsRT6omDqlWo0U0ubHJ43uzPC7wEluPZ8zDgvZgRkx7p6RBwttjcMsi vvHZzqNawMXCJV3E3tj81kPu72OsP3iNIpFKLQ4vVzbYqVCtFsPgt3Gpa2QPQZD3K97+ ALcQ== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr1933477yhn.87.1396457152568; Wed, 02 Apr 2014 09:45:52 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 2 Apr 2014 09:45:52 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 2 Apr 2014 09:45:52 -0700 (PDT) In-Reply-To: <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 09:45:52 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: multipart/alternative; boundary=089e0160bea685ff0304f6120440 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KGKmeBoyZOBJcUmAPMmUsmL7e5g Cc: tls@ietf.org Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 16:46:01 -0000 --089e0160bea685ff0304f6120440 Content-Type: text/plain; charset=UTF-8 On Apr 2, 2014 9:39 AM, "Dan Harkins" wrote: > > > Hi Hannes, > > On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote: > > Hi Watson, > > > > I believe there are several aspects that need to be untangled here: > > > > a) Is there a problem where a strong password-based authentication and > > key exchange protocol can help? > > > > b) Since there are various protocol variants available, which one is the > > best for the job? > > > > Item (a) is about use cases and clearly the Web is not the use case. > > There are use cases documented in > > http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I > > personally don't quite buy them. > > > > The constrained device use case is, however, one that I ran into myself > > as well. It requires a bit more description since constrained device are > > used in various different ways. There are at least three different cases > > I have seen: > > > > 1) Device talks to the cloud infrastructure. For this case it is not a > > problem to use long symmetric keys since the is nothing for the user to > > type. > > From what authenticated source does this long symmetric key come? The manufacturer. > > > 2) Device talks to another device. There are two variants to this: > > > > 2a) Pairing / Imprinting > > > > Here the pairing protocol typically runs a Diffie-Hellman and then you > > might have to confirm the initial set-up to avoid MITM attacks (via an > > out-of-band channel, such as a human entering something). > > The "something" the user enters is a simple, low-entropy, easy-to-enter > key. That key authenticates a PAKE exchange. > > > There are obviously many ways to do this pairing procedures and I am > > sure you have used many of them already yourself. > > > > Ekr provided a good overview for a workshop: > > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf > > And the use of PAKEs is mentioned there. The downside to PAKEs, according > to Eric, is use of public key cryptography with a constrained device that is > assumed to have limited CPU power. And that's why ECC support in a PAKE > is so crucial. > > > 2b) Key printed on the device itself > > > > I believe that this is the case you are talking about where you want to > > avoid having users enter too many numbers. Today, user's are often only > > required to scan a QR code instead of entering something but maybe there > > is something to standardize here. > > Putting a symmetric key in a QR code is a bad idea. Anybody who > sees the QR code can determine the secret. As Eric said in the paper > you referred to above, "The primary concern with a secret value system > is that the value must be kept secret or an attacker can impersonate the > base station to the device and vice versa." Indeed. > > Putting a public key in a QR code is a much better idea (and, again, > ECC support is crucial because the x-coordinate of a point on a 256-bit > curve produces a usable QR code while a 4096-bit RSA key does not-- too > big, too dense, hard-to-impossible to scan). For many devices, though, this > only provides one way authentication (not mutual) because the device that > scanned the QR code knows definitely it is talking to the device whose QR > code was scanned, but the device with the QR code has no idea who it is > communicating with. Using a short, easy-to-enter key with a PAKE > provides good mutual authentication. > > Also not every constrained device has a camera interface to scan QR > codes with, while many of them do have some limited UI from which > the user can enter a short key. > > > Regarding item (b) about the protocol choice. Given the use cases > > previously described I doubt that the "database leaking secrets" is a > > bit concern here in these environments. The database in most cases > > contains a single key (or a small number of them). > > Yes, that is correct. A large password database is not envisioned by > this use case. In fact, as The whole benefit of an augmented PAKE-- > a protected password database-- is not applicable to this use case. > > > A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC > > 6124) and we picked EKE because the publications reached their 20 year > > anniversary. > > I remember it well. I wrote EAP-pwd (dragonfly) and Yaron followed > with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followed > with an EKE exchange (which was later abandoned). > > One of the problems with EKE is that using it with ECC opens the > exchange up to a partitioning attack. Not if you use a uniform representation like Elligator. > > regards, > > Dan. > > > Just something to think about. > > > > Ciao > > Hannes > > > > > > On 04/02/2014 06:28 AM, Watson Ladd wrote: > >> Dear all, > >> > >> I'm afraid that several important points and quite a bit of history > >> has been missing from the recent exchange concerning Dragonfly in TLS. > >> > >> Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE has > >> a patent that expires in 2016, and a security proof in the ROM under a > >> DH style assumption and a reasonable ideal/real attack model. > >> Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to > >> authenticate nodes in a mesh network. It has no security proof despite > >> efforts to try and find one. > >> > >> The intended usecase is provisioning of constrained devices. While one > >> could include a 128 bit key on each device and have users type it in > >> (as they do for Xbox Live and Windows verification: 25 letters and > >> numbers from a 32 bit alphabet) it was felt that this was a bit much. > >> PSK will not work with anything that isn't a key, because offline > >> attack works beautifully. Nico's concerns about key database > >> compromise, etc, are ignoring the realities of this setting: the > >> password is the least valuable thing on the device, and since it was > >> not entered by the user (as the device has no user interaction > >> capability) unlikely to be reused. > >> > >> Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010. > >> There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE > >> is not specified on ECC groups, but this is easy to fix. (It's also > >> ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are not > >> on the agenda because of a rather heated controversy about how > >> Dragonfly got (seeming) CFRG approval, but there is a good case for > >> including them. On the web we have more of a problem due to the UI > >> issues that made client certificates a nonstarter. > >> > >> Sincerely, > >> Watson Ladd > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > > > --089e0160bea685ff0304f6120440 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2014 9:39 AM, "Dan Harkins" <dharkins@lounge.org> wrote:
>
>
> =C2=A0 Hi Hannes,
>
> On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote:
> > Hi Watson,
> >
> > I believe there are several aspects that need to be untangled her= e:
> >
> > a) Is there a problem where a strong password-based authenticatio= n and
> > key exchange protocol can help?
> >
> > b) Since there are various protocol variants available, which one= is the
> > best for the job?
> >
> > Item (a) is about use cases and clearly the Web is not the use ca= se.
> > There are use cases documented in
> > http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 bu= t I
> > personally don't quite buy them.
> >
> > The constrained device use case is, however, one that I ran into = myself
> > as well. It requires a bit more description since constrained dev= ice are
> > used in various different ways. There are at least three differen= t cases
> > I have seen:
> >
> > 1) Device talks to the cloud infrastructure. For this case it is = not a
> > problem to use long symmetric keys since the is nothing for the u= ser to
> > type.
>
> =C2=A0 From what authenticated source does this long symmetric key com= e?

The manufacturer.
>
> > 2) Device talks to another device. There are two variants to this= :
> >
> > =C2=A02a) Pairing / Imprinting
> >
> > Here the pairing protocol typically runs a Diffie-Hellman and the= n you
> > might have to confirm the initial set-up to avoid MITM attacks (v= ia an
> > out-of-band channel, such as a human entering something).
>
> =C2=A0 The "something" the user enters is a simple, low-entr= opy, easy-to-enter
> key. That key authenticates a PAKE exchange.
>
> > There are obviously many ways to do this pairing procedures and I= am
> > sure you have used many of them already yourself.
> >
> > Ekr provided a good overview for a workshop:
> > http://www.lix.polytechnique.fr/hipercom/Sm= artObjectSecurity/papers/EricRescorla.pdf
>
> =C2=A0 And the use of PAKEs is mentioned there. The downside to PAKEs,= according
> to Eric, is use of public key cryptography with a constrained device t= hat is
> assumed to have limited CPU power. And that's why ECC support in a= PAKE
> is so crucial.
>
> > =C2=A02b) Key printed on the device itself
> >
> > I believe that this is the case you are talking about where you w= ant to
> > avoid having users enter too many numbers. Today, user's are = often only
> > required to scan a QR code instead of entering something but mayb= e there
> > is something to standardize here.
>
> =C2=A0 Putting a symmetric key in a QR code is a bad idea. Anybody who=
> sees the QR code can determine the secret. As Eric said in the paper > you referred to above, "The primary concern with a secret value s= ystem
> is that the value must be kept secret or an attacker can impersonate t= he
> base station to the device and vice versa." Indeed.
>
> =C2=A0 Putting a public key in a QR code is a much better idea (and, a= gain,
> ECC support is crucial because the x-coordinate of a point on a 256-bi= t
> curve produces a usable QR code while a 4096-bit RSA key does not-- to= o
> big, too dense, hard-to-impossible to scan). For many devices, though,= this
> only provides one way authentication (not mutual) because the device t= hat
> scanned the QR code knows definitely it is talking to the device whose= QR
> code was scanned, but the device with the QR code has no idea who it i= s
> communicating with. Using a short, easy-to-enter key with a PAKE
> provides good mutual authentication.
>
> =C2=A0 Also not every constrained device has a camera interface to sca= n QR
> codes with, while many of them do have some limited UI from which
> the user can enter a short key.
>
> > Regarding item (b) about the protocol choice. Given the use cases=
> > previously described I doubt that the "database leaking secr= ets" is a
> > bit concern here in these environments. The database in most case= s
> > contains a single key (or a small number of them).
>
> =C2=A0 Yes, that is correct. A large password database is not envision= ed by
> this use case. In fact, as The whole benefit of an augmented PAKE-- > a protected password database-- is not applicable to this use case. >
> > A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE= (RFC
> > 6124) and we picked EKE because the publications reached their 20= year
> > anniversary.
>
> =C2=A0 I remember it well. I wrote EAP-pwd (dragonfly) and Yaron follo= wed
> with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followe= d
> with an EKE exchange (which was later abandoned).
>
> =C2=A0 One of the problems with EKE is that using it with ECC opens th= e
> exchange up to a partitioning attack.

Not if you use a uniform representation like Elligator.

>
> =C2=A0 regards,
>
> =C2=A0 Dan.
>
> > Just something to think about.
> >
> > Ciao
> > Hannes
> >
> >
> > On 04/02/2014 06:28 AM, Watson Ladd wrote:
> >> Dear all,
> >>
> >> I'm afraid that several important points and quite a bit = of history
> >> has been missing from the recent exchange concerning Dragonfl= y in TLS.
> >>
> >> Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. = SPEKE has
> >> a patent that expires in 2016, and a security proof in the RO= M under a
> >> DH style assumption and a reasonable ideal/real attack model.=
> >> Dragonfly was created by Dan Harkins, and adopted in IEEE 802= .11s to
> >> authenticate nodes in a mesh network. It has no security proo= f despite
> >> efforts to try and find one.
> >>
> >> The intended usecase is provisioning of constrained devices. = While one
> >> could include a 128 bit key on each device and have users typ= e it in
> >> (as they do for Xbox Live and Windows verification: 25 letter= s and
> >> numbers from a 32 bit alphabet) it was felt that this was a b= it much.
> >> PSK will not work with anything that isn't a key, because= offline
> >> attack works beautifully. Nico's concerns about key datab= ase
> >> compromise, etc, are ignoring the realities of this setting: = the
> >> password is the least valuable thing on the device, and since= it was
> >> not entered by the user (as the device has no user interactio= n
> >> capability) unlikely to be reused.
> >>
> >> Dragonfly was presented at IETF 83. AugPAKE was proven secure= in 2010.
> >> There is currently a draft for AugPAKE in TLS. Unfortunately = AugPAKE
> >> is not specified on ECC groups, but this is easy to fix. (It&= #39;s also
> >> ugly to shoehorn into TLS, but the draft seems to do it) PAKE= s are not
> >> on the agenda because of a rather heated controversy about ho= w
> >> Dragonfly got (seeming) CFRG approval, but there is a good ca= se for
> >> including them. On the web we have more of a problem due to t= he UI
> >> issues that made client certificates a nonstarter.
> >>
> >> Sincerely,
> >> Watson Ladd
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https:/= /www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
>

--089e0160bea685ff0304f6120440-- From nobody Wed Apr 2 09:46: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 1B7E61A0232 for ; Wed, 2 Apr 2014 09:46:35 -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 mw73m7iqZaXY for ; Wed, 2 Apr 2014 09:46:31 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4001A0242 for ; Wed, 2 Apr 2014 09:46:31 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 980E31DE05D for ; Wed, 2 Apr 2014 09:46:27 -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=lrSsgqLlKxnftYSzTmT6 LhUFoSI=; b=cjZZXP+Wn6eFTvI4S1kWUL4e2HbKlTsvJjbi9jTLNvzmfllbVZPc +3pHiP1taSiqUmYsn2zizn3FxBt/PX86jIP0lskfuM9K4pfW69MizHSP6Bf58PME eKmC6XQi7Hxmp3MqbmKiG+CtHx8jLwDcyB2KjIztfYotEC82XsNQ0Ds= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 3EEBF1DE059 for ; Wed, 2 Apr 2014 09:46:26 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so524456wes.38 for ; Wed, 02 Apr 2014 09:46:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr3605167wib.42.1396457185704; Wed, 02 Apr 2014 09:46:25 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 09:46:25 -0700 (PDT) In-Reply-To: <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 11:46:25 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e9OR1DB-t0oiMEMRXMGPQVWkhUY Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 16:46:35 -0000 On Wed, Apr 2, 2014 at 11:38 AM, Dan Harkins wrote: > One of the problems with EKE is that using it with ECC opens the > exchange up to a partitioning attack. Very much so. For example, EKE with curve25519 allows eavesdroppers to eliminate 7/8ths of possible passwords for each exchange observed (that's a different 7/8ths of possible passwords in each exchange). After a few exchanges the attacker can recover the password with very high confidence. For some ECC curves the solution is Elligator. This is quite convenient because EKE w/ ECC and Elligator is to a very high likelihood not subject to any patents whatsoever. Nico -- From nobody Wed Apr 2 09:51: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 66AD71A02CB for ; Wed, 2 Apr 2014 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 i9Ua4LktloqL for ; Wed, 2 Apr 2014 09:51:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id CC66F1A0254 for ; Wed, 2 Apr 2014 09:51:33 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LtmK9-1XCfqf1T65-011Cao; Wed, 02 Apr 2014 18:51:28 +0200 Message-ID: <533C3D12.7040802@gmx.net> Date: Wed, 02 Apr 2014 18:38:42 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dan Harkins References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> In-Reply-To: <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iMP4C3a7SHHRucdD66L3hU86pPnHN57ob" X-Provags-ID: V03:K0:F+T74XR/7S4mQjUggtdUc34d8vPVajDDzHB1tv6VH8K3Qee6/Lm hryeIetem6Su8maFmzgyI+OHnBhzkxEULVfxaef4Q+mzuhGdVm1lPgmSiykhl/FaL5WnkpL qKN/Q+4aau0Ww1+uc1+zrvE0YwmFu0K8GO//xH8nNOK52rb+UBuMpT6gFFPX7hf+gjokgNP yrfXoKoq1Won+enOBlKvw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/opk-qawRr9_ycxTtsWw1lBg2h6U Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 16:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iMP4C3a7SHHRucdD66L3hU86pPnHN57ob Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dan, comments inline. On 04/02/2014 06:38 PM, Dan Harkins wrote: >=20 > Hi Hannes, >=20 > On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote: >> Hi Watson, >> >> I believe there are several aspects that need to be untangled here: >> >> a) Is there a problem where a strong password-based authentication and= >> key exchange protocol can help? >> >> b) Since there are various protocol variants available, which one is t= he >> best for the job? >> >> Item (a) is about use cases and clearly the Web is not the use case. >> There are use cases documented in >> http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I >> personally don't quite buy them. >> >> The constrained device use case is, however, one that I ran into mysel= f >> as well. It requires a bit more description since constrained device a= re >> used in various different ways. There are at least three different cas= es >> I have seen: >> >> 1) Device talks to the cloud infrastructure. For this case it is not a= >> problem to use long symmetric keys since the is nothing for the user t= o >> type. >=20 > From what authenticated source does this long symmetric key come? >=20 This secret is pre-provisioned by the manufacturer of the device. If you buy any IoT device today this is most likely the model they are using. >> 2) Device talks to another device. There are two variants to this: >> >> 2a) Pairing / Imprinting >> >> Here the pairing protocol typically runs a Diffie-Hellman and then you= >> might have to confirm the initial set-up to avoid MITM attacks (via an= >> out-of-band channel, such as a human entering something). >=20 > The "something" the user enters is a simple, low-entropy, easy-to-ent= er > key. That key authenticates a PAKE exchange. Nope, this is not necessarily PAKE and the if you, fo rexample, use Bluetooth it is not PAKE. >=20 >> There are obviously many ways to do this pairing procedures and I am >> sure you have used many of them already yourself. >> >> Ekr provided a good overview for a workshop: >> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/Er= icRescorla.pdf >=20 > And the use of PAKEs is mentioned there. The downside to PAKEs, accor= ding > to Eric, is use of public key cryptography with a constrained device th= at is > assumed to have limited CPU power. And that's why ECC support in a PAKE= > is so crucial. + patents on ECC and patents on PAKE to worry about... >=20 >> 2b) Key printed on the device itself >> >> I believe that this is the case you are talking about where you want t= o >> avoid having users enter too many numbers. Today, user's are often onl= y >> required to scan a QR code instead of entering something but maybe the= re >> is something to standardize here. >=20 > Putting a symmetric key in a QR code is a bad idea. Anybody who > sees the QR code can determine the secret. This is the model that many embedded devices use. Look at your embedded router, for example. I doubt that someone breaks into your home and then has nothing better to do than to read the secret from your home router...= > As Eric said in the paper > you referred to above, "The primary concern with a secret value system > is that the value must be kept secret or an attacker can impersonate th= e > base station to the device and vice versa." Indeed. >=20 > Putting a public key in a QR code is a much better idea (and, again, > ECC support is crucial because the x-coordinate of a point on a 256-bit= > curve produces a usable QR code while a 4096-bit RSA key does not-- too= > big, too dense, hard-to-impossible to scan). For many devices, though, = this > only provides one way authentication (not mutual) because the device th= at > scanned the QR code knows definitely it is talking to the device whose = QR > code was scanned, but the device with the QR code has no idea who it is= > communicating with. Using a short, easy-to-enter key with a PAKE > provides good mutual authentication. >=20 > Also not every constrained device has a camera interface to scan QR > codes with, while many of them do have some limited UI from which > the user can enter a short key. Understand that argument but nothing of it can be found in your draft. >=20 >> Regarding item (b) about the protocol choice. Given the use cases >> previously described I doubt that the "database leaking secrets" is a >> bit concern here in these environments. The database in most cases >> contains a single key (or a small number of them). >=20 > Yes, that is correct. A large password database is not envisioned by > this use case. In fact, as The whole benefit of an augmented PAKE-- > a protected password database-- is not applicable to this use case. Yes. >=20 >> A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC= >> 6124) and we picked EKE because the publications reached their 20 year= >> anniversary. >=20 > I remember it well. I wrote EAP-pwd (dragonfly) and Yaron followed > with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followed= > with an EKE exchange (which was later abandoned). >=20 > One of the problems with EKE is that using it with ECC opens the > exchange up to a partitioning attack. Given that this initial exchange happens very infrequently additional delay with RSA does not matter that much (+ you don't have to worry about the IPRs). Ciao Hannes >=20 > regards, >=20 > Dan. >=20 >> Just something to think about. >> >> Ciao >> Hannes >> >> >> On 04/02/2014 06:28 AM, Watson Ladd wrote: >>> Dear all, >>> >>> I'm afraid that several important points and quite a bit of history >>> has been missing from the recent exchange concerning Dragonfly in TLS= =2E >>> >>> Dragonfly is a modified SPEKE. SPEKE was introduced in 2001. SPEKE ha= s >>> a patent that expires in 2016, and a security proof in the ROM under = a >>> DH style assumption and a reasonable ideal/real attack model. >>> Dragonfly was created by Dan Harkins, and adopted in IEEE 802.11s to >>> authenticate nodes in a mesh network. It has no security proof despit= e >>> efforts to try and find one. >>> >>> The intended usecase is provisioning of constrained devices. While on= e >>> could include a 128 bit key on each device and have users type it in >>> (as they do for Xbox Live and Windows verification: 25 letters and >>> numbers from a 32 bit alphabet) it was felt that this was a bit much.= >>> PSK will not work with anything that isn't a key, because offline >>> attack works beautifully. Nico's concerns about key database >>> compromise, etc, are ignoring the realities of this setting: the >>> password is the least valuable thing on the device, and since it was >>> not entered by the user (as the device has no user interaction >>> capability) unlikely to be reused. >>> >>> Dragonfly was presented at IETF 83. AugPAKE was proven secure in 2010= =2E >>> There is currently a draft for AugPAKE in TLS. Unfortunately AugPAKE >>> is not specified on ECC groups, but this is easy to fix. (It's also >>> ugly to shoehorn into TLS, but the draft seems to do it) PAKEs are no= t >>> on the agenda because of a rather heated controversy about how >>> Dragonfly got (seeming) CFRG approval, but there is a good case for >>> including them. On the web we have more of a problem due to the UI >>> issues that made client certificates a nonstarter. >>> >>> Sincerely, >>> Watson Ladd >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >=20 --iMP4C3a7SHHRucdD66L3hU86pPnHN57ob Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTPD0SAAoJEGhJURNOOiAthSAH/2PXKtCACvgjGgw5K+Hcx2R5 LWmPzBzLrRg5maED2ap3UmxRl9RZPMd7gN82GLXgk2/6fvLr2TuYtRn6I1zOf6kY SXx7fvrK0wgwe9t9wxXmNki52GJULlefOruS4GW+RlEdyHXkd9+99RUgEA3WrHRw O0YPvQdSy16B+/4KpTp1eu13qcsOA5DY7b5dbdEQ+FofZPE/C0GdRYEDdBX5tTtL zMgU3gmSsOkJTDWqJ84i+Xts47Gu2w/NPRAOuMlhXGuax3CoZJ5zRtm91aNF5FEL 7n+0/p07WybdjN83LWFvo19SMWa3FAloRFmDRokCd54aewZBFUScU1TAAWR0Ycw= =/V3h -----END PGP SIGNATURE----- --iMP4C3a7SHHRucdD66L3hU86pPnHN57ob-- From nobody Wed Apr 2 10:20: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 0536F1A032D for ; Wed, 2 Apr 2014 10:20:00 -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 nFU3pIG1bYVl for ; Wed, 2 Apr 2014 10:19:55 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA61A0332 for ; Wed, 2 Apr 2014 10:18:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CB844A888016; Wed, 2 Apr 2014 10:18:26 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 10:18:27 -0700 (PDT) Message-ID: <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> In-Reply-To: <533C3D12.7040802@gmx.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> Date: Wed, 2 Apr 2014 10:18:27 -0700 (PDT) From: "Dan Harkins" To: "Hannes Tschofenig" 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/1orb98vGwuAUyYTONQYAh1t5390 Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 17:20:00 -0000 Hi Hannes, On Wed, April 2, 2014 9:38 am, Hannes Tschofenig wrote: > Hi Dan, > > comments inline. > > > On 04/02/2014 06:38 PM, Dan Harkins wrote: >> >> Hi Hannes, >> >> On Wed, April 2, 2014 12:29 am, Hannes Tschofenig wrote: >>> Hi Watson, >>> >>> I believe there are several aspects that need to be untangled here: >>> >>> a) Is there a problem where a strong password-based authentication and >>> key exchange protocol can help? >>> >>> b) Since there are various protocol variants available, which one is >>> the >>> best for the job? >>> >>> Item (a) is about use cases and clearly the Web is not the use case. >>> There are use cases documented in >>> http://tools.ietf.org/html/draft-ietf-tls-pwd-04#section-1.1 but I >>> personally don't quite buy them. >>> >>> The constrained device use case is, however, one that I ran into myself >>> as well. It requires a bit more description since constrained device >>> are >>> used in various different ways. There are at least three different >>> cases >>> I have seen: >>> >>> 1) Device talks to the cloud infrastructure. For this case it is not a >>> problem to use long symmetric keys since the is nothing for the user to >>> type. >> >> From what authenticated source does this long symmetric key come? >> > > This secret is pre-provisioned by the manufacturer of the device. > If you buy any IoT device today this is most likely the model they are > using. It's the symmetric equivalent of a manufacturing certificate. This has its place but that place is not here. >>> 2) Device talks to another device. There are two variants to this: >>> >>> 2a) Pairing / Imprinting >>> >>> Here the pairing protocol typically runs a Diffie-Hellman and then you >>> might have to confirm the initial set-up to avoid MITM attacks (via an >>> out-of-band channel, such as a human entering something). >> >> The "something" the user enters is a simple, low-entropy, >> easy-to-enter >> key. That key authenticates a PAKE exchange. > > Nope, this is not necessarily PAKE and the if you, fo rexample, use > Bluetooth it is not PAKE. Bluetooth is not secure. What I am proposing is to use a secure PAKE, not something insecure. >> >>> There are obviously many ways to do this pairing procedures and I am >>> sure you have used many of them already yourself. >>> >>> Ekr provided a good overview for a workshop: >>> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/EricRescorla.pdf >> >> And the use of PAKEs is mentioned there. The downside to PAKEs, >> according >> to Eric, is use of public key cryptography with a constrained device >> that is >> assumed to have limited CPU power. And that's why ECC support in a PAKE >> is so crucial. > > + patents on ECC and patents on PAKE to worry about... FUD. There are no patents to worry about with TLS-pwd. >>> 2b) Key printed on the device itself >>> >>> I believe that this is the case you are talking about where you want to >>> avoid having users enter too many numbers. Today, user's are often only >>> required to scan a QR code instead of entering something but maybe >>> there >>> is something to standardize here. >> >> Putting a symmetric key in a QR code is a bad idea. Anybody who >> sees the QR code can determine the secret. > > This is the model that many embedded devices use. Look at your embedded > router, for example. I doubt that someone breaks into your home and then > has nothing better to do than to read the secret from your home router... They wouldn't need to since the protocol that uses that symmetric key on my home router is horribly broken. You keep bringing up broken uses of symmetric keys (bluetooth, WPS) as alternatives to doing it right. I'm having a hard time understanding what is motivating you here. >> As Eric said in the paper >> you referred to above, "The primary concern with a secret value system >> is that the value must be kept secret or an attacker can impersonate the >> base station to the device and vice versa." Indeed. >> >> Putting a public key in a QR code is a much better idea (and, again, >> ECC support is crucial because the x-coordinate of a point on a 256-bit >> curve produces a usable QR code while a 4096-bit RSA key does not-- too >> big, too dense, hard-to-impossible to scan). For many devices, though, >> this >> only provides one way authentication (not mutual) because the device >> that >> scanned the QR code knows definitely it is talking to the device whose >> QR >> code was scanned, but the device with the QR code has no idea who it is >> communicating with. Using a short, easy-to-enter key with a PAKE >> provides good mutual authentication. >> >> Also not every constrained device has a camera interface to scan QR >> codes with, while many of them do have some limited UI from which >> the user can enter a short key. > > Understand that argument but nothing of it can be found in your draft. I didn't think an expansive explanation of use cases was appropriate for a draft that defines a protocol. I can provide a bit more introductory text as well as an "applicability statement" if it will help. (I am currently rethinking my opinions on use case documents since people really seem to not understand the motivation for TLS-pwd. I have done a very poor job on that front). >> >>> Regarding item (b) about the protocol choice. Given the use cases >>> previously described I doubt that the "database leaking secrets" is a >>> bit concern here in these environments. The database in most cases >>> contains a single key (or a small number of them). >> >> Yes, that is correct. A large password database is not envisioned by >> this use case. In fact, as The whole benefit of an augmented PAKE-- >> a protected password database-- is not applicable to this use case. > > Yes. > >> >>> A few years ago Yaron, Glen, Scott and myself co-authored EAP-EKE (RFC >>> 6124) and we picked EKE because the publications reached their 20 year >>> anniversary. >> >> I remember it well. I wrote EAP-pwd (dragonfly) and Yaron followed >> with EAP-EKE, I proposed a dragonfly exchange in IKE and Yaron followed >> with an EKE exchange (which was later abandoned). >> >> One of the problems with EKE is that using it with ECC opens the >> exchange up to a partitioning attack. > Given that this initial exchange happens very infrequently additional > delay with RSA does not matter that much (+ you don't have to worry > about the IPRs). EKE doesn't do RSA. And, as Nico pointed out, observing a single exchange can eliminate a large majority of the potential passwords. Even an infrequent use can give an adversary a high probability of successfully determining the secret. Again, the IPR issue is FUD. regards, Dan. From nobody Wed Apr 2 10:26: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 BE21A1A024D for ; Wed, 2 Apr 2014 10:26:40 -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 dmyWmYsKb1YQ for ; Wed, 2 Apr 2014 10:26:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E2B511A0242 for ; Wed, 2 Apr 2014 10:26:36 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 323D32C806D for ; Wed, 2 Apr 2014 10:26:33 -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=Gkbo6wQtydZheO4fGZdw JRuzehs=; b=yg5okgVz3uFEUARURm2tQyHpxMRS576WtlyJvE5p97bqeNWIy9VA wp0ElB6H9ARI92UoFeDzN7L3WJcvr5xi+ji7nOjRqCQNRd7kFBV2pdSppcyhNHWq sG39b6dkCTVX2fhvgPWZRJ5FuiLg35SIq8mwX09IO/68BFGa3AwO1Hw= 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-a24.g.dreamhost.com (Postfix) with ESMTPSA id D793D2C806C for ; Wed, 2 Apr 2014 10:26:32 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so588746wgh.4 for ; Wed, 02 Apr 2014 10:26:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.10.66 with SMTP id g2mr30311109wib.5.1396459591668; Wed, 02 Apr 2014 10:26:31 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 10:26:31 -0700 (PDT) In-Reply-To: <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 12:26:31 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NM0NUZekBQStrjCtQ0rz8yDVNZc Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 17:26:41 -0000 On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins wrote: > EKE doesn't do RSA. And, as Nico pointed out, observing a single exchange > can eliminate a large majority of the potential passwords. Even an infrequent > use can give an adversary a high probability of successfully determining > the secret. But if you use Elligator then that problem goes away. That's the key point. From nobody Wed Apr 2 10:35: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 D58E61A0326 for ; Wed, 2 Apr 2014 10:35:38 -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 kOqdlPDA79Oy for ; Wed, 2 Apr 2014 10:35:34 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D73FF1A0318 for ; Wed, 2 Apr 2014 10:35:34 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 193E51B4059 for ; Wed, 2 Apr 2014 10:35:31 -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=zKYvcKLql6YbTpjuBAO3 ZIVt67U=; b=L3ng6LiNLkCTNx2jgmAzqg632CRxxlUQIGvWGxCnQyL2B7/ijckg OPrFBjsmsovepS/f6wAuBPmmwCpNbKbsxKOAcFQGJkZZ9haa7f/U0e+tEqnuH0MW S3b9Bgdem6c5js37Fu3BFSVDodrLyV09D/dfz+oWHOlHyE2Y8qu5Y8o= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (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 C25DF1B4058 for ; Wed, 2 Apr 2014 10:35:30 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id z2so5875427wiv.12 for ; Wed, 02 Apr 2014 10:35:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr3931437wib.42.1396460129424; Wed, 02 Apr 2014 10:35:29 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 10:35:29 -0700 (PDT) In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 12:35:29 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qqXXnnvTnGDibrsmqCGGf6je_u0 Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 17:35:39 -0000 With Elligator the eavesdropper goes from being able to eliminate 7/8ths of possible passwords with each exchange to being able to eliminate only 19/2^256 possible passwords (in the curve25519 case; the exact number varies by curve for which Elligator is available). Therefore EKE with ECC + Elligator is safe. From nobody Wed Apr 2 10:55: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 11B191A028D for ; Wed, 2 Apr 2014 10:55:27 -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 9dHuyYDIJtyz for ; Wed, 2 Apr 2014 10:55:22 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4CE1A02D4 for ; Wed, 2 Apr 2014 10:55:22 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 676F4A888016; Wed, 2 Apr 2014 10:55:18 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 10:55:18 -0700 (PDT) Message-ID: <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 10:55:18 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" 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/vOuHO-hh-nnfZqFMDlhJKIHCfmE Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 17:55:27 -0000 On Wed, April 2, 2014 10:26 am, Nico Williams wrote: > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins wrote: >> EKE doesn't do RSA. And, as Nico pointed out, observing a single >> exchange >> can eliminate a large majority of the potential passwords. Even an >> infrequent >> use can give an adversary a high probability of successfully determining >> the secret. > > But if you use Elligator then that problem goes away. That's the key > point. Yes, as I mentioned back in December on this list, EKE with Elligator would make a very good alternative to TLS-pwd. And if there was a mature draft ready for publication that specified such a scheme it would be worth considering. But there isn't. And we're 2+ years away from having such a thing. Probably more since we have not identified a stuckee willing to edit it. As Cullen mentioned, the IETF is a volunteer organization and telling people that they should go write a draft specifying your alternative to their draft is not really productive. I have received and resolved comments on the draft dealing with protection of the username from passive observers and on mitigating side channel attacks. There is no technical problem with TLS-pwd and it solves real problems right now. I see no reason why it should not ease away from the curb (and out of its parked position). regards, Dan. From nobody Wed Apr 2 11:15:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E64A1A0375 for ; Wed, 2 Apr 2014 11:15:52 -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 cwHBiFIfOt-w for ; Wed, 2 Apr 2014 11:15:46 -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 421E51A0370 for ; Wed, 2 Apr 2014 11:15:46 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so597214yha.10 for ; Wed, 02 Apr 2014 11:15: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=D2w8oa0NJ8aLacbuMAUa3rYKupXM9fJMxqfQ0eFxcnU=; b=KhhcKLsKl8bXaotTY/N/K+9qAtasPleCcqa3EzA08n25i8I63MwaV/UCYbKzPAemD3 3+PzTHbkhXFCefaTUMgt/frJwp/uJTgfMIWV4ZgV05cAYLc5WaM4QdHDbDh60h8uI3It 1gl18NjdrdvY9FNkux7Jm3n30w78dvPy5lfEIGdjVsQzvhQZZhs8EhTxMtNKabpE74Er uCDe39kwu7a4Ma+vQXjL3j4PQf5VDcZBT3jZsveBsFpPvDBhwGl6+VaSh8IhzAgBx1Bs m0qC0AIEbVm5ZwwzsHlX7y5h34biKBcXMEHnfHg7jMg3auTH+jfNvnznQZfA/Wq9aQ6X K8Fg== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr2600512yhj.63.1396462542220; Wed, 02 Apr 2014 11:15:42 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 2 Apr 2014 11:15:42 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 2 Apr 2014 11:15:42 -0700 (PDT) In-Reply-To: <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 11:15:42 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: multipart/alternative; boundary=20cf303dd434c5728a04f613450d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H5Ku42FKK_AGNbuRjxg_wMsTFgA Cc: tls@ietf.org Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 18:15:52 -0000 --20cf303dd434c5728a04f613450d Content-Type: text/plain; charset=UTF-8 On Apr 2, 2014 10:55 AM, "Dan Harkins" wrote: > > > On Wed, April 2, 2014 10:26 am, Nico Williams wrote: > > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins wrote: > >> EKE doesn't do RSA. And, as Nico pointed out, observing a single > >> exchange > >> can eliminate a large majority of the potential passwords. Even an > >> infrequent > >> use can give an adversary a high probability of successfully determining > >> the secret. > > > > But if you use Elligator then that problem goes away. That's the key > > point. > > Yes, as I mentioned back in December on this list, EKE with Elligator > would make a very good alternative to TLS-pwd. And if there was a mature > draft ready for publication that specified such a scheme it would be worth > considering. But there isn't. And we're 2+ years away from having such a > thing. Probably more since we have not identified a stuckee willing to > edit it. > > As Cullen mentioned, the IETF is a volunteer organization and telling > people that they should go write a draft specifying your alternative to > their draft is not really productive. > > I have received and resolved comments on the draft dealing with > protection of the username from passive observers and on mitigating > side channel attacks. There is no technical problem with TLS-pwd and it > solves real problems right now. I see no reason why it should not ease > away from the curb (and out of its parked position). What about the complete absence of any positive security analysis? You've known this was going to be an issue since you invented Dragonfly. I feel completely uncompelled to be 'productive' at the expense of security. Quit fussing and whining about how hard it is to write drafts. You could have started with something provably secure and avoided wasting your efforts. Failing that, make AugPAKE work on ECC by grabbing the draft and fixing it, then submit that instead. Sincerely, Watson Ladd > > regards, > > Dan. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --20cf303dd434c5728a04f613450d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 2, 2014 10:55 AM, "Dan Harkins" <dharkins@lounge.org> wrote:
>
>
> On Wed, April 2, 2014 10:26 am, Nico Williams wrote:
> > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins <dharkins@lounge.org> wrote:
> >> =C2=A0 EKE doesn't do RSA. And, as Nico pointed out, obse= rving a single
> >> exchange
> >> can eliminate a large majority of the potential passwords. Ev= en an
> >> infrequent
> >> use can give an adversary a high probability of successfully = determining
> >> the secret.
> >
> > But if you use Elligator then that problem goes away. =C2=A0That&= #39;s the key
> > point.
>
> =C2=A0 Yes, as I mentioned back in December on this list, EKE with Ell= igator
> would make a very good alternative to TLS-pwd. And if there was a matu= re
> draft ready for publication that specified such a scheme it would be w= orth
> considering. But there isn't. And we're 2+ years away from hav= ing such a
> thing. Probably more since we have not identified a stuckee willing to=
> edit it.
>
> =C2=A0 As Cullen mentioned, the IETF is a volunteer organization and t= elling
> people that they should go write a draft specifying your alternative t= o
> their draft is not really productive.
>
> =C2=A0 I have received and resolved comments on the draft dealing with=
> protection of the username from passive observers and on mitigating > side channel attacks. There is no technical problem with TLS-pwd and i= t
> solves real problems right now. I see no reason why it should not ease=
> away from the curb (and out of its parked position).

What about the complete absence of any positive security ana= lysis? You've known this was going to be an issue since you invented Dr= agonfly. I feel completely uncompelled to be 'productive' at the ex= pense of security.

Quit fussing and whining about how hard it is to write draft= s. You could have started with something provably secure and avoided wastin= g your efforts.

Failing that, make AugPAKE work on ECC by grabbing the draft= and fixing it, then submit that instead.

Sincerely,
Watson Ladd
>
> =C2=A0 regards,
>
> =C2=A0 Dan.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--20cf303dd434c5728a04f613450d-- From nobody Wed Apr 2 11:22: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 4AFF81A0326 for ; Wed, 2 Apr 2014 11:22:03 -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 BfcTnxhoajxR for ; Wed, 2 Apr 2014 11:21:58 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 57F101A03B9 for ; Wed, 2 Apr 2014 11:21:58 -0700 (PDT) Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id DACC160171 for ; Wed, 2 Apr 2014 19:21:53 +0100 (BST) Message-ID: <533C554A.7080607@akr.io> Date: Wed, 02 Apr 2014 19:22:02 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> In-Reply-To: <20140402164340.GA14790@roeckx.be> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ctszNoNjedg3Gp-lxRCL6y_GMHo Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 02 Apr 2014 18:22:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/04/2014 17:43, Kurt Roeckx wrote: > So what's the status of this? [draft-josefsson-tls-curve25519] As I recall, there were only three issues raised in the discussion in January (and one tiny one I'm raising now that is very easily fixed in the normal course of RFC editing). Discussion seemed to just peter out after then. If I may summarise where we left off (and _please_ speak out if you feel I'm grossly mischaracterising anything or got anything wrong!):— 1. Draft-04 uses its own point format, a 'big-endian' representation, (and adds a length byte). That differed from every existing Curve25519 implementation in the wild, which use a 'little-endian' representation. • Both Rich Salz and Robert Ransom spoke strongly for simply using the existing little-endian format used by all Curve25519 implementations already in the wild, and pointed out there was no technical reason to break compatibility and change that to anything else. [No such technical reasons were seemingly presented in the ensuing discussion. /akr] • Manuel Pégourié-Gonnard wasn't married to the point format in -04, had no objection to using the existing little-endian format, and requested comments 'in the next few days' from anyone who did have objections. • Watson Ladd said endianness wasn't a good reason to vote no, and asked please not to reignite the endianness 'holy war'. • Nikos Mavrogiannopoulos pointed out protocols are often expected to outlive existing implementations and aren't typically designed based on them. [Although this one would, presumably, be an exception? /akr] He also pointed out almost all IETF protocols use the big-endian format for transferring integers, so that implementations would be prepared for any endian issues anyway. • James Cloos suggested 'Internet-endian is the better choice'. [I presume, from context, that he meant big-endian. /akr] • Bill Frantz simply pointed out that it wouldn't be unprecedented to have little-endian data in an Internet Protocol. [For what it's worth - i.e. almost nothing! - I myself favour matching the Curve25519 reference: so, little-endian. /akr] 2. We need to specify what, exactly, to do with the unused high bit. As the discussion in January covered, except for one, buggy implementation, all Curve25519 implementations in the wild always produce 0, and always ignore it. We should probably specify that as required behaviour; it allows for using it for something else later, which was discussed. Manuel agreed that implementations SHOULD mask off the high bit. That's not in draft-04, but it should be in -05? There was talk about maybe using it later for sign-of-y or something else, for other protocols. I don't know if that went anywhere. [Again, I favour the draft simply matching the original Curve25519 implementation: high bit SHOULD be 0, high bit SHOULD be ignored. /akr] 3. The length byte was talked about, and the consensus seemed broadly to be: specify 32 now, allow 64 for if we want, say, an Edwards-form y-coordinate for some other protocol later, and have the first 32 bytes of that match the 32-byte format. [I have no position on this. /akr] 4. The NamedCurve value allocation is still [TBD1] in -04 - we'd need an actual value allocated before implementing that in the wild (outside of pure testing, where we can just use a private value)? That's about all I can remember. Were there any other substantive issues? Thanks for reminding us about the stalled discussion. I'm keen to start getting things out there myself: if we can wrap up the remaining issues, I think that'd be good for everyone. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTPFVKAAoJEOyEjtkWi2t6o3kP/1ZWnVr5jd7m3/S8H/IBY7kK 7VWgjlrgb3x6QqflU5xDwgrGNelp2m5FY4IKKUr0DPfIvGkXP+vKttXO+EWligq8 biP+DeObsstJ3Sb9tqd1pD4is3/Wb/Y6Zbo2PE+Qu5edF5wFX1lTJPtqMl9Lh6Ux Wev+dgQD7EXf+tgw9MXB92dhs9qS+zMFBUfH79QEC7QJI4kH7KCQlzTVBHB0Px1g wesrN0QEpgx1lY2/dw2lnejZaty6dsjbGKtYB416+qpNSlKvwSHchnFfz8dd/Krp u8+/JW3hLgnQsv8DzFHj31ZQAYoE/3HjrqXqm9bA2U4CtuVl+Crhprc+7f7JpuXi YfRZfY4+VswW2LRLRSHf1Gxa2oURqpEzYyk4R5XH7lIVBnD0nEqMoxLrHr3leA9a aDhse6SCbytpACrpVh/a/U9mf27jT7yno9KVdGeX/0WdJQRDPu3s+gN26/38jwCk tw3rxzCv911r4T7NA0vnwRW6lZLwAf6TWo64xJHcvDpq1QUFE61MJSOx4Z2H0xQ1 bXcZQoejEEkutYH0HXdbpsgr4aHsle8emwW9UdP6yyFzdRgN43QkAFUmKkMdRcrB rVQoPPxuiTPr4VM/Ii4vOViOjvaHoEuN1cKt+F1oPV5/33uhQt1oA10cvomM4QZ9 RwgW7YnKIyZ0HxwGlkyn =bm10 -----END PGP SIGNATURE----- From nobody Wed Apr 2 11:28: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 B70FD1A03BC for ; Wed, 2 Apr 2014 11:28:05 -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 wCpJM4dfTaQx for ; Wed, 2 Apr 2014 11:28:01 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C607D1A03AE for ; Wed, 2 Apr 2014 11:28:01 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 04C7B286078 for ; Wed, 2 Apr 2014 11:27: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=BJVc/QxvPhSyz/+8gQIw CqM1d/I=; b=HcwpHBImJa2byOzTzwk8eujC3Cd7rPxfmfW2+I8m06HaZx8TXCGg 0PSyNzjFbacbilyLmdTvBi+hV9V9nThSN3hETqM1+2wTCNni71BF4GQvCXUkBIAN C78MaPa4mkozM3jF/oiLAsoHBg3dpR9FORq+PvwrMyf552X7CZzQ2PI= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id A82D028606F for ; Wed, 2 Apr 2014 11:27:57 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so7718012wiv.3 for ; Wed, 02 Apr 2014 11:27:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.191.195 with SMTP id ha3mr2788599wjc.69.1396463276359; Wed, 02 Apr 2014 11:27:56 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 11:27:56 -0700 (PDT) In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 13:27: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/amNY5MfVj9LnyL2G8jXJwxa6VnI Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 18:28:05 -0000 On Wed, Apr 2, 2014 at 1:15 PM, Watson Ladd wrote: To be fair it's not just about I-Ds. I've written quite a few myself -- it's easy. It's also about running code. Nico -- From nobody Wed Apr 2 11:38: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 B79831A0375 for ; Wed, 2 Apr 2014 11:38:34 -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 q70LaDF7uCf2 for ; Wed, 2 Apr 2014 11:38:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3429A1A0370 for ; Wed, 2 Apr 2014 11:38:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1521DA888016; Wed, 2 Apr 2014 11:38:26 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 11:38:26 -0700 (PDT) Message-ID: In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 11:38:26 -0700 (PDT) From: "Dan Harkins" To: "Nico Williams" 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/VCv2d2o_O3lYV9j6STC8MLp6qDM Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 18:38:35 -0000 On Wed, April 2, 2014 11:27 am, Nico Williams wrote: > On Wed, Apr 2, 2014 at 1:15 PM, Watson Ladd wrote: > > To be fair it's not just about I-Ds. I've written quite a few myself > -- it's easy. It's also about running code. Check out Appendix A of draft-ietf-tls-pwd-04. Do you know of any running code that implements TLS ciphersuites that perform EKE with Elligator curves? Dan. From nobody Wed Apr 2 11:52: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 8A68C1A03A2 for ; Wed, 2 Apr 2014 11:52:34 -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 oqPdcIEt_rWN for ; Wed, 2 Apr 2014 11:52:29 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BB40E1A0370 for ; Wed, 2 Apr 2014 11:52:29 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5C026A888016; Wed, 2 Apr 2014 11:52:25 -0700 (PDT) Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Apr 2014 11:52:26 -0700 (PDT) Message-ID: <3eea5a90ed4b766b00589e61c30d6137.squirrel@www.trepanning.net> In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 11:52:26 -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/dJtaMPft24XY03EdA77-8DuXwm8 Cc: tls@ietf.org Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 18:52:34 -0000 On Wed, April 2, 2014 11:15 am, Watson Ladd wrote: > On Apr 2, 2014 10:55 AM, "Dan Harkins" wrote: >> >> >> On Wed, April 2, 2014 10:26 am, Nico Williams wrote: >> > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins > wrote: >> >> EKE doesn't do RSA. And, as Nico pointed out, observing a single >> >> exchange >> >> can eliminate a large majority of the potential passwords. Even an >> >> infrequent >> >> use can give an adversary a high probability of successfully > determining >> >> the secret. >> > >> > But if you use Elligator then that problem goes away. That's the key >> > point. >> >> Yes, as I mentioned back in December on this list, EKE with Elligator >> would make a very good alternative to TLS-pwd. And if there was a mature >> draft ready for publication that specified such a scheme it would be >> worth >> considering. But there isn't. And we're 2+ years away from having such a >> thing. Probably more since we have not identified a stuckee willing to >> edit it. >> >> As Cullen mentioned, the IETF is a volunteer organization and telling >> people that they should go write a draft specifying your alternative to >> their draft is not really productive. >> >> I have received and resolved comments on the draft dealing with >> protection of the username from passive observers and on mitigating >> side channel attacks. There is no technical problem with TLS-pwd and it >> solves real problems right now. I see no reason why it should not ease >> away from the curb (and out of its parked position). > > What about the complete absence of any positive security analysis? You've > known this was going to be an issue since you invented Dragonfly. I feel > completely uncompelled to be 'productive' at the expense of security. You're overstating things a bit. There is no formal proof but that doesn't mean there is a complete absence of any positive security analysis. Being uncompelled and upset at the lack of a formal proof are not technical comments, they are just whines. > Quit fussing and whining about how hard it is to write drafts. You could > have started with something provably secure and avoided wasting your > efforts. "Quit fussing and whining" works both ways. You've been fussing and whining since you joined this list and it might be a good time to quit. To be clear, I have not said that it is hard to write a draft, I said it is time consuming. And I already have a draft (and running code) that solves the problems I have identified. I have no reason to volunteer to write another draft to do something that you want and I don't think you can afford my consulting rate. > Failing that, make AugPAKE work on ECC by grabbing the draft and fixing > it, then submit that instead. You should stop telling people to do things you are unwilling to do yourself. Dan. From nobody Wed Apr 2 12:00: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 599701A0411 for ; Wed, 2 Apr 2014 12:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku1a3Yfc7rj5 for ; Wed, 2 Apr 2014 12:00:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1221A03DE for ; Wed, 2 Apr 2014 12:00:34 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s32IwgP3017229; Wed, 2 Apr 2014 15:00:28 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Nico Williams Date: Wed, 2 Apr 2014 15:00:20 -0400 Thread-Topic: [TLS] The PAKE question and PSK Thread-Index: Ac9Opc3yP9eP7yXlTTCpFlJcHCeuHw== Message-ID: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3479295620_5531468" 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-04-02_05:2014-04-02,2014-04-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404020150 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bRfjysmTqOyvyWaVEpGyO38d_t0 Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 19:00:51 -0000 --B_3479295620_5531468 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Could you please remind me - is Elligator limited to a certain group/class of curves, or is it usable with any, e.g., E(Fp)? Thanks! On 4/2/14 13:35 , "Nico Williams" wrote: >With Elligator the eavesdropper goes from being able to eliminate >7/8ths of possible passwords with each exchange to being able to >eliminate only 19/2^256 possible passwords (in the curve25519 case; >the exact number varies by curve for which Elligator is available). >Therefore EKE with ECC + Elligator is safe. --B_3479295620_5531468 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHjMIIEyzCCA7OgAwIBAgIKa7HhIQAAAACRlDANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTE0MDEyNzE2MTg1MloXDTE1MDEyNzE2MTg1Mlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMzX2AgWtgCJ2VJBfeiXUnR7FHfrCpElYl5agkmKEe 0kbvlM1XrVnvCbzgSXyiPD9pHAjj/fE0XEjEgLy3M3h6H7LX503XwoicBtYKO+OcuP6Z/cbt +mHlVpa5zrTBtHdbxM/Dg3Km7UvVqfVoCW4LJ6YCH4eBGg49efKVDWE5fReO90fWAQQZJ4ou tvYjPAlRVn2F0pr8Rgh1SbMGGs/blcP9Mv4PDfiI1DnT/f9LEOgkvuzY3FmltMbR8K0QeFVJ y4p9bYA/HTZwaLF4nW8+HUC+n+RJ1Ji0WBWx66R2VgWA51oXsHvgyIH72LQL/sQVReuEstkq OdmW0+hquzAXAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUWOgymm0BMjd4VJ3fS5lgVlV1kiAw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAePYh/MRINApc6X/qe1sDLHVAgxEVN2x/hwu38f+XUALYvbtIDLvYtHHX4tw6 D75LlzrYTcj57S/kiL0NVsUjhBs76zRR3iasxMC0Q8Ry6eTumsTc9NM/SdfgIOHZWqbADwC/ R3ePYyZTL/VQAU6115q2r7MI/3+fxvmul9BRAud3A+Gg1wiI8FhU5ydL890bjGbsJ2YVDMxC 6zMFBV4TJAlpvpIFixABVZufETqEH/xRCtg+B/fKOdjzMmOwolhcUTHJj8DiubjkyYb4Rvyu W1ktjCPllUvdAUj5nvy7nSah9U2oULMp1DZSz2p7mBlcFNlm7XJcpbI2kjzx8mFRsDCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIEzjCCA7agAwIBAgIKPVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjm saplLeGQusUFRyRNSkfYtdB4YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SS lTzGRo+gaL6rqsDKdwDOzs3CPYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGq VeAY8ht5u2h4ojPdwiuDQDW2QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW 8BwJOruVsBfLNxyDxgffNQ1D1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6 avZAaCa3AgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAJiU3WfJ9GvGJiDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrv s+lU8fU2F2ELpV8q8eYgqLLw7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZg WFz8R6akAoLKpqGulNrvjvU8c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ /hOyBwbBntc+W2gDppfR1BCtDNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdre BEv/YuLnDd/PhVgQwp3LHGCXX1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUw ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKa7HhIQAAAACRlDANBglg hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCud2gj0/hw/dFccJu3wzk+Y1efW+bGJHv2 TIA0cXL9IDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA0 MDIxOTAwMjBaMA0GCSqGSIb3DQEBAQUABIIBAB3oHsJ5ZQGfFgZpvv/zaKYp99BzgfD2Ejyy CL2/NLd3xrYQDcYW5ExwRMjJr1+QfAPV6xI4jGKNcR0F0K36TbqdDVgJgDa3FbgCJJOaK/cS OQGMpreEPaYbIP138kDevWJdBZKyQjnVaeHpRAeVdnjQpLSlOR1Bpy4D2XzsuykKsqkZoyVk rPUshqqC+aDIzMw4hyt7615QmRDyVTsoP7PqydwIVx4OJmzIVsQ3ctBFuvcTVFE0WMkESAnX DUXlbC1mhLHw90EK+Ed3quJPQY80jSMuGicDo+Mgg7NJCRL1z1MpySgKUCgMI0fFemA/8PxT s9PBUC54hIxP8ZzlTr8= --B_3479295620_5531468-- From nobody Wed Apr 2 12:26: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 3A1A21A03AA for ; Wed, 2 Apr 2014 12:26: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 s0IMcYy1YGqZ for ; Wed, 2 Apr 2014 12:26:16 -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 3BA421A02C5 for ; Wed, 2 Apr 2014 12:26:16 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CF028481A7; Wed, 2 Apr 2014 19:26:11 +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 C38E54810D; Wed, 2 Apr 2014 19:26:11 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 75F5A47BD5; Wed, 2 Apr 2014 19:26:11 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.97]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 2 Apr 2014 15:26:10 -0400 From: "Salz, Rich" To: Alyssa Rowan , "tls@ietf.org" Date: Wed, 2 Apr 2014 15:26:03 -0400 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac9OoHJ6ZEilCs3gTBan+qkuDAEwfwACNiQA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04E1F7@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> In-Reply-To: <533C554A.7080607@akr.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9di2zhm4JifxSXqQ7JDJPcFeDCE Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 02 Apr 2014 19:26:21 -0000 TmljZSBzdW1tYXJ5Lg0KDQpJIHRoaW5rIHdlIGhhZCBjb25zZW5zdXMgYXJvdW5kIHVzaW5nIHRo ZSBsaXR0bGUtZW5kaWFuIHBvaW50IGZvcm1hdCwgYnV0IHRoaXMgcmVxdWlyZXMgc29tZSBtb3Jl IG92ZXJoZWFkIChhIG5ldyBFQ1BvaW50IHR5cGUgYW5kIGFuIElBTkEgcmVnaXN0cnkpIHRoYXQg bm9ib2R5IGhhcyBzdGVwcGVkIHVwIHRvIGRvIHlldC4NCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3Vy aXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0K From nobody Wed Apr 2 12:37: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 588451A03AE for ; Wed, 2 Apr 2014 12:37:29 -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 Erbcy0I_Z5QZ for ; Wed, 2 Apr 2014 12:37:25 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 879131A03AB for ; Wed, 2 Apr 2014 12:37:25 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id BE1DC438072 for ; Wed, 2 Apr 2014 12:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=oZHBYC49sia0qSCHlhBF jJhs64s=; b=L7r2E27HpLfFnDZImUQcQo1C3Dw0MQWcfTcug6uGBPxRdW/VWeTq OS7hN6NFXI9b4bzOipHXxYwZfVLtyFwNTv3zkhs1sTs1sZ/nM0WP5RiTFkTuQuIj pkFknnEQX0TFxDzUwI1+eRb4rhsqJs2HOHEXvfQtDtRZwIbB7f1MLWY= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 71F8543806C for ; Wed, 2 Apr 2014 12:37:21 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so754049wes.34 for ; Wed, 02 Apr 2014 12:37:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.226 with SMTP id wd2mr3151859wjc.95.1396467440306; Wed, 02 Apr 2014 12:37:20 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 12:37:20 -0700 (PDT) In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 14:37:20 -0500 Message-ID: From: Nico Williams To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jeft5Op10D_avHGZz4bt-hfKOi8 Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 19:37:29 -0000 On Wed, Apr 2, 2014 at 1:38 PM, Dan Harkins wrote: > Check out Appendix A of draft-ietf-tls-pwd-04. Do you know of > any running code that implements TLS ciphersuites that perform EKE > with Elligator curves? And in constant time. Still, we're inching closer to having all the pieces. I did find one liberally-licensed C implementation of Elligator just now, and an unlicensed implementation in Go. We may soon well have enough Elligator implementations to permit interop testing and widespread implementation of EKE w/ Elligator. And, of course, one can always write one's own implementation. Nico -- From nobody Wed Apr 2 12:38: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 B34AB1A03B3 for ; Wed, 2 Apr 2014 12:38:26 -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 02JdQmIzrega for ; Wed, 2 Apr 2014 12:38:23 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EE5971A0383 for ; Wed, 2 Apr 2014 12:38:22 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 2D2771B4058 for ; Wed, 2 Apr 2014 12:38: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; s=cryptonector.com; bh=iVx9SdNNigmT7+Bgpaa+ HH8IHHw=; b=gPhIxz1JxjkJtorCwyV1K4jhvTgcFnRW6CH24jmU0lG9/TUwO78Q 8NGOMOVyuLBR8fbKLCukvU31FZPnsqLs02KBllmHFHs4ZFb+eWBOittCe2pYLTGx 3LfOLRWki1wSr/gh7mhfDV/vQdWKNxcDvlxsmaL+03iGDE1x+hfzr/4= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 C67681B4057 for ; Wed, 2 Apr 2014 12:38:18 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so1199026wiv.1 for ; Wed, 02 Apr 2014 12:38:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr4669435wib.42.1396467497442; Wed, 02 Apr 2014 12:38:17 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 2 Apr 2014 12:38:17 -0700 (PDT) In-Reply-To: References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> Date: Wed, 2 Apr 2014 14:38:17 -0500 Message-ID: From: Nico Williams To: "Blumenthal, Uri - 0558 - MITLL" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-4vg8rMn3sUpHC0MAYYCrXylyjY Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2014 19:38:26 -0000 On Wed, Apr 2, 2014 at 2:00 PM, Blumenthal, Uri - 0558 - MITLL wrote: > Could you please remind me - is Elligator limited to a certain group/class > of curves, or is it usable with any, e.g., E(Fp)? http://elligator.cr.yp.to/elligator-20130828.pdf From nobody Wed Apr 2 14:40: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 1E3881A03F0 for ; Wed, 2 Apr 2014 14:40:05 -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 0fcO9jpN2IrP for ; Wed, 2 Apr 2014 14:40:00 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE07A1A03EE for ; Wed, 2 Apr 2014 14:39:58 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id hz1so798123pad.7 for ; Wed, 02 Apr 2014 14:39: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WrNkkF6+8Rm7ArGXhCHbvg1QfNfqiYsow3HRnuf7FTo=; b=BwiRJO/l6m7IjQVDrdKEFaWwuOmfus3gCZaSNaIGmPEzbrsWGSOH4xNKVguQM54cF5 cGpO2toO96BH+B8lTtg2fmyW3hwIxdzrQvo5VlEYQoIK/t2S5R8xK3Wq3CrdoieSjnsY Z6AwVkpx07iHQzD5CN9JjYKVVZB6CesAVlIQyweL66TAgm+r2KWGXcRNsboySd3e5k5d put1yFz6Dn+1GsOBDh3HZOxTOy/A9QFZEoYJI5PQzytv2W1xW1sc2lzAKuH4p/Abkcz3 W6fEmvWQQM2Agirf4D19sn4UocjMpzkzp79nEjsuqRbS2kpg5F0BfUKPGYeVLkqJrHpW j7UA== X-Gm-Message-State: ALoCoQk0p2Yckb3twnDB2VEkoVgZ2TjdCS538agWR1pAVp8sW0GW5UweXlrzvGzmimpTbQHTFevF X-Received: by 10.68.231.196 with SMTP id ti4mr2898358pbc.48.1396474794838; Wed, 02 Apr 2014 14:39:54 -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 z3sm15033127pas.15.2014.04.02.14.39.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 14:39:54 -0700 (PDT) Message-ID: <533C83A9.8090302@mit.edu> Date: Wed, 02 Apr 2014 14:39:53 -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: Dan Harkins , Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SuwZkwuGZVWbynnUTIdz4fowfxE 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: Wed, 02 Apr 2014 21:40:05 -0000 On 03/30/2014 11:04 PM, Dan Harkins wrote: > > > 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". There's a difference between IND-CCA and IND-CCA2. >> 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. If everyone designing TLS 1.3 thought about what the use cases that want or require client authentication, then maybe TLS 1.3 will come up with a way of doing client authentication that actually makes sense. Conversely, maybe if these were an understanding of the use cases that require actual renegotiation (as opposed to supplementary authentication of the parties that negotiated the original secret), then TLS might have avoided supporting renegotiation in the first place. (Hint: I've never heard of a legitimate reason that an application would want to explicitly change keys in the middle of a session.) >> 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. I think that Watson is actually saying that the WG should decide what security properties TLS 1.3 should actually have. Then it should document those properties. Then people can and should verify that the eventual specification actually has those properties. --Andy From nobody Wed Apr 2 23:04: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 3B59C1A00C2 for ; Wed, 2 Apr 2014 23:04:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROmlP61VJbFi for ; Wed, 2 Apr 2014 23:03:55 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4671A00B9 for ; Wed, 2 Apr 2014 23:03:55 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta12.emeryville.ca.mail.comcast.net with comcast id lHxa1n00616AWCU01J3rAT; Thu, 03 Apr 2014 06:03:51 +0000 Received: from [192.168.1.8] ([71.202.164.227]) by omta06.emeryville.ca.mail.comcast.net with comcast id lJ3q1n0014uhcbK8SJ3qqs; Thu, 03 Apr 2014 06:03:51 +0000 Message-ID: <533CF9C5.7030107@brainhub.org> Date: Wed, 02 Apr 2014 23:03:49 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> In-Reply-To: <533C554A.7080607@akr.io> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396505031; bh=dFhaTEjF3p3jfp5/fwGlmI6FES0z27BusgsUDlnksPc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Jxet6QmQLBAF5owjvdp1r2Ae5OnxzU9iW/p2PWhW9MOhPdXmoE+BWX0Nm8cGaShhp vn2v0aw94OFyy9irot2KotMu9Vp8yJrrK6adkVxCCs9U49bGpKNxgpJXQRgPCPwgky 4UjeNQqVBbxbkkqu6uKL/FCXIUwG4fPP2tDcEf15MGAcJLF0kbQdOurHCTCRoDo72M b8/C+VFieT6OTiR3kyaX7LTuZ/ouKCUvOGfykFNc54tY+1/YkbPgWcxRr1wZKRfIy7 N30nfoY0LVzUYsNYn3SitS6qZ5awDWnYjUQdfO5xPkUump2VQRbPlF+z6WTcl/CM3c Ydxhf3zL9hCdw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qXMcscJV9X4NC6tt7NbUUWxAiyo Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 06:04:01 -0000 On 04/02/2014 11:22 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 02/04/2014 17:43, Kurt Roeckx wrote: > >> So what's the status of this? [draft-josefsson-tls-curve25519] > > As I recall, there were only three issues raised in the discussion in > January (and one tiny one I'm raising now that is very easily fixed in > the normal course of RFC editing). Discussion seemed to just peter out > after then. > > If I may summarise where we left off (and _please_ speak out if you > feel I'm grossly mischaracterising anything or got anything wrong!):— > > 1. Draft-04 uses its own point format, a 'big-endian' representation, > (and adds a length byte). > > That differed from every existing Curve25519 implementation in the > wild, which use a 'little-endian' representation. > > • Both Rich Salz and Robert Ransom spoke strongly for simply using > the existing little-endian format used by all Curve25519 > implementations already in the wild, and pointed out there was no > technical reason to break compatibility and change that to > anything else. > > [No such technical reasons were seemingly presented in the ensuing > discussion. /akr] > > • Manuel Pégourié-Gonnard wasn't married to the point format in -04, > had no objection to using the existing little-endian format, and > requested comments 'in the next few days' from anyone who did have > objections. > > • Watson Ladd said endianness wasn't a good reason to vote no, and > asked please not to reignite the endianness 'holy war'. > > • Nikos Mavrogiannopoulos pointed out protocols are often expected > to outlive existing implementations and aren't typically designed > based on them. > > [Although this one would, presumably, be an exception? /akr] > > He also pointed out almost all IETF protocols use the big-endian > format for transferring integers, so that implementations would be > prepared for any endian issues anyway. > > • James Cloos suggested 'Internet-endian is the better choice'. > [I presume, from context, that he meant big-endian. /akr] > > • Bill Frantz simply pointed out that it wouldn't be unprecedented > to have little-endian data in an Internet Protocol. > > [For what it's worth - i.e. almost nothing! - I myself favour > matching the Curve25519 reference: so, little-endian. /akr] > > > 2. We need to specify what, exactly, to do with the unused high bit. > > As the discussion in January covered, except for one, buggy > implementation, all Curve25519 implementations in the wild always > produce 0, and always ignore it. > > We should probably specify that as required behaviour; it allows for > using it for something else later, which was discussed. Manuel > agreed that implementations SHOULD mask off the high bit. That's not > in draft-04, but it should be in -05? > > There was talk about maybe using it later for sign-of-y or something > else, for other protocols. I don't know if that went anywhere. > > [Again, I favour the draft simply matching the original Curve25519 > implementation: high bit SHOULD be 0, high bit SHOULD be ignored. > /akr] > > > 3. The length byte was talked about, and the consensus seemed broadly > to be: specify 32 now, allow 64 for if we want, say, an Edwards-form > y-coordinate for some other protocol later, and have the first 32 > bytes of that match the 32-byte format. > > [I have no position on this. /akr] The ECPoint is defined as follows, struct { opaque point <1..2^8-1>; } ECPoint; Is the format on the wire per section 2.3 33 32 xx xx xx ... xx or, suggested, 65 64 xx xx xx ... xx yy yy yy ... yy ? Or I am reading it incorrectly and the extra byte mentioned in the draft is actully a part of standard TLS encoding of the length byte? At first I interpreted it as former. Then the question is why the (excessive) length byte is needed? The negotiated Curve25519 tells that 32 bytes are expected. (If there are 64, there is a y there.) > > > 4. The NamedCurve value allocation is still [TBD1] in -04 - we'd need an > actual value allocated before implementing that in the wild (outside > of pure testing, where we can just use a private value)? > > > That's about all I can remember. Were there any other substantive issues? > > Thanks for reminding us about the stalled discussion. > > I'm keen to start getting things out there myself: if we can wrap up > the remaining issues, I think that'd be good for everyone. > > - -- > /akr ... From nobody Wed Apr 2 23:42: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 1B4691A00DB for ; Wed, 2 Apr 2014 23:42:50 -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 1Gn_cghIvIKI for ; Wed, 2 Apr 2014 23:42:45 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5111D1A00CB for ; Wed, 2 Apr 2014 23:42:45 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1329187wes.10 for ; Wed, 02 Apr 2014 23:42:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PTc6WUppI7Sjdl+5jVFWJqMf6e85rnId2As9rr18fQg=; b=Es4bJSVq97R24XO4+Xmk7RA8SMASKr7X8cTsO+Rk2or7FqiNXdOPbskiVSElJOkNLx d3Eb5032nJApTZ2/labN8ZDnxJeb1Y3Vlok2kv9woDp3vXYOeDHjCwW5K7VdeqoOAyjp zbSzQ3x4e6I3fThw8aX2geJIb3C2tV8hyWXPadDozIpOAw8B98E9E+rOQaQIsIA6/4Gf 63Flnapaddbgxsf+M4FYHL4cV8/mJLlHz5zMOqaqTzY63rfmVXsPbjSbUETJeu5+Kz38 gXFWhsToaDFe2hb0Jgry7bBsfO25cxt2lWI5JCMBJsNopDhJS+inQyshj+a6SKdSZiAs TywA== X-Gm-Message-State: ALoCoQnEjT5xbwKvoD/QYduwseMMD/VyvvDMR6voSWtX5jsAHO0hJ4PYuuHzUqMmgYDbyrNdcJ+u X-Received: by 10.180.87.233 with SMTP id bb9mr8283900wib.10.1396507360637; Wed, 02 Apr 2014 23:42:40 -0700 (PDT) Received: from [192.168.1.10] (AAubervilliers-651-1-161-84.w81-249.abo.wanadoo.fr. [81.249.172.84]) by mx.google.com with ESMTPSA id gc19sm9256187wic.5.2014.04.02.23.42.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 23:42:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "henry.story@bblfish.net" In-Reply-To: <533C83A9.8090302@mit.edu> Date: Thu, 3 Apr 2014 08:42:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C4B191E-2CF8-444A-8FC7-C177DAC3AB28@bblfish.net> References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz> <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net> <533C83A9.8090302@mit.edu> To: Andy Lutomirski X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b1Cs07Pu2J6HHddXWABu7FDmlfI 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: Thu, 03 Apr 2014 06:42:50 -0000 If I may intervene as an outsider who has a use case. My use case is = simple: allow peer to peer secure http connections - i.e. clients communicating = with servers, servers with servers, ... - with decentralised identity, decentralised access control, using if possible just TLS, DANE and HTTP. =20 All of this actually can work with current versions of TLS, as shown by various implementations of the WebId specs=20 http://www.w3.org/2005/Incubator/webid/spec/ . ( eg.=20 https://github.com/stample/rww-play ) even if I don't doubt that there = could be improvements which closer analysis by members of this group would = show up. But it seems that HTTP2.0 and SPDY is having trouble with it as shown on = this thread http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0000.html It would be nice if the speed improvements in SPDY did not come at the = cost of security and a distributed social web. =20 On 2 Apr 2014, at 23:39, Andy Lutomirski wrote: > On 03/30/2014 11:04 PM, Dan Harkins wrote: >>=20 >>=20 >> On Sun, March 30, 2014 9:09 pm, Watson Ladd wrote: >>> On Sun, Mar 30, 2014 at 6:16 PM, Dan Harkins = wrote: >>>>=20 >>>> On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote: >>>>> Dan Harkins writes: >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> Some of us are more worried about making it fit for purpose than = in >>>>> fiddling >>>>> with crypto details. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> Yes, IND-CCA is a good definition of encryption "working correctly". >=20 > There's a difference between IND-CCA and IND-CCA2. >=20 >>> 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. I'd like to defend that organisation for having at least got those = pieces into TLS as it currently is. Without their effort we ( a little band of = very poorly funded hackers ) would not have been able to show that the same = technology=20 when tied in with Linked Data, keygen tag in html, LDP and TLS - can in = fact be=20 used to get distributed authentication with X509 certificates very = cheaply.=20 A similar argument can be made for the CA system. It helped get = something going which can be improved greatly with DANE. >>=20 >> Excellent, we have an existence proof for client authentication. And = no >> justification for spending time enumerating use cases that require = it. >=20 > If everyone designing TLS 1.3 thought about what the use cases that = want > or require client authentication, then maybe TLS 1.3 will come up with = a > way of doing client authentication that actually makes sense. >=20 > Conversely, maybe if these were an understanding of the use cases that > require actual renegotiation (as opposed to supplementary = authentication > of the parties that negotiated the original secret), then TLS might = have > avoided supporting renegotiation in the first place. (Hint: I've = never > heard of a legitimate reason that an application would want to > explicitly change keys in the middle of a session.) I always assumed that renegotation was also there to for example allow say an HTTP client that say was browsing a file system using something = like WebDAV or LDP ( https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html )=20= to move to higher levels of security if a resource required it. But I = have=20 not come around to implement anything like this, because doing = distributed=20 authentication and access control is already a lot of work. ( so I don't=20= even know if renegotiation is the right tool for that, but was relying = on the collective wisdom of this group. :-) >=20 >>> 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. >>=20 >> You are obviously mistaking a use case document for a specification. >=20 > I think that Watson is actually saying that the WG should decide what > security properties TLS 1.3 should actually have. Then it should > document those properties. Then people can and should verify that the > eventual specification actually has those properties. >=20 > --Andy >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From nobody Thu Apr 3 01:55: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 38BD51A011A for ; Thu, 3 Apr 2014 01:55:49 -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 qS5pn0LfoTHk for ; Thu, 3 Apr 2014 01:55:45 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 443801A0116 for ; Thu, 3 Apr 2014 01:55:45 -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=PVn+6y3H6s312praR/aHAHxqqAIzQ2oEgPMnK+DfcSc=; b=BdZ3bJEcIWeoef50gJJNx6Fj0lvxjEgY+/+W1tvOnRqvW0zfXkTH6LB5qa3rYpYCTzPIAwtgh/PV3eiUb5bTbM9e1wCYV7BZW1ZoRfk+prDEpvROuApySYQ5tp3BtUxto5a/yVYBnpHmyg71IPfQ6f+QodRJZWocsc1pgLSud+I=; 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 1WVdQh-0000qn-4A; Thu, 03 Apr 2014 10:55:23 +0200 Message-ID: <533D2207.807@polarssl.org> Date: Thu, 03 Apr 2014 10:55:35 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrey Jivsov , tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <533CF9C5.7030107@brainhub.org> In-Reply-To: <533CF9C5.7030107@brainhub.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/clJMggaFB6p4d2EhOBXhVdUCf3I Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 08:55:49 -0000 On 03/04/2014 08:03, Andrey Jivsov wrote: > The ECPoint is defined as follows, > > struct { > opaque point <1..2^8-1>; > } ECPoint; > > Is the format on the wire per section 2.3 > 33 32 xx xx xx ... xx > or, suggested, > 65 64 xx xx xx ... xx yy yy yy ... yy ? > > Or I am reading it incorrectly and the extra byte mentioned in the draft > is actully a part of standard TLS encoding of the length byte? > The intention of the current draft is that the wire format be 32 xx xx ... xx So the "additional length byte" is indeed just the one from the TLS encoding. In the next iteration of the draft, it might change to 33 tt xx xx .. xx Where tt would be an "encoding type" which would allow for future extensions like transmitting y too, or a bit of y, or (parts of) other representation (eg Edwards coordinates). Manuel. From nobody Thu Apr 3 01:57: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 37DD61A011A for ; Thu, 3 Apr 2014 01:57:26 -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 JgQ2rMWpdh9O for ; Thu, 3 Apr 2014 01:57:22 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34E1A0116 for ; Thu, 3 Apr 2014 01:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=ZuahSQeNWaIEPC4GomToY+ZYhcq2qUFHSGWxU4QLuxM=; b=FzouEH887YKvJ1EBZRy49sadxLUlhGyn068hk8kmWxcCTmdCZjz347XhxuHRM/kjkpI3WXtY1CC/DCHmeXqbO09Tg9kiHv0QtHGj+bhdOLBGgWfEHexjP5DpNmKHc3U8urWrkRwtIWJVHbegM8S4OoH1uJEk3tRkzcy/nNXW2CA=; 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 1WVdSG-0000rJ-Ka; Thu, 03 Apr 2014 10:57:00 +0200 Message-ID: <533D2268.5030502@polarssl.org> Date: Thu, 03 Apr 2014 10:57:12 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Salz, Rich" , Alyssa Rowan , "tls@ietf.org" References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04E1F7@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04E1F7@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CTnXUwf-SqDOq2SlIGkU0PDplF4 Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 08:57:26 -0000 On 02/04/2014 21:26, Salz, Rich wrote: > Nice summary. > +1 Thanks for putting it together. > I think we had consensus around using the little-endian point format, Agreed. > but > this requires some more overhead (a new ECPoint type and an IANA registry) > that nobody has stepped up to do yet. > Yep. I'll try to update the draft soon, probably over the week-end. Manuel. From nobody Thu Apr 3 04:55: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 0A0351A01E5 for ; Thu, 3 Apr 2014 04:55:05 -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, FREEMAIL_FROM=0.001, 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 Cd1ME0QH62J6 for ; Thu, 3 Apr 2014 04:55:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8A31A0087 for ; Thu, 3 Apr 2014 04:55:00 -0700 (PDT) Received: from netb ([47.67.154.91]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MFi1J-1WH9eF1Izl-00EZmI; Thu, 03 Apr 2014 13:54:54 +0200 From: Bjoern Hoehrmann To: Anders Rundgren Date: Thu, 03 Apr 2014 13:54:56 +0200 Message-ID: References: <676D7423-514E-40A1-9CE5-DCBE3E5811FC@bblfish.net> <533BBF61.6060307@gmail.com> In-Reply-To: <533BBF61.6060307@gmail.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9mtNRbV/A6tPBjXiPNVBTLeaPkaYdKSOn774dwieu4YGG/zztD3 rg10GK0PdY2crHyEO96H3DvMibKDodnyPAlzJUjXTlyavv+7u0LSOXrTH8QrJw6X45Ti4vG UMIUMafsxhDZKCSrhN4k827Unkyy1JTp1CfeZxRotitzdvh6GrQ0ITpZs/QHXEHUf2OiImI IfcBwg2p9sj3gycp0dZMw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5nt4WH_YRQW1aQp00vetJA7JF-s Cc: TLS Mailing List Subject: Re: [TLS] registering x-509 mime types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2014 11:55:05 -0000 * Anders Rundgren wrote: >AFAIK, the "x-" actually means non-standard. There is some truth in that, but note http://tools.ietf.org/html/rfc6838 Note that types with names beginning with "x-" are no longer considered to be members of this tree (see [RFC6648]). Also note that if a generally useful and widely deployed type incorrectly ends up with an "x-" name prefix, it MAY be registered using its current name in an alternative tree by following the procedure defined in Appendix A. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Thu Apr 3 06:09: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 C110A1A0332 for ; Thu, 3 Apr 2014 06:09:07 -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 CmaXCZR2ybED for ; Thu, 3 Apr 2014 06:08:55 -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 2D7D51A029C for ; Thu, 3 Apr 2014 06:08:31 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so1847436wgh.27 for ; Thu, 03 Apr 2014 06:08: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=AHrUGXSOLl5dkaTczmMgG6dkARFuliK6eJdDnpuZ5VU=; b=UshleGQnJzkzw5DQJV7ivY9caitEkvFSZe6+sO36ZUCm7ZL2txZVawWEbSI+PtB0ZM CrlSmkDkiVSwTgRfV0tCVV8LozYDje8LR/jRy62ukKosbFWnYAZ8wEFMBx8Zv38pzc5Q WSmdInvjOC5yclHxivpQ5BR1hwGrTlISHQRw22K90r2jP5AxFk2c8+DVbWquyxdg+kkt ji8ingtCHw1M9GU+539YAnCQFtn0a+4prMvD4Hd/EQ/HYdmLlGMIhoT46zFVzCbdONrj 5KN8MI8dd9bNQsTu2d3c60HC5WLWdtc1PgtqorqFcvzlzoB1S7pOOqTJCATgGO7EyiTZ MqIw== X-Received: by 10.194.201.73 with SMTP id jy9mr10128161wjc.51.1396530507440; Thu, 03 Apr 2014 06:08:27 -0700 (PDT) Received: from [192.168.1.99] (40.247.130.77.rev.sfr.net. [77.130.247.40]) by mx.google.com with ESMTPSA id ct2sm7639360wjb.33.2014.04.03.06.08.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 06:08:26 -0700 (PDT) Message-ID: <533D5D44.9050904@gmail.com> Date: Thu, 03 Apr 2014 15:08:20 +0200 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: Bjoern Hoehrmann References: <676D7423-514E-40A1-9CE5-DCBE3E5811FC@bblfish.net> <533BBF61.6060307@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/Ad12lRdhei_QlR7UtKqqmwGMhok Cc: TLS Mailing List Subject: Re: [TLS] registering x-509 mime types X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2014 13:09:08 -0000 On 2014-04-03 13:54, Bjoern Hoehrmann wrote: > * Anders Rundgren wrote: >> AFAIK, the "x-" actually means non-standard. > > There is some truth in that, but note http://tools.ietf.org/html/rfc6838 > > Note that types with names beginning with "x-" are no longer > considered to be members of this tree (see [RFC6648]). Also note > that if a generally useful and widely deployed type incorrectly ends > up with an "x-" name prefix, it MAY be registered using its current > name in an alternative tree by following the procedure defined in > Appendix A. > So it took a decade for the IETF to find out that pragmatism MAY be useful :-) Anders From nobody Thu Apr 3 06: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 EF3961A01BC for ; Thu, 3 Apr 2014 06:33:09 -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 75Z4__ETHrMP for ; Thu, 3 Apr 2014 06:33:05 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB51A0152 for ; Thu, 3 Apr 2014 06:33:05 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so1804019pdi.30 for ; Thu, 03 Apr 2014 06:33:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=84/17TxdK0O2mLLwIOAom8DPwhahY9eXdcjqjk0tsxI=; b=Bch6I08pqEiwziQhdMGFMS4ix0a3BH9eIBJNhfOypN6a35A32rCZEsT5tXRapxo61b mY/GkDJSe9r4g6P650q/RT2FvVWY8RMV6mn08KXsVZCuW2+O4GxCk56eIW90qKdRlo55 t6GokjXVsbcr8ySaQG/q4TTfhTD1j0fHmG9rIVIyai4bNEhka3HPeBKMXkvzDbXVHNxf S9wnEsifhTAA/9tcSr/0CzsmrAYLJlPA1NvEiscDZpDqBkNjQQrYcXA0KntyppIZ/RYs Qhdy906C7EzJYZYnt2VSlPfZuCea5vDStW2ub0biIMA9SiwoTWZpsGR5aD/mOEBcbcfI zpGw== X-Gm-Message-State: ALoCoQnNHOD+b38egAxD1AEVjxbwSjktNPqubsbtEHHbo73sMsDv8mqXQYyvrlV2RBowNWX01hPm X-Received: by 10.68.254.5 with SMTP id ae5mr7302094pbd.83.1396531981423; Thu, 03 Apr 2014 06:33:01 -0700 (PDT) Received: from [192.168.1.105] ([222.129.109.127]) by mx.google.com with ESMTPSA id pe3sm11307496pbc.23.2014.04.03.06.32.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 06:33:00 -0700 (PDT) Message-ID: <533D62FE.2060400@Vimino.COM> Date: Thu, 03 Apr 2014 21:32:46 +0800 From: Xuelei Fan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Karthik Bhargavan , tls@ietf.org References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> <5316A363.3000801@Vimino.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/gQkaIIUCmbOZG42a-91kQcwizjM 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: Thu, 03 Apr 2014 13:33:10 -0000 I was wondering, can an extension of the renegotiation indication (RFC 5746) be used to bind the client and server? At present, in session resumption initial handshake, the "renegotiation_info" should be empty in both ClientHello and ServerHello messages. In order to bind the client and server more tightly, the renegotiation indication can be extended to use the previous client_verify_data and server_verify_data in session resumption initial handshake (probably only if previous connection supports secure renegotiation). That's, in session resumption initial handshake, client sends previous client_verify_data and server responses with previous client_verify_data plus server_verify_data. This extension of the renegotiation indication need to cache client_verify_data and server_verify_data. Regards, Xuelei On 3/5/2014 9:09 PM, Karthik Bhargavan wrote: > 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 > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Apr 3 06:45:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8491A01FC for ; Thu, 3 Apr 2014 06:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 E78SsvH3JG1F for ; Thu, 3 Apr 2014 06:45:20 -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 0A54B1A01B5 for ; Thu, 3 Apr 2014 06:45:19 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so921638wib.0 for ; Thu, 03 Apr 2014 06:45: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:from:date:message-id:subject:to :cc:content-type; bh=rmPtpPc4JtIpF70B1xg2hRC7PHAoN2iD3R4chRvs+ns=; b=EKpIVW2EFanezdfrbn4+YNo3GTaqk2ypS8Wk86vPQcZ8mouE9Sa+kMCASERoGsPI4l w22tnN6Z+jVp17+2fje6f72xFeaQ4vn8/M5dm9vBLFivCZM41FgSnafC/Lsas2jfzLZN 7yG1PHZTB+Eqr2O/+Qm/YR2dCDJ/NwvRvwHnlwYn54MsVN3QLB5I+ddU6dsJrfo/nRUm zSeUZ3GUX3KpXOn1OeHkX9Vl0mBDLLrhEX3vzSKUwCM4G59JxKeJClX+NailEK7m2lY3 snWH27K4RkbzK81frTebVlqS8jxrM8TZfdDD91gnRUyH6y/O1uR1YN/aOLYJ0iJZ17FW L6Xg== X-Received: by 10.180.81.228 with SMTP id d4mr37877463wiy.49.1396532715153; Thu, 03 Apr 2014 06:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.98.38 with HTTP; Thu, 3 Apr 2014 06:44:55 -0700 (PDT) In-Reply-To: <533D62FE.2060400@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> <533D62FE.2060400@Vimino.COM> From: Karthik Bhargavan Date: Thu, 3 Apr 2014 15:44:55 +0200 Message-ID: To: Xuelei Fan Content-Type: multipart/alternative; boundary=f46d043bdb0e6770df04f6239ce8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UdMOv3_DYue_svaQYwImwEl_nPk 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: Thu, 03 Apr 2014 13:45:25 -0000 --f46d043bdb0e6770df04f6239ce8 Content-Type: text/plain; charset=ISO-8859-1 We cannot modify Renegotiation Indication since TLS extensions are not versioned. But we do have another internet draft called Secure Resumption Indication that does this. Specifically, it takes the session hash of the initial handshake that set up a session and sends it within an extension in the hello messages of the abbreviated handshake. This would indeed fix the renegotiation attack and it would fix tls-unique, but note that it would not fix master-secret based channel bindings (e.g. PEAP). Best, Karthik On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan wrote: > I was wondering, can an extension of the renegotiation indication (RFC > 5746) be used to bind the client and server? > > At present, in session resumption initial handshake, the > "renegotiation_info" should be empty in both ClientHello and ServerHello > messages. > > In order to bind the client and server more tightly, the renegotiation > indication can be extended to use the previous client_verify_data and > server_verify_data in session resumption initial handshake (probably only > if previous connection supports secure renegotiation). That's, in session > resumption initial handshake, client sends previous client_verify_data and > server responses with previous client_verify_data plus server_verify_data. > > This extension of the renegotiation indication need to cache > client_verify_data and server_verify_data. > > Regards, > Xuelei > > > On 3/5/2014 9:09 PM, Karthik Bhargavan wrote: > >> 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 >> >> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --f46d043bdb0e6770df04f6239ce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We cannot modify Renegotiation Indication since TLS e= xtensions are not versioned.

But we do have another= internet draft called Secure Resumption Indication that does this.
Spe= cifically, it takes the session hash of the initial handshake that set up a= session and sends it within an extension in the hello messages of the abbr= eviated handshake.=A0
This would indeed fix the renegotiation attack and it would fix tls-un= ique, but note that it would not fix master-secret based channel bindings (= e.g. PEAP).

Best,
Karthik




On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan <xuelei= .fan@vimino.com> wrote:
I was wondering, can an extension of the ren= egotiation indication (RFC 5746) be used to bind the client and server?

At present, in session resumption initial handshake, the "renegotiatio= n_info" should be empty in both ClientHello and ServerHello messages.<= br>
In order to bind the client and server more tightly, the renegotiation indi= cation can be extended to use the previous client_verify_data and server_ve= rify_data in session resumption initial handshake (probably only if previou= s connection supports secure renegotiation). =A0That's, in session resu= mption initial handshake, client sends previous client_verify_data and serv= er responses with previous client_verify_data plus server_verify_data.

This extension of the renegotiation indication need to cache client_verify_= data and server_verify_data.

Regards,
Xuelei


On 3/5/2014 9:09 PM, Karthik Bhargavan wrote:
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 =A0a certificate in<= br> 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,<= br> 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
=A0 =A0and renegotiation uses the real server certificate
- Initial handshake uses a server certificate,
=A0 =A0and 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 <xuelei.fan@vimino.com
<mailto:xuele= i.fan@vimino.com>> wrote:

=A0 =A0 On 3/5/2014 12:05 AM, Dr Stephen Henson wrote:

=A0 =A0 =A0 =A0 On 04/03/2014 15:23, Martin Thomson wrote:

=A0 =A0 =A0 =A0 =A0 =A0 On 4 March 2014 14:03, Dr Stephen Henson
=A0 =A0 =A0 =A0 =A0 =A0 <lists@drh-consultancy.co.uk
=A0 =A0 =A0 =A0 =A0 =A0 <mailto:lists@drh-consultancy.co.uk>> wro= te:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I performed a few checks with an experiment= al option to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 change the server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 certificate during renegotiation, which I b= elieve
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 simulates the attack
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mechanism. If the client checks certificate= s in band
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then all versions choke
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with a verification error if a chain is unt= rusted. For
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1.0.2 only it also chokes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if the chain is trusted but the hostname do= esn't match.


=A0 =A0 =A0 =A0 =A0 =A0 This is an interesting option. =A0I like the genera= l idea, but
=A0 =A0 =A0 =A0 =A0 =A0 wonder
=A0 =A0 =A0 =A0 =A0 =A0 what "hostname doesn't match" means i= n this case.

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


=A0 =A0 =A0 =A0 I'd be interested if anyone knows of examples where the= server
=A0 =A0 =A0 =A0 certificate does
=A0 =A0 =A0 =A0 have to change during renegotiation and how common that pra= ctice is.

=A0 =A0 I was wondering, if the cipher suite is changed from RSA cert based=
=A0 =A0 to EC cert based (and vice versa), the server certificate would hav= e
=A0 =A0 to change accordingly. =A0Not sure about the case in practice.

=A0 =A0 Xuelei


=A0 =A0 _________________________________________________
=A0 =A0 TLS mailing list
=A0 =A0 TLS@ietf.org = <mailto:TLS@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/tls
=A0 =A0 <https://www.ietf.org/mailman/listinfo/tls>





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



--f46d043bdb0e6770df04f6239ce8-- From nobody Thu Apr 3 06:57: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 850A31A0299 for ; Thu, 3 Apr 2014 06:57:16 -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 58fQ82oSLjNv for ; Thu, 3 Apr 2014 06:57:12 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id EDA371A02AC for ; Thu, 3 Apr 2014 06:57:11 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so1832385pdj.20 for ; Thu, 03 Apr 2014 06:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SlqdRgVJ6x90kMubHTnrdjIWLZROVklqtbdH7VlkS1U=; b=bEMRQeAD/r9EEdeyJK5neoT4Kwhm7hwH5OZqhFkvfg4quFpQCLDB/2Xi3cwUdclmFz 1Q0hxldvDrlLhmGZzxtv/b39TLRhkp9zdYfR8ORcjGZg/Q6wVbcmdcO0ulM7sQkgzjEM aYd+DGCH47F6UW+Q8xysOPd0DY2LDupcUOrv8aId/ZNYggVg4HazlBKvDnaUbNx2P7th j1xPVXb+gaf+uNEfMz+72EAbPEJs7nKFKxwT/BmvboBRo1VSh8qixipZwfVe+J6nwOxM qNzu+pR5PvXXATUVEgMmpS+HGqRXdO6FGyWTvptA4cyliLnMu6eZsus4KAVKgguAb19t wevQ== X-Gm-Message-State: ALoCoQm2OMxchVfCrDGA7B7O4qLYNjSo5gWJWBz+KPCUxEqywbIJIxJZS574DByxO5GWxFYQI4vg X-Received: by 10.66.148.230 with SMTP id tv6mr7436860pab.155.1396533427821; Thu, 03 Apr 2014 06:57:07 -0700 (PDT) Received: from [192.168.1.105] ([222.129.109.127]) by mx.google.com with ESMTPSA id n6sm11432098pbj.22.2014.04.03.06.57.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 06:57:07 -0700 (PDT) Message-ID: <533D68A6.3020702@Vimino.COM> Date: Thu, 03 Apr 2014 21:56:54 +0800 From: Xuelei Fan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Karthik Bhargavan References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <5315F9BA.4060805@drh-consultancy.co.uk> <5316A363.3000801@Vimino.COM> <533D62FE.2060400@Vimino.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/SIIQ6CyK672GxhQH13w5GMPloIk 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: Thu, 03 Apr 2014 13:57:16 -0000 On 4/3/2014 9:44 PM, Karthik Bhargavan wrote: > We cannot modify Renegotiation Indication since TLS extensions are not > versioned. > Sure, need to use a new extension ID. > But we do have another internet draft called Secure Resumption > Indication that does this. > Specifically, it takes the session hash of the initial handshake that > set up a session and sends it within an extension in the hello messages > of the abbreviated handshake. Is it published? Can I have the link of the draft? Thanks & Regards, Xuelei > This would indeed fix the renegotiation attack and it would fix > tls-unique, but note that it would not fix master-secret based channel > bindings (e.g. PEAP). > > Best, > Karthik > > > > > On Thu, Apr 3, 2014 at 3:32 PM, Xuelei Fan > wrote: > > I was wondering, can an extension of the renegotiation indication > (RFC 5746) be used to bind the client and server? > > At present, in session resumption initial handshake, the > "renegotiation_info" should be empty in both ClientHello and > ServerHello messages. > > In order to bind the client and server more tightly, the > renegotiation indication can be extended to use the previous > client_verify_data and server_verify_data in session resumption > initial handshake (probably only if previous connection supports > secure renegotiation). That's, in session resumption initial > handshake, client sends previous client_verify_data and server > responses with previous client_verify_data plus server_verify_data. > > This extension of the renegotiation indication need to cache > client_verify_data and server_verify_data. > > Regards, > Xuelei > > > On 3/5/2014 9:09 PM, Karthik Bhargavan wrote: > > 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 > > > > > > > > > _________________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/__listinfo/tls > > > > From nobody Thu Apr 3 06: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 B4E841A01B5 for ; Thu, 3 Apr 2014 06:57:22 -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_38=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 W4mD7CgUXmSb for ; Thu, 3 Apr 2014 06:57:17 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF511A029D for ; Thu, 3 Apr 2014 06:57:16 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ec20so1344383lab.39 for ; Thu, 03 Apr 2014 06:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2dDHTlcxDCE/ZL/iz+wbXJ/guIjLoSnYao/y1hzd1AE=; b=xvgjpHfTCfuZnSPJ6eZtvc8/eiqsWdfYlvTP90bTy7uu1tfsI6b/MsKffNJScl+mWX RTfb5cYGcGEOvNygBoYC/NTANAEXdPwKfwaV80SD2jhD/kZIXOuQcdKIcTGEAEjpkJBu jJ+Dlv5v850OHjPq/lRkeCHX25vqk7if5/YZnHWlFKBTa/bLJXEBsQLe2nPbb/5q2KLa Pm0NcVHYbpRj+aHLE5VsC/HMSWlcfy+3ORLwS5bT3PX98910YxmaHl16gfkfJKmImEv+ 88CABnbmd4sSLaM/Gjn9/Zxsv7k15ZQ3bcZnZk//3NbgwyOuE98A/Bd8UdV2S6ETtm1k 0TSA== MIME-Version: 1.0 X-Received: by 10.112.12.97 with SMTP id x1mr15259lbb.78.1396533431699; Thu, 03 Apr 2014 06:57:11 -0700 (PDT) Received: by 10.152.18.133 with HTTP; Thu, 3 Apr 2014 06:57:11 -0700 (PDT) Received: by 10.152.18.133 with HTTP; Thu, 3 Apr 2014 06:57:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Apr 2014 06:57:11 -0700 Message-ID: From: Liz meeks To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a11c3a1061d0f1204f623c7f1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YJusaLRnzOChE9Gy71OG17jdPQY 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: Thu, 03 Apr 2014 13:57:23 -0000 --001a11c3a1061d0f1204f623c7f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please stop sending me these emails On Mar 3, 2014 8:47 AM, "Karthikeyan Bhargavan" < karthikeyan.bhargavan@inria.fr> wrote: > > 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's version than Ray's > 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 suc= h > protocols. > > > I would note that the renegotiation handshake we are speaking about is no= t > 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 dat= a > 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" > 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, > 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 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c3a1061d0f1204f623c7f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Please stop sending me these emails

On Mar 3, 2014 8:47 AM, "Karthikeyan Bharga= van" <karthikeyan= .bhargavan@inria.fr> wrote:

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
a= ttack of Ray&Dispensa and Rex.

Yes,= indeed, the impact of our renegotiation attack is comparable to the 2009 r= enegotiation attacks.
In fact, the setup of our attack is closer to Rex’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 f= orwards and ends up NOT
knowing the keys shared by C and S. Any authenti= cation 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
protocols.

I would note tha= t the renegotiation handshake we are speaking about is not exactly a standa= lone authentication protocol. It is the second handshake on a connection, w= ith different client or server identity than the first handshake. This leav= es 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 co= nsidered. 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 interpre= ts data
that may have been sent under TLS protection in the first 2 step= s in the
attack: it may assume it came from C when in fact it came from M.

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

Step 3. (Renegotiation C-M-S)

...
Both handshakes complete with new mutually-authenticated sessions an= d
record keys.
C now thinks it is connected to S and S thinks it is c= onnected to C.
(M does not know the new record keys but its previous mes= sages 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* c= onnected to C
after step 3! (not just that they "think" they a= re so-connected).

Cheers

Kenny


On 03/03/2014 15:20, "Karthikeyan B= hargavan"
<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
fo= und as part of our research on trying to prove cryptographic
security fo= r a TLS implementation [1].  We presenting some of the
materials he= re to kick-start some discussion and get early comments on
our proposed countermeasure. Some people on the list already know of
the= se attacks but this is the first public disclosure.

More details are= at https://sec= ure-resumption.com
<https://se= cure-resumption.com/> [2]

Scenario
=3D=3D=3D=3D=3D=3D
C= onsider a client C that normally authenticates to a server S using a
cli= ent 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
a= uthenticate its own connection to S.

The attack relies on the combin= ation 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
h= andshakes, C has a connection to M and M has a connection to
S. During t= he 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 beenprevented by the Renegotiation Indication (RI) extension [3] but by
inj= ecting session resumption between the two full handshakes, we are
able t= o 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<= br>exchange.  The webpage [2] has diagrams that will be easier to foll= ow,
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 recei= ves an encrypted PMS from C and reencrypts it towards S.
- Both handshakes complete with new sessions and record keys.
 Bot= h 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 unc= hanged between C
and S.
- Note that the RI extensions on both handshakes are empty,
&= nbsp;since it is the first handshake on the connection
- Both handshakes= complete with new record keys (and reuse old sessions)
 Both conn= ections have the same record keys and handshake logs (verify
data)
 (M still knows the record keys and can send messages in eit= her
direction.)

Step 3. (Renegotiation C-M-S)
- S requests M f= or renegotiation with client certificate.
 M requests C for renego= tiation 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.
- Bot= h 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 pre= vious messages to S on
the same connection
 may be treated as a= uthenticated by C.)

At the end of Step 3, S has an incoming connection on which it
initi= ally 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 lat= er S=B9s certificate. If C refuses to accept this
change of server ident= ity, 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 ren= egotiation.

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

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

The propos= ed draft is available at:
http://secure-resumpt= ion.com/draft-bhargavan-tls-session-hash-00.txt

The key idea is that each full handshake is associated with a sessionhash, 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_m= aster_secret,
         &nb= sp;            =             &nb= sp;    "extended master secret",
            &n= bsp;            = ;            &n= bsp;  session_hash) [0..47];

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

An alternativ= e countermeasure would be an extension (along the lines
of [3]) that inc= ludes the session hash as defined above in the
ClientHello and ServerHel= lo messages of the abbreviated
handshake. This would provide an explicit link between the resumption
ha= ndshake and its original full handshake, and hence prevent the
renegotia= tion 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://sec= ure-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



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

--001a11c3a1061d0f1204f623c7f1-- From nobody Thu Apr 3 09:53: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 986FD1A025F for ; Thu, 3 Apr 2014 09:53:06 -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 kBEgkhNG8ezd for ; Thu, 3 Apr 2014 09:53: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 9C7231A021B for ; Thu, 3 Apr 2014 09:53:02 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so1810029ykb.30 for ; Thu, 03 Apr 2014 09:52: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:content-transfer-encoding; bh=a1YWVqWWgbOrD/f4WMesQNtLB5McGuENwCE317lrENI=; b=Zzz6a2TBwry7R/YMNucY6hN2yFxIkf7UEr6m0dTSZLJbnLI20aqHUsCp02SsQsuUiQ IJGAEdzD4ketumsWisEFlBfpmOXFR8NMuN/vqELVwl7MpPPEYyQaep0OlQXVj829sJSu x4lC2CkjxxhrXT7AAr5er09+wmPRQFaOz3Mlixz07NrG/2FxeUzgFLylZB7kmmkOZk7A E0TwpCrxAv/f9Fp4N1517cnoh9WwM98R+CKuRCjiNC6Kybp8Fh1ATIBrQXzXWIvN3hOJ NlCcYYR4W19yejznwDHhCyjLIDiqSXIf22VGWjVr8J9gca06ZFriR+Sa+Okh5z8kumki IO8w== MIME-Version: 1.0 X-Received: by 10.236.191.67 with SMTP id f43mr9836445yhn.60.1396543978215; Thu, 03 Apr 2014 09:52:58 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 3 Apr 2014 09:52:58 -0700 (PDT) In-Reply-To: <533D2207.807@polarssl.org> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <533CF9C5.7030107@brainhub.org> <533D2207.807@polarssl.org> Date: Thu, 3 Apr 2014 09:52:58 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PyP38InJlz6NaGTP9lrYdZwVkJE Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 16:53:06 -0000 On Thu, Apr 3, 2014 at 1:55 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 03/04/2014 08:03, Andrey Jivsov wrote: >> The ECPoint is defined as follows, >> >> struct { >> opaque point <1..2^8-1>; >> } ECPoint; >> >> Is the format on the wire per section 2.3 >> 33 32 xx xx xx ... xx >> or, suggested, >> 65 64 xx xx xx ... xx yy yy yy ... yy ? >> >> Or I am reading it incorrectly and the extra byte mentioned in the draft >> is actully a part of standard TLS encoding of the length byte? >> > The intention of the current draft is that the wire format be > > 32 xx xx ... xx > > So the "additional length byte" is indeed just the one from the TLS encod= ing. > > In the next iteration of the draft, it might change to > > 33 tt xx xx .. xx > > Where tt would be an "encoding type" which would allow for future extensi= ons > like transmitting y too, or a bit of y, or (parts of) other representatio= n (eg > Edwards coordinates). I don't think this is a good idea. At the time when one side sees the point it is too late to negotiate. So points with different encodings should be indicated as different in the Client Hello message to enable negotiation of which one to send. Furthermore, I don't see benefit to the potential extensions yet for pure DH. Also, do we really need a length prefix on a string that is always 32 bytes long? I get that the TLS encoding provides that, but length prefix formats are a can of worms: what should happen when 33 0 or 32 32 xx .. are encountered? Sincerely, Watson Ladd > > Manuel. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Apr 3 10:36: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 189C61A024E for ; Thu, 3 Apr 2014 10:36:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 U-8e4Yyv3YVC for ; Thu, 3 Apr 2014 10:36:26 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4BE1A0245 for ; Thu, 3 Apr 2014 10:36:26 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id lQsf1n0040b6N64A1VcNYm; Thu, 03 Apr 2014 17:36:22 +0000 Received: from [127.0.0.1] ([71.202.164.227]) by omta03.emeryville.ca.mail.comcast.net with comcast id lVcD1n00J4uhcbK8PVcLwa; Thu, 03 Apr 2014 17:36:21 +0000 Message-ID: <533D9BEA.9030907@brainhub.org> Date: Thu, 03 Apr 2014 10:35:38 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <533CF9C5.7030107@brainhub.org> <533D2207.807@polarssl.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060504050604010202080701" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396546582; bh=OKIFvdF1TA6+xec4kwkOeVVk3GAywn32BLUmAA4tTZU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=muVn33FOPa9aq18Xr0Zp8iQYoKeaTxLeabT4US+tgOENwI7TTLGpXe9s/TXg2Xjvx x4N0Fbp8LfGDJ2w6fLuG/ZTlrSkVTVYkNlJh1QKU7va6DuvzDiFXF5f8onKtdUYCUF wzQxW6Sjn1mNTGeJMd4SPQjQWXsiaWhCIA9mM3BRPSlywdXd4NsdCYapSuffW+dlAd nScDDati5W0ek0Ck23+Ab7zfj+3GkyXi2u+Rgw7BANg7D46ypD88EbDZYbQNT4eYiz C+bwmYa53lXPJ6cq/5hg0r7niF1F9wVdokqqfErt2MPufGJdR7FR+rL83BaRBWRHK3 j91y+Z22zVPSg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dCduf5JuM_2EbCc6rMq-kktFUNI Cc: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6k=?= =?UTF-8?B?LUdvbm5hcmQ=?= Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 17:36:30 -0000 This is a multi-part message in MIME format. --------------060504050604010202080701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/03/2014 09:52 AM, Watson Ladd wrote: > On Thu, Apr 3, 2014 at 1:55 AM, Manuel Pégourié-Gonnard > wrote: >> On 03/04/2014 08:03, Andrey Jivsov wrote: >>> The ECPoint is defined as follows, >>> >>> struct { >>> opaque point <1..2^8-1>; >>> } ECPoint; >>> >>> Is the format on the wire per section 2.3 >>> 33 32 xx xx xx ... xx >>> or, suggested, >>> 65 64 xx xx xx ... xx yy yy yy ... yy ? >>> >>> Or I am reading it incorrectly and the extra byte mentioned in the draft >>> is actully a part of standard TLS encoding of the length byte? >>> >> The intention of the current draft is that the wire format be >> >> 32 xx xx ... xx >> >> So the "additional length byte" is indeed just the one from the TLS encoding. >> >> In the next iteration of the draft, it might change to >> >> 33 tt xx xx .. xx >> >> Where tt would be an "encoding type" which would allow for future extensions >> like transmitting y too, or a bit of y, or (parts of) other representation (eg >> Edwards coordinates). > I don't think this is a good idea. At the time when one side sees the > point it is too late to negotiate. So points with different encodings > should be indicated as different in the Client Hello message to enable > negotiation of which one to send. Furthermore, I don't see benefit to > the potential extensions yet for pure DH. I second this. > Also, do we really need a length prefix on a string that is always 32 > bytes long? I get that the TLS encoding provides that, but length > prefix formats are a can of worms: what should happen when 33 0 or 32 > 32 xx .. are encountered? > I assume you are commenting on the case with tt present. Certainly, there will need to be consistency checks with such a tt. My reply regarding the current draft with clarification from Manuel follows: RFC 5246 is listed as a normative reference. As such, it defines the the encoding for the opaque something <1..2^8-1> The reader is expected to know that "something" is encoded with an additional byte for the length. Thus, I find the item (2) in sec. 2.3 confusing (IMHO more confusing than helpful). > Note that ECPoint.point differs from the definition of public keys in > [Curve25519 ] in two ways: (1) the byte-ordering is big-endian, wich > is more uniform with how big integers are represented in TLS, and (2) > there is an additional length byte (so ECpoint.point is actually 33 > bytes), again for uniformity (and extensibility). Would the following be clearer: > Unlike the definition of public keys specified in [Curve25519], > ECPoint.point uses big-endian byte ordering. As defined in [RFC5246], > the ECPoint.point is serialized with one-byte block size. The payload must be 32 > bytes, even when one or more leading bytes are zeros. ... --------------060504050604010202080701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 04/03/2014 09:52 AM, Watson Ladd wrote:
On Thu, Apr 3, 2014 at 1:55 AM, Manuel Pégourié-Gonnard
<mpg@polarssl.org> wrote:

On 03/04/2014 08:03, Andrey Jivsov wrote:

The ECPoint is defined as follows,

            struct {
                opaque point <1..2^8-1>;
            } ECPoint;

Is the format on the wire per section 2.3
    33 32 xx xx xx ... xx
or, suggested,
    65 64 xx xx xx ... xx yy yy yy ... yy ?

Or I am reading it incorrectly and the extra byte mentioned in the draft
is actully a part of standard TLS encoding of the length byte?


The intention of the current draft is that the wire format be

32 xx xx ... xx

So the "additional length byte" is indeed just the one from the TLS encoding.

In the next iteration of the draft, it might change to

33 tt xx xx .. xx

Where tt would be an "encoding type" which would allow for future extensions
like transmitting y too, or a bit of y, or (parts of) other representation (eg
Edwards coordinates).

I don't think this is a good idea. At the time when one side sees the
point it is too late to negotiate. So points with different encodings
should be indicated as different in the Client Hello message to enable
negotiation of which one to send. Furthermore, I don't see benefit to
the potential extensions yet for pure DH.
I second this. 

Also, do we really need a length prefix on a string that is always 32
bytes long? I get that the TLS encoding provides that, but length
prefix formats are a can of worms: what should happen when 33 0 or 32
32 xx .. are encountered?
I assume you are commenting on the case with tt present. Certainly, there will need to be consistency checks with such a tt.

My reply regarding the current draft with clarification from Manuel follows:

RFC 5246 is listed as a normative reference. As such, it defines the the encoding for the

   opaque something <1..2^8-1>
The reader is expected to know that "something" is encoded with an additional byte for the length. Thus, I find the item (2) in sec. 2.3 confusing (IMHO more confusing than helpful). 


   Note that ECPoint.point differs from the definition of public keys in
   [Curve25519] in two ways: (1) the byte-ordering is big-endian, wich
   is more uniform with how big integers are represented in TLS, and (2)
   there is an additional length byte (so ECpoint.point is actually 33
   bytes), again for uniformity (and extensibility).

Would the following be clearer:

> Unlike the definition of public keys specified in [Curve25519],
> ECPoint.point uses big-endian byte ordering. As defined in [RFC5246],
> the ECPoint.point is serialized with one-byte block size. The payload must be 32
> bytes, even when one or more leading bytes are zeros.

...
--------------060504050604010202080701-- From nobody Thu Apr 3 12:14: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 52E3B1A02B2 for ; Thu, 3 Apr 2014 12:14:19 -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 RsqIiqfHqMgy for ; Thu, 3 Apr 2014 12:14:15 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC001A02B0 for ; Thu, 3 Apr 2014 12:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=5h1Ioru5bJFF76iRv+FoJorpqGL4U1S7sYrgnxH7hXU=; b=S1M400m4N1HQ16IPHv5mvsJS7mwQb5oTuwDGPSCVPHzKSVZjErp6ihXDvBUGFYwK50O2OzT24VjEPBzhf/TZAebcm9pEAT7KiVPywbIjyRV6sC3lhkDlX5+G7KmIyWu/j2pfJRg1198hNifV6lqP49V7qnXTIR1x7Hido7vxN7A=; 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 1WVn5A-0001tD-Ge; Thu, 03 Apr 2014 21:13:51 +0200 Message-ID: <533DB2F4.5090803@polarssl.org> Date: Thu, 03 Apr 2014 21:13:56 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Watson Ladd References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <533CF9C5.7030107@brainhub.org> <533D2207.807@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RqLKSwujXk1vwwf5TzDXUVSdnA8 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 19:14:19 -0000 On 03/04/2014 18:52, Watson Ladd wrote: > On Thu, Apr 3, 2014 at 1:55 AM, Manuel Pégourié-Gonnard > wrote: >> In the next iteration of the draft, it might change to >> >> 33 tt xx xx .. xx >> >> Where tt would be an "encoding type" which would allow for future extensions >> like transmitting y too, or a bit of y, or (parts of) other representation (eg >> Edwards coordinates). > > I don't think this is a good idea. At the time when one side sees the > point it is too late to negotiate. So points with different encodings > should be indicated as different in the Client Hello message to enable > negotiation of which one to send. That's the intention, yes (indicating supported point formats in the existing ClientHello and ServerHello extensions). > Furthermore, I don't see benefit to > the potential extensions yet for pure DH. > Just because we can't see a benefit for extensions now doesn't mean we shouldn't leave the door open for later ideas. > Also, do we really need a length prefix on a string that is always 32 > bytes long? I get that the TLS encoding provides that, but length > prefix formats are a can of worms: what should happen when 33 0 or 32 > 32 xx .. are encountered? > Well, what's already hapenning: implementations check for consistency. This is no different than with the current short Weierstrass curves. Manuel. From nobody Thu Apr 3 12:15: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 28FE61A02B8 for ; Thu, 3 Apr 2014 12:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 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, J_CHICKENPOX_75=0.6, 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 2DyWJRtBlJHy for ; Thu, 3 Apr 2014 12:15:21 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2F1A0295 for ; Thu, 3 Apr 2014 12:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=HJIqkqqk93Y/H5jO2U6al65uNdOHQ2Ovbg2wUr1QuJE=; b=AIr+3J7G2S1EEXpQ/OUrXzuESfO4zWVY3fXnGPIj0XU4sjuaeDRpJIb/GyPuyoYbpNZ4i0WwqV2wRVQhilJaT4gCbubS/qDuc7cgKqfuoB0znWa+sp2gT/5brsF5VH27XvWD6lUkiDgky12tnD38Rkxd1Jj7wCYfoTOj8bAciOo=; 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 1WVn6I-0001th-1c; Thu, 03 Apr 2014 21:14:59 +0200 Message-ID: <533DB33C.2060106@polarssl.org> Date: Thu, 03 Apr 2014 21:15:08 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrey Jivsov , "tls@ietf.org" References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <533C554A.7080607@akr.io> <533CF9C5.7030107@brainhub.org> <533D2207.807@polarssl.org> <533D9BEA.9030907@brainhub.org> In-Reply-To: <533D9BEA.9030907@brainhub.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pR7OkyXeNAPGwAOtoc2UW5XuRXg Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 03 Apr 2014 19:15:25 -0000 On 03/04/2014 19:35, Andrey Jivsov wrote: > My reply regarding the current draft with clarification from Manuel follows: > > RFC 5246 is listed as a normative reference. As such, it defines the the > encoding for the > > opaque something <1..2^8-1> > > The reader is expected to know that "something" is encoded with an additional byte for the length. Thus, I find the item (2) in sec. 2.3 confusing (IMHO more confusing than helpful). > >> Note that ECPoint.point differs from the definition of public keys in >> [Curve25519 ] in two ways: (1) the byte-ordering is big-endian, wich >> is more uniform with how big integers are represented in TLS, and (2) >> there is an additional length byte (so ECpoint.point is actually 33 >> bytes), again for uniformity (and extensibility). > > Would the following be clearer: > >> Unlike the definition of public keys specified in [Curve25519], >> ECPoint.point uses big-endian byte ordering. As defined in [RFC5246], >> the ECPoint.point is serialized with one-byte block size. The payload must be 32 >> bytes, even when one or more leading bytes are zeros. > Thanks for the helpful suggestion. Manuel. From nobody Fri Apr 4 18:36: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 086501A01E1 for ; Fri, 4 Apr 2014 18:36:02 -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 Mez9zRXRw10d for ; Fri, 4 Apr 2014 18:35:57 -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 5A9A41A01D4 for ; Fri, 4 Apr 2014 18:35:57 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so3838261yho.4 for ; Fri, 04 Apr 2014 18:35:52 -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=AJXBWkFwQejJZRJ3n2fZjS0laegXCDZj7SLhq6rPP7A=; b=CixrSsjr+J6V83VmPt53k6l7s3W4sD/5vD6xlVGAKniZYW1e0RaHI9luvw0ljARa5m UHPYcmiB6+ui/aA6yWEkRHDXaK62TvKc6HpIHd6QYmsal6t94+UBUlo/+l7N0bk1IGbg 09AD28IfgOV+dwKhaQaF0XwEeba/CS3EOSJvTWvwOtuhXtFe9zE3/9jJy49geiB1zVw6 uO2pvcMDMbcDkSZBF3nNZETEk5bCDELzFtD+tRSz4MZMaU4fBHlxt0plpDLJeGBhhDk9 iBtyBt5q1qmrERVgJLBRUMG6cfHsEkVY/kvt5/DZVYpNo+V/zg0aYJhIueRyfa4Xkxff jUbQ== MIME-Version: 1.0 X-Received: by 10.236.90.12 with SMTP id d12mr393821yhf.120.1396661752528; Fri, 04 Apr 2014 18:35:52 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 4 Apr 2014 18:35:52 -0700 (PDT) Date: Fri, 4 Apr 2014 18:35:52 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2IVuX727QWPTuFiRoMPuB76LwQY Subject: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 01:36:02 -0000 Dear all, https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of many TLS implementations. Interestingly all tested implementations contain errors, and all but OpenSSL erroneous accepts. Cryptlib was not tested, because it doesn't validate certificates. At the core of these issues is the complexity of certificate validation. Things for this committee to consider: 1: How will DANE make this worse? 2: Is this really the best we can do? What features of X509 led to these problems? 3: This focused on server authentication. How does client authentication fare? 4: Did this actually cover everything? Sincerely, Watson Ladd From nobody Fri Apr 4 18: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 995991A0226 for ; Fri, 4 Apr 2014 18:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 681CvZ8Z1NT3 for ; Fri, 4 Apr 2014 18:49:05 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) by ietfa.amsl.com (Postfix) with ESMTP id 50D301A01E1 for ; Fri, 4 Apr 2014 18:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=sBNd1yPriIPxsRPoSy3jc8wsbYrUZKLneFDvJHLo140=; b=kJoAaDrw2UUTvW7+ZMUPbDhYO5evEo5hulqhKadfwIVQV1iPTtvFKSxMOtVg/p6Eo2ZpMlyG4FJ+Wd8dh7/G9AwgLK7ScWgcP5WSh+xjomMkM0ut+s0whkjDnZNvQBZltZGhVREQDINzVEJ2vXG8AYm805S6OQYvJuIl4NJtzUo=; Received: ; Fri, 04 Apr 2014 18:49:00 -0700 Message-ID: <533F6106.5000308@eff.org> Date: Fri, 04 Apr 2014 18:48:54 -0700 From: Yan Zhu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s8RbiIDpMHJA6b6CI0i79HXXlMAmQiDrJ" Received-SPF: skipped for local relay Received-SPF: skipped for local relay Archived-At: http://mailarchive.ietf.org/arch/msg/tls/flJMmKFIoIIXY2-7SnPJLpCQh-4 Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 01:49:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s8RbiIDpMHJA6b6CI0i79HXXlMAmQiDrJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/04/2014 06:35 PM, Watson Ladd wrote: > Dear all, > https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of > many TLS implementations. Interestingly all tested implementations > contain errors, and all but OpenSSL erroneous accepts. Cryptlib was > not tested, because it doesn't validate certificates. >=20 > At the core of these issues is the complexity of certificate > validation. Things for this committee to consider: >=20 > 1: How will DANE make this worse? > 2: Is this really the best we can do? What features of X509 led to > these problems? > 3: This focused on server authentication. How does client authenticatio= n fare? In case anyone wants to investigate these questions, the code used in that study to generate mutated certificates is at https://github.com/sumanj/frankencert. (You will need a corpus of certificates to start from; the mirrors of EFF's SSL Observatory scan results seem to all be unavailable at the moment, but that should be fixed soon.) -Yan > 4: Did this actually cover everything? >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --=20 Yan Zhu Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134 --s8RbiIDpMHJA6b6CI0i79HXXlMAmQiDrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJTP2EHAAoJENC7YDZD/dnsV1oH/Ayt1x+R8mZ6gx6fbVhfK8Ip 7vLj3p3a52dm5xqppvvka0LmRWFiBbSIlUK6OptQX/DqUes/C0UY2r7PjB5b5EsX 8F/UkN1JGKdP5wg6sr3M+fCEmrc3ZC5xDFAmEoyAHT/c5qrnAO6xv6m80Viq0non HzRrJg1cmc9lbsoUaX9ZHQeuUZej1fc2nO2xs848xsy6fCK+WNJVnhPVZpQGQZ6A JBElRW8FSny1gmJ5Vr0cxzXgbRpGE6TceFlzd5BHnddN7vGy6ArBZ9OR/KMA4HbI 1RRyp77tql/kOqYAwgePjwfUPd2IRo652tmRDtPnRaQazFO1BdA8KYn/q24zVdQ= =1XZu -----END PGP SIGNATURE----- --s8RbiIDpMHJA6b6CI0i79HXXlMAmQiDrJ-- From nobody Fri Apr 4 19:20:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBA71A01ED for ; Fri, 4 Apr 2014 19:20:33 -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 OANUL5SY7-Tl for ; Fri, 4 Apr 2014 19:20:28 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D11A034B for ; Fri, 4 Apr 2014 19:20:26 -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=1396664423; x=1428200423; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=g2HgZNKQaZaEK8Nw+08mY9oqI1FVzSv2wDd3jnbEwjY=; b=SrRkda8P5X/4gT/Kv3AhGVValZKVkUq2nMzPrGX3VOqvA+zy4HYhwXuo McR+UMbCliew/QqBN2QkhNGR8ZOBO0hZW1XHxvhIQvuni+9HBAQAAGjeA L1/66yiNL8YNZcak6mJ7tUbk21+OXLFz+AcuEd0KFtme9Xn9k9EKxhwaX E=; X-IronPort-AV: E=Sophos;i="4.97,798,1389697200"; d="scan'208";a="245397994" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Apr 2014 15:20:21 +1300 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.111]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Sat, 5 Apr 2014 15:20:20 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: Ac9QdZdJ7+UCtTetRMyEs68P42C2Ng== Date: Sat, 5 Apr 2014 02:20:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738A346949@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/kAIRk_b6EvpnzeI8cRld3xzlJvM Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 02:20:34 -0000 Watson Ladd writes:=0A= =0A= >Dear all, https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests = of=0A= >many TLS implementations. Interestingly all tested implementations contain= =0A= >errors, and all but OpenSSL erroneous accepts. Cryptlib was not tested,=0A= >because it doesn't validate certificates.=0A= =0A= ... which is actually wrong, it does support certificate validation, it jus= t=0A= doesn't do it by default because in the large majority of situations where= =0A= cryptlib is used, users don't want to trust or not trust any arbitrary cert= =0A= just because it was bought from a commercial CA. In other words cryptlib= =0A= isn't a web browser that blindly trusts anything that chains to a commercia= l=0A= CA. If you do want that behaviour (and I wouldn't recommend it), it's two= =0A= lines of code to implement. I'll write to the authors in a minute asking t= hem=0A= to correct the statement in the paper.=0A= =0A= Peter.= From nobody Fri Apr 4 21:17: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 D3D3D1A0099 for ; Fri, 4 Apr 2014 21:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncA5fa1OAYV1 for ; Fri, 4 Apr 2014 21:17:52 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC01A007F for ; Fri, 4 Apr 2014 21:17:52 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 144D52AC059 for ; Fri, 4 Apr 2014 21:17: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:cc:content-type; s=cryptonector.com; bh=FVjI9vNEgy/bx+TOoAt4 kK93A88=; b=WjNaUGCEV8/7qJbjhdvSIMOZUAdzDx6fIy52Dk1cpntHGBBaH53Z dQXobLZa4HM0uswqGUsPJPU4xcqsIvfXHauFVRsL1ZrymD9w99x56qIe5pVT2cyt A8VdnS6iaMGwkjjHc51pyCZsoyTkek7miDjNxpgZTgrNxxAs6907ZP4= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id BA98B2AC005 for ; Fri, 4 Apr 2014 21:17:47 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so4363039wes.10 for ; Fri, 04 Apr 2014 21:17:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr415495wjc.84.1396671466390; Fri, 04 Apr 2014 21:17:46 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Fri, 4 Apr 2014 21:17:46 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Fri, 4 Apr 2014 21:17:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 23:17:46 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bb03f9c9f4ae704f643ead8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HnG3bDlIIQIlwlT8FqWXN226rZc Cc: tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 04:17:57 -0000 --047d7bb03f9c9f4ae704f643ead8 Content-Type: text/plain; charset=UTF-8 On Apr 4, 2014 8:36 PM, "Watson Ladd" wrote: > 1: How will DANE make this worse? > 2: Is this really the best we can do? What features of X509 led to > these problems? Let's take #2 first. Here's two entrants: - x.509 naming is impossibly difficult to deal with (see RFC4514); - stapled OCSP is how it should have been from day one -- CRLs add a ton of complexity Back to #1: DNSSEC is a PKI, but with better naming and fewer root CAs. We're going to need CT for DNSSEC. > 3: This focused on server authentication. How does client authentication fare? Very differently. For user authentication I think something more like Persona (still PK, but not Internet-scale PKI) is better. We really need a standard account & device enrollment protocol to make user PK work well -- then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the market likes best. Nico -- --047d7bb03f9c9f4ae704f643ead8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 4, 2014 8:36 PM, "Watson Ladd" <watsonbladd@gmail.com> wrote:
> 1: How will DANE make this worse?
> 2: Is this really the best we can do? What features of X509 led to
> these problems?

Let's take #2 first.=C2=A0 Here's two entrants:

- x.509 naming is impossibly difficult to deal with (see RF= C4514);

- stapled OCSP is how it should have been from day one -- C= RLs add a ton of complexity

Back to #1:=C2=A0 DNSSEC is a PKI, but with better naming an= d fewer root CAs.=C2=A0 We're going to need CT for DNSSEC.

> 3: This focused on server authentication. How does clie= nt authentication fare?

Very differently.=C2=A0 For user authentication I think some= thing more like Persona (still PK, but not Internet-scale PKI) is better.= =C2=A0 We really need a standard account & device enrollment protocol t= o make user PK work well -- then we can land wherever on the PKI..web-of-tr= ust..ad-hoc spectrum the market likes best.

Nico
--

--047d7bb03f9c9f4ae704f643ead8-- From nobody Fri Apr 4 22:15: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 2915B1A01CA for ; Fri, 4 Apr 2014 22:15: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 s0c1qTpqxBSn for ; Fri, 4 Apr 2014 22:15:44 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE21A00A8 for ; Fri, 4 Apr 2014 22:15:44 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so4008265yha.17 for ; Fri, 04 Apr 2014 22:15:39 -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=Ucj2UhG3FOafzOG/zuI/8/JPwBY6h/dZlDR8VN0aOlc=; b=eTavOB93giHdjlkcV/573crbBR1PgcAkln/5YMVIx2WIM9X7/gSR8T+f7Hra5ZJptD uQvq/ElxJctFV2uSLAv8j+FpKsR3Or/6HGN7ydwRFvVKEBtcbAwrhNmu616c5USZSqB0 PyOceVtJ1tXmSYX9RvonK/zKTBFseWlyzmr10I6s5y7/EGoaAPIhkEcSfZzy2ZTY1PN8 kdOboLVYVo/l0E0PDZJB75sxa7dnB0XFYysFhzINd88JUH/aLYGbLdA3Daioc3B1tdHS J9739G0kp2tPqdwNXXlxHik5BsU+xbK8BeEo5oiUyhUnfW7IB0fz5xryXhWXE6PxqapP Q1CA== MIME-Version: 1.0 X-Received: by 10.236.30.230 with SMTP id k66mr22694795yha.57.1396674939354; Fri, 04 Apr 2014 22:15:39 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 4 Apr 2014 22:15:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 22:15:39 -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/OZdfDP2xZna8cCcwlEwoekRxDJI Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 05:15:49 -0000 On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams wrote: > On Apr 4, 2014 8:36 PM, "Watson Ladd" wrote: >> 1: How will DANE make this worse? >> 2: Is this really the best we can do? What features of X509 led to >> these problems? > > Let's take #2 first. Here's two entrants: > > - x.509 naming is impossibly difficult to deal with (see RFC4514); > > - stapled OCSP is how it should have been from day one -- CRLs add a ton of > complexity You are ignoring the reason we have CRLs in the first place: stapled OCSP assumes all devices are globally connected and so can get OCSP. Furthermore, neither naming nor OCSP/CRLs were involved in this research, although the complexity may have lead to corners being cut in the rest of the code. > Back to #1: DNSSEC is a PKI, but with better naming and fewer root CAs. > We're going to need CT for DNSSEC. Well, you're assuming that all implementations will agree on DNSSEC validity. Even if they do, DANE connects to the X509 ecosystem. This raises the problem of validating the parts between the TLS connection and the link to DANE. > >> 3: This focused on server authentication. How does client authentication >> fare? > > Very differently. For user authentication I think something more like > Persona (still PK, but not Internet-scale PKI) is better. We really need a > standard account & device enrollment protocol to make user PK work well -- > then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the > market likes best. Enrollment and accounts are secondary to making sure everyone agrees on what a valid certificate looks like. If you don't have that, you can't trust the results of authentication. This research analyzed server certificates only. It didn't have user certificates to play with. Furthermore, if X509 implementors got this wrong, how do we get it right? 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 Sat Apr 5 02:15: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 BC6681A03CD for ; Sat, 5 Apr 2014 02:15:01 -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 459_eDE8oizy for ; Sat, 5 Apr 2014 02:14: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 97D9E1A03C7 for ; Sat, 5 Apr 2014 02:14:57 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 21F6B1C21B3; Sat, 5 Apr 2014 11:14:51 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E7AFB1FE01D7; Sat, 5 Apr 2014 11:14:50 +0200 (CEST) Date: Sat, 5 Apr 2014 11:14:50 +0200 From: Kurt Roeckx To: Yan Zhu Message-ID: <20140405091450.GA30180@roeckx.be> References: <533F6106.5000308@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533F6106.5000308@eff.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I3CYwBQ03rr26jWO-jL6Xy2ktAA Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 09:15:02 -0000 On Fri, Apr 04, 2014 at 06:48:54PM -0700, Yan Zhu wrote: > On 04/04/2014 06:35 PM, Watson Ladd wrote: > > Dear all, > > https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of > > many TLS implementations. Interestingly all tested implementations > > contain errors, and all but OpenSSL erroneous accepts. Cryptlib was > > not tested, because it doesn't validate certificates. > > > > At the core of these issues is the complexity of certificate > > validation. Things for this committee to consider: > > > > 1: How will DANE make this worse? > > 2: Is this really the best we can do? What features of X509 led to > > these problems? > > 3: This focused on server authentication. How does client authentication fare? > > In case anyone wants to investigate these questions, the code used in > that study to generate mutated certificates is at > https://github.com/sumanj/frankencert. (You will need a corpus of > certificates to start from; the mirrors of EFF's SSL Observatory scan > results seem to all be unavailable at the moment, but that should be > fixed soon.) I have a copy of that corpus. But you might also want to look at https://scans.io/ Kurt From nobody Sat Apr 5 08:26:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6DA1A0499 for ; Sat, 5 Apr 2014 08:26:07 -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 fwD5waPJ78at for ; Sat, 5 Apr 2014 08:26:01 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B0AB41A048E for ; Sat, 5 Apr 2014 08:26:01 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id uo5so4785575pbc.32 for ; Sat, 05 Apr 2014 08:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iXpOXMLLWZdSp9c3bh+sS7JnTT5Dl7A4UoO76rVLVek=; b=NBF3xGdMGZ84+NimS7mMaFj5hVsa4GgrHP1u9Sdp29whE6qYoWHEgxLch6cBCW6mDc wxx1GPQgpnPzVaL6+zDbMN8sQJXvnArMyWfztQ7v49BY5phJJYMIdb18aI9Of0S/Ce7V 4/36WMx6VJ5XHRjM9JUmgMCCj0usX9Cs21JTDqIT8Uu4F6XztQp/+D2lzS+o7GiwDgmY fLhgI9tg+cP3Y7oFh7jGk3jDwO4kd/vppJJfS/DLkgbfeEvL/ONFi7tj7nMdZF18aV1B pBJbG3jU+1NPedvzQ2XBJDL0xtwiTiFTfbWv0M0k1ChaZyn9C3Csv2O/2bnbQ2o8aO+V FOUA== MIME-Version: 1.0 X-Received: by 10.66.122.1 with SMTP id lo1mr21416011pab.118.1396711556864; Sat, 05 Apr 2014 08:25:56 -0700 (PDT) Received: by 10.70.131.16 with HTTP; Sat, 5 Apr 2014 08:25:56 -0700 (PDT) In-Reply-To: References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> Date: Sat, 5 Apr 2014 08:25:56 -0700 Message-ID: From: Peter Bowen To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lW14Aasaztg-tK0sdKzO_Fq2z3g Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 15:26:07 -0000 On Sun, Jan 26, 2014 at 3:37 PM, Eric Rescorla wrote: > Based on this discussion the chairs believe we have sufficient support to > ask for an early code point assignment. This message serves as a request > to the chair to do so. It looks like this was assigned value 21 last month. (http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml) Other than updating the draft replace "TBD" with "21" are there other open issues? From nobody Sat Apr 5 14:01: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 C2C4F1A02D1 for ; Sat, 5 Apr 2014 14:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxzDAfsiDF73 for ; Sat, 5 Apr 2014 14:01:08 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF3101A02D8 for ; Sat, 5 Apr 2014 14:01:08 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id DCDBF2F4060; Sat, 5 Apr 2014 14:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uO+wfWof7gvgEX oR0p1CFnH1Pho=; b=DWW+RgWx2QoBnoa3JVbzw8/yVNf0duAOvmnwX4n4Wpjd+1 +Xq03GB/ZNXdBVbTIqgKtZLc6/uzojUmhNy4KLPrqEZvJA+FBsD8xETI6e4GqSfV WI+hav7Xs1EpS/Szf8Vg4tCtFQyjHdcUBuo/aRH6or9AGlm07LkcZrH7+qVO8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 9622F2F401C; Sat, 5 Apr 2014 14:01:03 -0700 (PDT) Date: Sat, 5 Apr 2014 16:01:02 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20140405210100.GD2727@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V4ySh8OZkaS_VNIettou4cE-ZzA Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 21:01:13 -0000 On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote: > On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams wrote: > > Let's take #2 first. Here's two entrants: > > > > - x.509 naming is impossibly difficult to deal with (see RFC4514); > > > > - stapled OCSP is how it should have been from day one -- CRLs add a ton of > > complexity > > You are ignoring the reason we have CRLs in the first place: stapled > OCSP assumes all devices are globally connected and so can get OCSP. This is the off-line infrastructure argument. If you have the same freshness policy for CRLs and [stapled] OCSP then you have the same on-line/off-line trade-off but with the on-line infrastructure access burden moved from the RP's shoulders to the presenter's. In terms of mechanics, stapled OCSP Response validation is simpler than CRL checking, and its operational characteristics are *much* better (just ask the DoD). > Furthermore, neither naming nor OCSP/CRLs were involved in this > research, although the complexity may have lead to corners being cut > in the rest of the code. What TLS/PKIX libraries have historically implemented naming constraints correctly, or at all? Naming constraint usage and enforcement are critical for PKI, so that a CA compromise in -say- the Netherlands doesn't affect anyone outside its purview. With DNS the naming constraints were always there, so DNSSEC gets them for free. OTOH, DNS is lousy for representing some types of names -- IP addresses, for example. But for the things we desperately need strong security for, namely server/service names, DNS is perfect. DNS is perfect for host/domain naming because it's what won for host/domain naming, so it's what we all use for host/domain naming. x.400/500-style naming was a horrible, useless mess from day one, and we're still stuck with x.500-style naming for TLS server certs, with kludgy conventions layered on top. The research you linked didn't deal with naming. That doesn't mean naming isn't a problem for PKI. You asked, I answered :) > > Back to #1: DNSSEC is a PKI, but with better naming and fewer root CAs. > > We're going to need CT for DNSSEC. > > Well, you're assuming that all implementations will agree on DNSSEC > validity. Even if they do, DANE connects to the X509 ecosystem. This I'm not sure what you mean by "agree on DNSSEC validity". If you mean "agree to place high value on DNSSEC", no, I'm not assuming that. Still, assuming that [we have any significant reliance on DNSSEC (and why wouldn't we for at least some things)] for Internet security, doesn't it stand to reason that, being a PKI, DNSSEC will need to address transparency? Even if we don't replace the TLS server PKI with DANE... generic PKI problems -as opposed to x.509/PKIX-specific ones- will surely apply to DNSSEC. > raises the problem of validating the parts between the TLS connection > and the link to DANE. Hmm? What are the problems here? DANE specifies this "link" in detail. And if DANE "certificate usage 3" cuts out the PKIX world almost completely. > >> 3: This focused on server authentication. How does client authentication > >> fare? > > > > Very differently. For user authentication I think something more like > > Persona (still PK, but not Internet-scale PKI) is better. We really need a > > standard account & device enrollment protocol to make user PK work well -- > > then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the > > market likes best. > > Enrollment and accounts are secondary to making sure everyone agrees > on what a valid certificate looks like. If you don't have that, you Certificate validation is a sine qua non for PKI, no doubt, at least for _servers_/_services_. For users it's different since you might just do TOFU enrollment and only match on public keys (or the public key of a user's private "root CA"). Therefore, and considering the extremely low penetration of PKI for user authentication in TLS, I think certificate validation is not really all that relevant to the user authentication side of things. Depending on how one chooses to use PK (not necessarily I) for user authentication, certificate validation can be a separable [non-]problem. One could publish user name/public key pairings in the DNS[SEC] and enroll user accounts in domains which then act as CAs/IdPs, in which case "certificate validation" becomes relevant again. But in any case, account/device enrollment is a big deal if you want to use PK for user authentication in a scalable and reusable way. > can't trust the results of authentication. This research analyzed Why do you assume that PKI is the only way to use PK? > server certificates only. It didn't have user certificates to play > with. Furthermore, if X509 implementors got this wrong, how do we get > it right? By simplifying. I'm not saying DNS is simple, but the ugly parts of it are not really relevant to the cryptographic security side of things, while the ugly parts of PKIX are (see above). In particular DNS naming is trivial, and so are name constraint expression and checking. Nico -- From nobody Sat Apr 5 14:37:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D681A02DB for ; Sat, 5 Apr 2014 14:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUZeS_W41s3W for ; Sat, 5 Apr 2014 14:37:21 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 939651A02DC for ; Sat, 5 Apr 2014 14:37:21 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 1F3AB1DE060; Sat, 5 Apr 2014 14:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=f+T1SOZPqDD4p8 vKEkTOJPUE4DQ=; b=lUkGlUNL/JRuQG5VfAqLNKYxYRpFHHjYCGl0UT41LYX5Kk f6zoY0z3ewS6O0HhBNsZUrjDuTSLFHZte+W0XPoF14S1ijRhcv1mIuYgsxZhkrOE DlbNEASrzAq+RdZ+zK6jFzlROJi2xU4xdsAMz45H5tUdLoV+XzSMHM97kdXMo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id DE4661DE059; Sat, 5 Apr 2014 14:37:15 -0700 (PDT) Date: Sat, 5 Apr 2014 16:37:14 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20140405213712.GA7962@localhost> References: <20140405210100.GD2727@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140405210100.GD2727@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gCJvS5KCNhRl4IMRSuquP0CnL3U Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 05 Apr 2014 21:37:25 -0000 On Sat, Apr 05, 2014 at 04:01:02PM -0500, Nico Williams wrote: > On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote: > > Furthermore, neither naming nor OCSP/CRLs were involved in this > > research, although the complexity may have lead to corners being cut > > in the rest of the code. > [...] > The research you linked didn't deal with naming. That doesn't mean > naming isn't a problem for PKI. You asked, I answered :) Er, no, it did deal with naming. Search for "name constraint"; it's mentioned quite a few times. Several TLS libraries don't implement PKIX name constraints at all. Embarrassing. I'd say that a PKI with no name constraints is just not hierarchical, it can only be logically flat (ignoring local policy), which then results in a lot of the problems that we've seen with the TLS server PKI. It'd be extremely difficult to not apply DNSSEC's equivalent of name constraints! Nico -- From nobody Sun Apr 6 01:15:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26C11A0346 for ; Sun, 6 Apr 2014 01:15: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, 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 eoZH9w17MnEE for ; Sun, 6 Apr 2014 01:15:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F41A0331 for ; Sun, 6 Apr 2014 01:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396772112; x=1428308112; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=QPv2VPRh2y32YQ9yYYTqiLVbbYP6OcsPmuGfjUVa5Es=; b=GNio8GlQWGAh0yfSo4ND7EQYUaYZiGlkkOySTXiym4mmhX02W0ExsMoG yEduwgdPb1VytiM3lEdFJEFalAynVQqmPUmpwMy3XbHZjyC6MBNDa85A8 aB8xEj1atas6c/r1dbdeG3f10TrVlrxVMl7b7ar0FGt+E7+n/O677Ouhj o=; X-IronPort-AV: E=Sophos;i="4.97,802,1389697200"; d="scan'208";a="245551029" 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; 06 Apr 2014 20:15:09 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.111]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Sun, 6 Apr 2014 20:15:08 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Next steps for draft-agl-tls-padding Thread-Index: Ac9RcFJgaW8Cv0IPS7ummDfhhvbVZg== Date: Sun, 6 Apr 2014 08:15:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@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/RhDNCitHTidE723anT32YafbrIk Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2014 08:15:22 -0000 Peter Bowen writes:=0A= =0A= >Other than updating the draft replace "TBD" with "21" are there other open= =0A= >issues?=0A= =0A= Not that I know of, the only other change has been to include some comments= =0A= (suggested by ekr) about active attacks in the Security Considerations=0A= section.=0A= =0A= Peter.= From nobody Sun Apr 6 10:51: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 C41ED1A03EA for ; Sun, 6 Apr 2014 10:51:14 -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 j5DRO5umvGKM for ; Sun, 6 Apr 2014 10:51:10 -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 9DD8D1A04B1 for ; Sun, 6 Apr 2014 10:51:10 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so4677338ykb.8 for ; Sun, 06 Apr 2014 10:51: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=2QMEZPVvLk8cYt3SIBEe40aFDxzzRG7r+Yscs0UfuWg=; b=hio8I2NFCmVwanhdN2gqg82SJbASKRJxtZbKy4uZWhM8m7EhiyTBIYRhhUz5sIcUUc Q42/WjAxZ+zL+xA+Jj1nULcyeSY8LgCghNmi28l4nBmmHRSSZsOrOwdaRANzJ8iCFQX0 SDYkNFzT+GOS3qEGH/PsF46uNMZ+9CpVgnmsvcny8h1j3zDc9fmhJd3sxz4yhabfVGbn m34RLJwGFWszGGxK21jbdcew380pmp8rESA89mH6yw5EZJyL2On1e8hNTmZSUubQAlgB dsHP8r94y01MulrUwRH5QRENBbgdNGO/hCnf28o92c6nxm3bwXifHoK1ZH7g8Efj8/nn d6nw== MIME-Version: 1.0 X-Received: by 10.236.97.102 with SMTP id s66mr37656672yhf.45.1396806665275; Sun, 06 Apr 2014 10:51:05 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 6 Apr 2014 10:51:05 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Sun, 6 Apr 2014 10:51:05 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jnMPdMgNBKw2phqm9_ynspxu4tE Cc: "" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2014 17:51:15 -0000 On Sun, Apr 6, 2014 at 1:15 AM, Peter Gutmann wrote: > Peter Bowen writes: > >>Other than updating the draft replace "TBD" with "21" are there other open >>issues? > > Not that I know of, the only other change has been to include some comments > (suggested by ekr) about active attacks in the Security Considerations > section. You mean the text on covert channels? I always thought the way to avoid covert channels was to use implementations that didn't have them. In particularly, ECDSA has a covert channel which cannot be closed, and so does OAEP signature. It's not wrong, just incredibly weird that this would be considered worth adding to the draft. Sincerely, Watson Ladd > > Peter. > _______________________________________________ > 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 Apr 6 14:18: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 7F5F71A024D for ; Sun, 6 Apr 2014 14:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 8rdinH2WnxPj for ; Sun, 6 Apr 2014 14:17:59 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id 846B41A02D7 for ; Sun, 6 Apr 2014 14:17:58 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 6042E1A2625; Mon, 7 Apr 2014 00:17:51 +0300 (EEST) Date: Mon, 7 Apr 2014 00:17:51 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140406211750.GA8953@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WAuMJd9TMwGdvfDrTFk7P4hvMw4 Cc: "" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2014 21:18:05 -0000 On Sun, Apr 06, 2014 at 10:51:05AM -0700, Watson Ladd wrote: > > You mean the text on covert channels? I always thought the way to > avoid covert channels was to use implementations that didn't have > them. In particularly, ECDSA has a covert channel which cannot be > closed, and so does OAEP signature. You mean can't be verifiably closed? Or something else? AFAIK, there is no ECC-based signature primitive that is publically deterministic (Ed25519 is no exception to this rule). Of course, ECDSA is rather bad ECC signature scheme as signature schemes go... -Ilari From nobody Sun Apr 6 14:27: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 57FC81A0182 for ; Sun, 6 Apr 2014 14:27: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 CK_Um6-8RglQ for ; Sun, 6 Apr 2014 14:27:44 -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 3D0B41A02E4 for ; Sun, 6 Apr 2014 14:27:44 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so5127489yha.10 for ; Sun, 06 Apr 2014 14:27: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=gd1FWk+nwO07/2lNOQNGMLM0cPgqEt+wOXvvMNQAdFg=; b=IxRckMAl8tahy6kZW0XtfBFU0fGmeDkCtX6+rYJ9JBI44w7JJyTOC4SGYPkvSZvsly 9M/Uf2PRS2/s0n2GCnHxzcyvQRTie7be+PSgTVFn/6i86hdwX298pOAuo6IVdW3uzonN xKjKHdpYlozRQvHDLw0ltV9Jr2mU7xiYr2ztUpZPpzJrlUht5WtVKH9jq5eya5WaBvCV HvDyfU5dwbYnB2ZDCSDOGBTSGLo+fNE9gV5PGXYmSwaXGWdmFQhhmi0UG1Fq3vWxqDsO 6hbljvtCxDNeWEodDvPGO/iTprkFKhcBb2Bddbfztig9EInB9vUo/8NuO0Gmvd+y34q8 Ecbg== MIME-Version: 1.0 X-Received: by 10.236.120.147 with SMTP id p19mr39116411yhh.6.1396819658695; Sun, 06 Apr 2014 14:27:38 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 6 Apr 2014 14:27:38 -0700 (PDT) In-Reply-To: <20140406211750.GA8953@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> <20140406211750.GA8953@LK-Perkele-VII> Date: Sun, 6 Apr 2014 14:27:38 -0700 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nxwayzOgC_yuw5M8SG_LmsDKA74 Cc: "" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2014 21:27:49 -0000 On Sun, Apr 6, 2014 at 2:17 PM, Ilari Liusvaara wrote: > On Sun, Apr 06, 2014 at 10:51:05AM -0700, Watson Ladd wrote: >> >> You mean the text on covert channels? I always thought the way to >> avoid covert channels was to use implementations that didn't have >> them. In particularly, ECDSA has a covert channel which cannot be >> closed, and so does OAEP signature. > > You mean can't be verifiably closed? Or something else? All covert channels can be closed by auditing the software. But if I introduce a leak in the nonce bits of ECDSA that is subtle, or encode data I want to exfiltrate in the random padding of OAEP, even with the private key, I cannot detect this. > > AFAIK, there is no ECC-based signature primitive that is > publically deterministic (Ed25519 is no exception to this > rule). > > Of course, ECDSA is rather bad ECC signature scheme as signature > schemes go... > > > -Ilari Sincerely, Watson ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Apr 6 14:31: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 B3E441A02DE for ; Sun, 6 Apr 2014 14:31:25 -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 Zspv3w_WKb06 for ; Sun, 6 Apr 2014 14:31:21 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 098A91A024D for ; Sun, 6 Apr 2014 14:31:21 -0700 (PDT) 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 9F7843FE9; Mon, 7 Apr 2014 00:31:14 +0300 (EEST) Date: Mon, 7 Apr 2014 00:31:14 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140406213114.GA9363@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> <20140406211750.GA8953@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x31YrS5sFcWMVoL67KegYMd2YhQ Cc: "" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Apr 2014 21:31:25 -0000 On Sun, Apr 06, 2014 at 02:27:38PM -0700, Watson Ladd wrote: > On Sun, Apr 6, 2014 at 2:17 PM, Ilari Liusvaara > wrote: > > > > You mean can't be verifiably closed? Or something else? > > All covert channels can be closed by auditing the software. But if I > introduce a leak in the nonce bits of ECDSA that is subtle, or encode > data I want to exfiltrate in the random padding of OAEP, even with the > private key, I cannot detect this. Ah, the model is post-hoc auditing with access to private key. Got it. And yeah, there are EC signature primitives that are deterministic and auditable in that model (such as Ed25519)... -Ilari From nobody Sun Apr 6 17:22: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 3EDB81A0584 for ; Sun, 6 Apr 2014 17:22:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE1V3pfbZoYi for ; Sun, 6 Apr 2014 17:22:03 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7261A00EC for ; Sun, 6 Apr 2014 17:22:02 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta08.emeryville.ca.mail.comcast.net with comcast id mo5D1n00316AWCUA8oMxvw; Mon, 07 Apr 2014 00:21:57 +0000 Received: from [192.168.1.8] ([71.202.164.227]) by omta06.emeryville.ca.mail.comcast.net with comcast id moMw1n00N4uhcbK8SoMwLY; Mon, 07 Apr 2014 00:21:57 +0000 Message-ID: <5341EFA4.7070808@brainhub.org> Date: Sun, 06 Apr 2014 17:21:56 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396830117; bh=btqmaKPrX4G4v9z1DDdSr8DewiRTX5SJTNUx7Z32/ts=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nl9H7ruHjnYWqWy8tyLe6c4x2qsNlpsp5BDaOXhfPaB335ktH47YIKaQqa/3gQOZY mvuuRY1UgaBd1E2JPQ/AEnFP1LBHo/vN+PGx9F1bOVcBUmBsr8Se2FfhXDtkhFAhPd Mw7KxaeVG6PHR9oJ37I8RYJg7KCEq6Es3nINSbVNatbSPOeLDc/ia1O0KE034CaWcn ZqhZxbisYrChASMyh1P0lE9Zp7inltti/MinrNxSHKE0stR09Y5U1YjOldG5NNxNEQ CDrSAv6EccMqs0kvJ9vxZSNtZoRJA38/wx63WeviCsz6SQN2McJGZUMD6hzHGfYrPD zxdZlMemewxcg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kC1iFf2lnvWmPFESqPYLyqOnNI4 Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 00:22:08 -0000 > > 1. Introduction > > > Successive TLS [RFC5246] versions have added support for more cipher > suites and, over time, more TLS extensions have been defined. This > has caused the size of the TLS ClientHello to grow and the additional > size has caused some implementation bugs to come to light. At least > one of these implementation bugs can be ameliorated by making the > ClientHello even larger. ( Sorry if it was already discussed ) I suggest to explain why the last sentience in the above paragraph holds true. The paragraph leads the reader to the idea that "larger ClientHello --> bugs", but then there is a shift that "even larger ClientHello --> fewer bugs". The spec would benefit from a suggestion about what the recommended use of the padding extension is (i.e. to which size one should pad). Thank you. From nobody Mon Apr 7 02:51: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 DC1101A06E1 for ; Mon, 7 Apr 2014 02:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 gVS7yMQ3Siv3 for ; Mon, 7 Apr 2014 02:51:14 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id B0FCB1A06E2 for ; Mon, 7 Apr 2014 02:51:13 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s379p3F7029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Apr 2014 11:51:05 +0200 Date: Mon, 7 Apr 2014 11:51:02 +0200 From: Simon Josefsson To: Kurt Roeckx Message-ID: <20140407115102.3011d2e5@latte.josefsson.org> In-Reply-To: <20140402164340.GA14790@roeckx.be> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.1 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yHgY2Cm7DU5v1NA5gNv4k8VrwLM Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 09:51:19 -0000 You wrote: > On Wed, Jan 22, 2014 at 05:18:54PM +0100, Simon Josefsson wrote: > > > > 1) Curve25519 for TLS. This was the original scope of the draft. > > The URL is: > > . As > > far as I know, there are no outstanding issues, and it is possible > > to implement and deploy Curve25519 in TLS following the draft. > > Please prove me wrong with comments or preferrably patches to the > > draft. > > So what's the status of this? The above is still the current status as far as I am aware. To move the draft forward in the RFC process, we need find an AD to sponsor the draft or (I guess) the TLS WG to adopt it. It would be useful if TLS implementers let the list know what their status is (waiting/planning/implemeted/rejected). If interop testing is pending on having an assigned number, I suggest using 65024 as the Curve25519 EC Named Curve number for testing purposes. /Simon From nobody Mon Apr 7 07:29: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 D7E0A1A072C for ; Mon, 7 Apr 2014 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OC3b4UJMwJi8 for ; Mon, 7 Apr 2014 07:29:38 -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 BF4611A0452 for ; Mon, 7 Apr 2014 07:29:38 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E3B34285BB for ; Mon, 7 Apr 2014 14:29:32 +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 CF33A28537 for ; Mon, 7 Apr 2014 14:29:32 +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 CB889202C for ; Mon, 7 Apr 2014 14:29:32 +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; Mon, 7 Apr 2014 10:29:32 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Mon, 7 Apr 2014 10:29:31 -0400 Thread-Topic: About encrypting SNI Thread-Index: Ac9SbYXhdiDYEiy3R5ypSW7DwlHnYA== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/riBjY2zyUrbnlOYBFeafmy8fHiU Subject: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:29:44 -0000 I have concerns some about SNI encryption. First, I think it addresses a problem that is actually not that important f= or most. There are comparatively few sites on the web that have multiple pr= operties served from a single host (or cluster). Certainly the biggest site= s that received the most publicity for being under attack by the NSA -- Mic= rosoft, Google, Yahoo, etc. -- are really a few to smallish number of servi= ces. And those companies have the wherewithal to deploy separate identities= and IP addresses for their properties. Second, it potentially disadvantages a portion of the net: large CDN's and = their customers. My employer, for example, serves thousands of sites on its= TLS network, and encrypting SNI requires us to either have a single long-l= ived keypair for all customers, or require an extra RTT for clients to fetc= h an EDH key, perhaps still shared, but hopefully more secure. The latter i= s particularly off-putting since customers paying for a "faster, better" en= d-user experience are now at a disadvantage. Some in this community might n= ot deploy TLS 1.3 to avoid the "retry penalty." This would be a shame. Third, we have not heard from the real potential community of consumers of = this. I posit that they are mid-size sites with a "handful" of hosted prope= rties. They are currently adequately served by virtual IP's, and even more = so in the future by IPv6. And in terms of adversaries, does it matter which= property within peacefire, for example, a user is contacting? A site unde= r surveillance by a national-scale adversary will have *everything* scooped= up anyway. Let me put some numbers on the previous points. We deliver content for arou= nd 10K domains, each with its own RSA keypair, out of 1500 locations. Witho= ut SNI, that means we need 15Million IP addresses, while being able to use = SNI we only need one per location (region in our terminology). With SNI enc= ryption we either need to share keys (bad for security, and perhaps not com= pliant with some regulations) or fragment IPs (bad for the web long-term). = And that's just us. Add in all the CDNs, hosting companies, cloud provider= s... it's big. Do we know what people like AWS, Rackspace, IBM Cloud, etc.= , think about this? Fourth, it potentially "unlevels" the playing field. Organizations that hav= e both a browser and servers of interest could, trivially, arrange to push = out keys on a regular basis. I am not suggesting that anyone is planning on= doing this, but I fear the temptation to do so in the name of "improving t= he user experience" will prove too great. In darker moments, I extrapolate = the " browser list of CA's" story and imagine a future where Chrome talkin= g to Google will be faster than IE talking to Bing, and Firefox will end up= selling slots in its EDH store (sic) to attract revenue. Fifth, it introduces unknown security and trust implications in browsers. I= t took years to make "certificate stores" actually secure. And we are poten= tially opening up a new avenue of active attacks over the network while inc= reasing the expectation that things are more secure. We are also increasing= the client-side attack surface. Sixth, it adds an extra burden to servers. I think it also improves potenti= al DoS attacks, since they could start at the first PDU exchange. Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Hos= t header, the virtual hosting industry was created. Until virtual IP's were= well-known and SNI was widely adopted (I'm being charitable here), adoptio= n of TLS among hosting providers had significant drag. If SNI is routing, t= hen routing is plaintext and we are now going hide it without understanding= the trade-offs.=20 =20 Finally, it is a lot of mechanism. As ekr said in London, "you have to do = all this if you want to protect the SNI." It's not worth it. I think we're going too far, and we should come down on the side of simplic= ity, not for its own sake, but for security's sake. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 7 07:55: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 803A31A0785 for ; Mon, 7 Apr 2014 07:55: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 INI--N-Uemu2 for ; Mon, 7 Apr 2014 07:55:33 -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 644891A0468 for ; Mon, 7 Apr 2014 07:55:33 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so5512673ykb.8 for ; Mon, 07 Apr 2014 07:55: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=puXkyOMdM25NPa6KoAsCqkpcYtJSXgZeKmNgnR5vgb0=; b=g/mYtSr2634rFlQH9MZ0CE+08x542sl3t+fnI1wCKuOhBJHJYeXxbBXstije1E7hul od74G85wvF7o4jmlDjMCRrutf7x+WOOHqAI5BUY7eFI3AG3SvLmTZySWLIWg+2omCOZT pOodEMoyJHchPNA4uthBr/cY/1ofPt00OFB8qxJBMstduqgn88J2UmV3TUbBXW+m7djS v/otnt+uQafPiEji4gOEUz7A4TQ3hY8hY1WKq0T3f8ZwYydJeiiuRN3NiivkF/+Lwt9u 0hUBFE2Sc+UU9BjWrIzVBHJ2SI72oTnlP4Ktklr7pUJ9SgZn4tsrGNHNBtWHGl2jqBsZ 1BgA== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr44209280yhi.4.1396882527561; Mon, 07 Apr 2014 07:55:27 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 7 Apr 2014 07:55:27 -0700 (PDT) In-Reply-To: <20140407115102.3011d2e5@latte.josefsson.org> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> Date: Mon, 7 Apr 2014 07:55:27 -0700 Message-ID: From: Watson Ladd To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KYHfCFa6qzjemWbzSpV5umUX2bk Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:55:38 -0000 On Mon, Apr 7, 2014 at 2:51 AM, Simon Josefsson wrote: > You wrote: > >> On Wed, Jan 22, 2014 at 05:18:54PM +0100, Simon Josefsson wrote: >> > >> > 1) Curve25519 for TLS. This was the original scope of the draft. >> > The URL is: >> > . As >> > far as I know, there are no outstanding issues, and it is possible >> > to implement and deploy Curve25519 in TLS following the draft. >> > Please prove me wrong with comments or preferrably patches to the >> > draft. >> >> So what's the status of this? > > The above is still the current status as far as I am aware. > > To move the draft forward in the RFC process, we need find an AD to > sponsor the draft or (I guess) the TLS WG to adopt it. Does anyone object to the WG adopting it? > > It would be useful if TLS implementers let the list know what their > status is (waiting/planning/implemeted/rejected). > > If interop testing is pending on having an assigned number, I suggest > using 65024 as the Curve25519 EC Named Curve number for testing > purposes. > > /Simon Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Apr 7 08:06: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 514B81A0783 for ; Mon, 7 Apr 2014 08:06:39 -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 WXRlUQOYzunP for ; Mon, 7 Apr 2014 08:06:33 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id CE3351A0799 for ; Mon, 7 Apr 2014 08:06:23 -0700 (PDT) Received: from MUSTANG.miss.ncsc.mil (mustang.missi.ncsc.mil [144.51.60.149]) by stingray.missi.ncsc.mil with ESMTP id s37F6HpU075822 for ; Mon, 7 Apr 2014 11:06:17 -0400 (EDT) Received: from PINTO.missi.ncsc.mil ([fe80::60c7:cec6:b35c:deed]) by Mustang.missi.ncsc.mil ([fe80::dd64:e457:4553:e1ff%14]) with mapi id 14.03.0181.006; Mon, 7 Apr 2014 11:06:17 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: AQHPUG9tCuKVCLxxtECpLbZHb+hchZsCri0AgAAQLICAAQgjAIACeaVA Date: Mon, 7 Apr 2014 15:06:15 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8CB7D8C62@PINTO.missi.ncsc.mil> References: <20140405210100.GD2727@localhost> In-Reply-To: <20140405210100.GD2727@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.60.29] 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/oZPw7yKryk5ew6SxjOv-tts7l1k Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 15:06:39 -0000 You are comparing apples and oranges - OCSP responses covering one or a few= certificates vs. CRLs covering hundreds of thousands. If you select a giv= en number of subscribers per status structure, CRLs are more efficient than= OCSP. Alternately, if you select a given data structure size (4K, 16K, 64= K), the number of subscribers covered by a CRL of that size is larger than = the number covered by the same sized OCSP response, because the CRL uses a = more efficient encoding. The same server-vs-client fetch options apply to CRLs as OCSP. However, on= ly CRLs support delta coding, which saves significant bandwidth for bulk tr= ansfers (as a server validating many clients would need). OCSP validation is not simpler, it simply uses a more verbose representatio= n of the same information. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nico Williams Sent: Saturday, April 05, 2014 5:01 PM To: Watson Ladd Cc: tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms On Fri, Apr 04, 2014 at 10:15:39PM -0700, Watson Ladd wrote: > On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams wro= te: > > Let's take #2 first. Here's two entrants: > > > > - x.509 naming is impossibly difficult to deal with (see RFC4514); > > > > - stapled OCSP is how it should have been from day one -- CRLs add a=20 > > ton of complexity >=20 > You are ignoring the reason we have CRLs in the first place: stapled=20 > OCSP assumes all devices are globally connected and so can get OCSP. This is the off-line infrastructure argument. If you have the same freshness policy for CRLs and [stapled] OCSP then you = have the same on-line/off-line trade-off but with the on-line infrastructur= e access burden moved from the RP's shoulders to the presenter's. In terms of mechanics, stapled OCSP Response validation is simpler than CRL= checking, and its operational characteristics are *much* better (just ask = the DoD). ------------------------- From nobody Mon Apr 7 10:21: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 2BFEE1A04A3 for ; Mon, 7 Apr 2014 10:21: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 h2GdgVWWdOpO for ; Mon, 7 Apr 2014 10:21:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E61A027A for ; Mon, 7 Apr 2014 10:21:13 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm4so5481077wib.8 for ; Mon, 07 Apr 2014 10:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UiiVe7DSZ/bGyEDhsn2uqA4RxGVzcpLscjspG8KBTuM=; b=0I2Wh79U9IF6e1DuIE7O7gMk/FLOkDe4F8CiIsLUtDTHp38LaoeP+V5RJH2v7O9csR HKOmT4QLoWysHewxvKROp1MOWpCmv8F5FudcVJwsil5IG43kkY0NkZjotQuoFqdtMJFb 2/iSj9ZbhSjbYHebpP569B75vgAxU31Lp8LuAIn+urPYxRio5AArbnpO1yyq5Okqi9dg zXUQdGe14rJdtYNrFzUhhI3N+pCaYVGXkwEcOTEchgIT/P5GlW8UvEhr6AdDC3Rqxnoc FdDcq6MNkX2Y7dN+O67s+LNbQcMHrxDG3OJg/bnofxEQ6996/ZXZOwOiOE6Aj7W9pe9o rtsA== MIME-Version: 1.0 X-Received: by 10.194.174.197 with SMTP id bu5mr42558151wjc.71.1396891267413; Mon, 07 Apr 2014 10:21:07 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 10:21:07 -0700 (PDT) In-Reply-To: <5341EFA4.7070808@brainhub.org> References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <5341EFA4.7070808@brainhub.org> Date: Mon, 7 Apr 2014 10:21:07 -0700 Message-ID: From: Martin Thomson To: Andrey Jivsov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZJ00DWX2Nbky3X-v4j1escXYvnY Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 17:21:22 -0000 On 6 April 2014 17:21, Andrey Jivsov wrote: > The spec would benefit from a suggestion about what the recommended use of > the padding extension is (i.e. to which size one should pad). This has been discussed extensively, here and elsewhere. See for instance, http://www.ietf.org/mail-archive/web/tls/current/msg10423.html or https://www.imperialviolet.org/2013/10/07/f5update.html or https://code.google.com/p/chromium/issues/detail?id=315828 . I expect that the draft authors are being sensitive to the fact there is no need to create a more public, permanent record of what is a transient problem. From nobody Mon Apr 7 10:23: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 3642F1A027A for ; Mon, 7 Apr 2014 10:23:08 -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 8ozoQJJWHLLg for ; Mon, 7 Apr 2014 10:23:01 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 49D2E1A0221 for ; Mon, 7 Apr 2014 10:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=kfdNDzBcHClysnwV+OTU/88j6vS7f0W5DOrBrls3fMo=; b=Ap0PT0zHLsnJ2i+aJHlmPnRay6KAj42y/0qS9tYVL7i3MFyXGG5uGZ4JsQqSr6MNvibkpSGIc4iHxP/0RiiM0W9wZt8t68OAvznklzZfLqIL8FvkVPvHrs4HJPdP5KPo9z0h27SNK+So//7QslGiU0Os5/kfbJGPp3eunT71Vk8=; 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 1WXDFe-0003SN-At; Mon, 07 Apr 2014 19:22:31 +0200 Message-ID: <5342DEE7.3010706@polarssl.org> Date: Mon, 07 Apr 2014 19:22:47 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ilari Liusvaara , Watson Ladd References: <9A043F3CF02CD34C8E74AC1594475C738A3471E5@uxcn10-tdc06.UoA.auckland.ac.nz> <20140406211750.GA8953@LK-Perkele-VII> <20140406213114.GA9363@LK-Perkele-VII> In-Reply-To: <20140406213114.GA9363@LK-Perkele-VII> 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/mfEOlJA0LPZFbibPO29CZOLtlDs Cc: "" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 17:23:08 -0000 On 06/04/2014 23:31, Ilari Liusvaara wrote: > On Sun, Apr 06, 2014 at 02:27:38PM -0700, Watson Ladd wrote: >> All covert channels can be closed by auditing the software. But if I >> introduce a leak in the nonce bits of ECDSA that is subtle, or encode >> data I want to exfiltrate in the random padding of OAEP, even with the >> private key, I cannot detect this. > > Ah, the model is post-hoc auditing with access to private key. Got it. > > And yeah, there are EC signature primitives that are deterministic and > auditable in that model (such as Ed25519)... > It seems to me that deterministic usage of ECDSA as documented in RFC 6979 is also auditable in that model. Am I missing something? Manuel. From nobody Mon Apr 7 10:36: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 8AF221A07A1 for ; Mon, 7 Apr 2014 10:36: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 0aaQC915qsw2 for ; Mon, 7 Apr 2014 10:36:30 -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 8C3E81A07BE for ; Mon, 7 Apr 2014 10:36:24 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so5494586wib.16 for ; Mon, 07 Apr 2014 10:36:18 -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=OxgTuARU/J9+7eu+AXs0LvbLZQ31lP3ahtGy823wv0I=; b=xOsQVO23VOqLL/b0WehchVc7+KQ0nxgDvBImC3CE05Fpj3IxT9Jf/CL25MqN2NjbZp 3r5Rn1hK5BxWJKzgSRANEbzUT10VfTz9xFwntH4QwSPs3iKdLp9p+HOntIopB/lPBoXc 9XUwBWbnhwd/zHwYDpzTRpPqz8hR+/1W/eNx7T6aEEOQBc4IBH2tCvUpI2JmJgnoGK0E VZj37SwySSDgxS5u6kAwXVbJ3+JmtTg4UGTFfgFcvJp5MHsAlgyfAsR2crUjYjQ92z00 9EQzBHOPt+gv2IuIowW88aVSqcx2RTtAQuXP7UmMvXporSA2F+ynkzaaDCiBfwLb8iT5 /O5Q== MIME-Version: 1.0 X-Received: by 10.195.12.14 with SMTP id em14mr43801740wjd.15.1396892178483; Mon, 07 Apr 2014 10:36:18 -0700 (PDT) Received: by 10.227.147.10 with HTTP; Mon, 7 Apr 2014 10:36:18 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> Date: Mon, 7 Apr 2014 10:36:18 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fO6KfErZ6Q_D9MRUI6gw1D7VThc Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 17:36:34 -0000 Rich, Did you consider the solution proposed by dkg at the meeting? That is, embed routing information in the server_key_label [1]. That means that you can identify flows as precisely as you need prior to decrypting. No need then for 15m IP addresses, certainly. --Martin [1] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.= 4.3 On 7 April 2014 07:29, Salz, Rich wrote: > I have concerns some about SNI encryption. > > First, I think it addresses a problem that is actually not that important= for most. There are comparatively few sites on the web that have multiple = properties served from a single host (or cluster). Certainly the biggest si= tes that received the most publicity for being under attack by the NSA -- M= icrosoft, Google, Yahoo, etc. -- are really a few to smallish number of ser= vices. And those companies have the wherewithal to deploy separate identiti= es and IP addresses for their properties. > > Second, it potentially disadvantages a portion of the net: large CDN's an= d their customers. My employer, for example, serves thousands of sites on i= ts TLS network, and encrypting SNI requires us to either have a single long= -lived keypair for all customers, or require an extra RTT for clients to fe= tch an EDH key, perhaps still shared, but hopefully more secure. The latter= is particularly off-putting since customers paying for a "faster, better" = end-user experience are now at a disadvantage. Some in this community might= not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame. > > Third, we have not heard from the real potential community of consumers o= f this. I posit that they are mid-size sites with a "handful" of hosted pro= perties. They are currently adequately served by virtual IP's, and even mor= e so in the future by IPv6. And in terms of adversaries, does it matter whi= ch property within peacefire, for example, a user is contacting? A site un= der surveillance by a national-scale adversary will have *everything* scoop= ed up anyway. > > Let me put some numbers on the previous points. We deliver content for ar= ound 10K domains, each with its own RSA keypair, out of 1500 locations. Wit= hout SNI, that means we need 15Million IP addresses, while being able to us= e SNI we only need one per location (region in our terminology). With SNI e= ncryption we either need to share keys (bad for security, and perhaps not c= ompliant with some regulations) or fragment IPs (bad for the web long-term)= . And that's just us. Add in all the CDNs, hosting companies, cloud provid= ers... it's big. Do we know what people like AWS, Rackspace, IBM Cloud, et= c., think about this? > > Fourth, it potentially "unlevels" the playing field. Organizations that h= ave both a browser and servers of interest could, trivially, arrange to pus= h out keys on a regular basis. I am not suggesting that anyone is planning = on doing this, but I fear the temptation to do so in the name of "improving= the user experience" will prove too great. In darker moments, I extrapolat= e the " browser list of CA's" story and imagine a future where Chrome talk= ing to Google will be faster than IE talking to Bing, and Firefox will end = up selling slots in its EDH store (sic) to attract revenue. > > Fifth, it introduces unknown security and trust implications in browsers.= It took years to make "certificate stores" actually secure. And we are pot= entially opening up a new avenue of active attacks over the network while i= ncreasing the expectation that things are more secure. We are also increasi= ng the client-side attack surface. > > Sixth, it adds an extra burden to servers. I think it also improves poten= tial DoS attacks, since they could start at the first PDU exchange. > > Seventh, it ignores some of our own history. When HTTP/1.1 mandated the H= ost header, the virtual hosting industry was created. Until virtual IP's we= re well-known and SNI was widely adopted (I'm being charitable here), adopt= ion of TLS among hosting providers had significant drag. If SNI is routing,= then routing is plaintext and we are now going hide it without understandi= ng the trade-offs. > > Finally, it is a lot of mechanism. As ekr said in London, "you have to d= o all this if you want to protect the SNI." It's not worth it. > > I think we're going too far, and we should come down on the side of simpl= icity, not for its own sake, but for security's sake. > > /r$ > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Apr 7 10:40: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 1C68E1A0836 for ; Mon, 7 Apr 2014 10:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXmCbO2dL0p7 for ; Mon, 7 Apr 2014 10:40:44 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A47B1A07EF for ; Mon, 7 Apr 2014 10:40:16 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so6114235yha.3 for ; Mon, 07 Apr 2014 10:40:10 -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=cYQoJV9aEaH3WqQfwvHxQ45boJhlVNfeePAnfVzMLsM=; b=PAuWjp22b1Qqek7n2inCkPlqaVTYjEa04cPXBdCxRgYT1ksItDvG8aLuhm/PfPqEPi 8D7qNTzHe7HOehPakcM8uMOZaNfQk7IqmnPBgoCNbxI0DwG5IVTwK5gPzTnIscXyr59U ptap7UYuJNFbt7NIm1LRWvQEOZ950aijQotiNB4SG4b0ldZENua6PbYKZ6n8Fepg51h6 wcEfuG0lswIavGW9L/MEJjnm+Sqfwv7hxgNl/s96ObkT3m7Lz+pQsac20fRu48P/ax2U m3DnEGbaGvp4TZ4LN6SYOh6F3ddu01nD5leDyEbBi08XZYvN4vimALRhTCAHMIkUM/AQ 0QJQ== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr24277447yhn.87.1396892410482; Mon, 07 Apr 2014 10:40:10 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 7 Apr 2014 10:40:10 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 7 Apr 2014 10:40:10 -0700 (PDT) In-Reply-To: References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <5341EFA4.7070808@brainhub.org> Date: Mon, 7 Apr 2014 10:40:10 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0160bea6eab39804f6775b84 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EsIs-iLVlRsSshD9ZNhqZVsGXfU Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 17:40:50 -0000 --089e0160bea6eab39804f6775b84 Content-Type: text/plain; charset=UTF-8 On Apr 7, 2014 10:21 AM, "Martin Thomson" wrote: > > On 6 April 2014 17:21, Andrey Jivsov wrote: > > The spec would benefit from a suggestion about what the recommended use of > > the padding extension is (i.e. to which size one should pad). > > > This has been discussed extensively, here and elsewhere. See for > instance, http://www.ietf.org/mail-archive/web/tls/current/msg10423.html > or https://www.imperialviolet.org/2013/10/07/f5update.html or > https://code.google.com/p/chromium/issues/detail?id=315828 . > > I expect that the draft authors are being sensitive to the fact there > is no need to create a more public, permanent record of what is a > transient problem. I read the F5 explaination. It's worth keeping it around so in the future, when tempted to upgrade a binary protocol we ask the guy proposing the upgrade how to distinguish old and new. In particular, tossing it down the memory hole out of misguided professional courtesy would probably mean making the same mistake in the future. In particular treating this extension's proper use as something to be passed on by word of mouth hurts new implementors who don't know the magic number. Embarrassment for F5 is nowhere near as serious. Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e0160bea6eab39804f6775b84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 7, 2014 10:21 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>
> On 6 April 2014 17:21, Andrey Jivsov <crypto@brainhub.org> wrote:
> > The spec would benefit from a suggestion about what the recommend= ed use of
> > the padding extension is (i.e. to which size one should pad).
>
>
> This has been discussed extensively, here and elsewhere. =C2=A0See for=
> instance, http://www.ietf.org/mail-archive/web/tls/current/msg10423.ht= ml
> or https://www.imperialviolet.org/2013/10/07/f5update.html or
> https://code.google.com/p/chromium/issues/detail?id=3D315828 .
>
> I expect that the draft authors are being sensitive to the fact there<= br> > is no need to create a more public, permanent record of what is a
> transient problem.

I read the F5 explaination. It's worth keeping it around= so in the future, when tempted to upgrade a binary protocol we ask the guy= proposing the upgrade how to distinguish old and new.

In particular,=C2=A0 tossing it down the memory hole out of = misguided professional courtesy would probably mean making the same mistake= in the future.

In particular treating this extension's proper use as so= mething to be passed on by word of mouth hurts new implementors who don'= ;t know the magic number. Embarrassment for F5 is nowhere near as serious.<= /p>

Sincerely,
Watson Ladd
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--089e0160bea6eab39804f6775b84-- From nobody Mon Apr 7 11:59: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 394671A0162 for ; Mon, 7 Apr 2014 11:59:53 -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 03uZ6DVRz5mE for ; Mon, 7 Apr 2014 11:59:48 -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 091BD1A04A7 for ; Mon, 7 Apr 2014 11:59:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ED8E628584; Mon, 7 Apr 2014 18:59:35 +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 DBD122857B; Mon, 7 Apr 2014 18:59:35 +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 D21D2FE073; Mon, 7 Apr 2014 18:59:35 +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; Mon, 7 Apr 2014 14:59:35 -0400 From: "Salz, Rich" To: Martin Thomson Date: Mon, 7 Apr 2014 14:59:34 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9Sh+RPSw/lS2vaSWq8hD8LwKOqIQAC27ng Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC1864D@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@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/-6Y22CviOTxhs93DOZYwKIdJwis Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 18:59:53 -0000 PiBEaWQgeW91IGNvbnNpZGVyIHRoZSBzb2x1dGlvbiBwcm9wb3NlZCBieSBka2cgYXQgdGhlIG1l ZXRpbmc/ICBUaGF0IGlzLCBlbWJlZCByb3V0aW5nIGluZm9ybWF0aW9uIGluIHRoZSBzZXJ2ZXJf a2V5X2xhYmVsIFsxXS4NCg0KWWVzIHdlIGxvb2tlZCBhdCBpdC4gV2hhdCB3ZSBuZWVkIGFuZCB3 YW50IGlzIHRoZSBTTkkuICBOb3QgYSBjdXN0b20gcmUtY3JlYXRpb24gb2YgaXQuDQoNCgkvciQN Cg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0K Q2FtYnJpZGdlLCBNQQ0KDQo= From nobody Mon Apr 7 13:23: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 6E41C1A07FC for ; Mon, 7 Apr 2014 13:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMh_lveFYi72 for ; Mon, 7 Apr 2014 13:23:26 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4F1A07AE for ; Mon, 7 Apr 2014 13:23:26 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s37KNI8J012256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 22:23:18 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Mon, 7 Apr 2014 22:23:18 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140407202318.97EA41ACAA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VEb10Kf09HlGZvmTSyKSAPGgcVk Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 07 Apr 2014 20:23:32 -0000 Watson Ladd wrote: > > https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of > many TLS implementations. Interestingly all tested implementations > contain errors, and all but OpenSSL erroneous accepts. Cryptlib was > not tested, because it doesn't validate certificates. That paper seems to contain a few flawed assumptions on what characteristics is to be expected from implementations of X.509 or PKIX, and on which specific checks a TLS client is supposed to do. As much as some may dislike this, the extendedKeyUsage in an end entity certificate is completely irrelevant for TLS (rfc2246/rfc4346/rfc5246) as well as HTTP-over-TLS (rfc2818). I don't know whether there currently exists _any_ X-over-TLS protocol specification that addresses EKU. There seem to be very few protocols that specify requirements for the EKU value in the end entity cert (such as OCSP: rfc2560 & bis) and timestamps (rfc3161). Similar for certificate policies and policy constraints. They're completely irrelevant for any X-over-TLS, and it would be unwise to assume that they are not simply ignored. Implementing name constraints (other than Distinguished Name) is a mere option. The usage of a subjectAltName name constraint alone (i.e. without a Distinguished name name constraints to go with it) as depicted in Fig. 1 can be a security problem for CRL checking because any CRL signer whose certificate can be verified under the same trust anchor is specified to be an acceptable CRL signer. -Martin From nobody Mon Apr 7 13:31: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 010CA1A04B1 for ; Mon, 7 Apr 2014 13:31:56 -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 wobAnNDjiw5K for ; Mon, 7 Apr 2014 13:31:51 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36AEE1A081F for ; Mon, 7 Apr 2014 13:31:41 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s37KVVIe013475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 22:31:31 +0200 (MEST) In-Reply-To: <20140405213712.GA7962@localhost> To: Nico Williams Date: Mon, 7 Apr 2014 22:31:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140407203131.202061ACAA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PRZeFzMbSsy1lkEmV2xVjKx4-wc Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 07 Apr 2014 20:31:56 -0000 Nico Williams wrote: >> >> The research you linked didn't deal with naming. That doesn't mean >> naming isn't a problem for PKI. You asked, I answered :) > > Er, no, it did deal with naming. Search for "name constraint"; it's > mentioned quite a few times. Several TLS libraries don't implement PKIX > name constraints at all. Embarrassing. This is not embarrassing at all. Name constraints are *OPTIONAL* to implement. What is embarrassing is an implementation of PKI & CA software that will happily created cert chains with bogus name constraints in them. A while ago I had been given a certificate chain with a huge amounts of name constraints in them. Some of the name constraints were bogus (syntactically invalid), and there was a set of name constraints included for which no public specification of the subjectAltName (otherName), let alone the definition of name constraints format and processing for that proprietary nametype. -Martin From nobody Mon Apr 7 13:58: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 F14761A0237 for ; Mon, 7 Apr 2014 13:58:10 -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 Wex3pKiEOSBj for ; Mon, 7 Apr 2014 13:58:06 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9991A07BF for ; Mon, 7 Apr 2014 13:57:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,813,1389762000"; d="scan'208";a="2552000" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 07 Apr 2014 16:57:52 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Mon, 7 Apr 2014 16:57:51 -0400 From: Santosh Chokhani To: "mrex@sap.com" , Watson Ladd Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: AQHPUG9nRS10t5Ha0EyLKsoi0FgTh5sG4JsA///FM+A= Date: Mon, 7 Apr 2014 20:57:51 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811391789E8@scygexch10.cygnacom.com> References: <20140407202318.97EA41ACAA@ld9781.wdf.sap.corp> In-Reply-To: <20140407202318.97EA41ACAA@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.117] 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/M3aEo8HYihYK6YYK1iristAO-Xw Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 20:58:11 -0000 While I am still reading the cited paper , the EKU if present should be ver= y relevant. The client should reject the server certificate if server auth= entication or anhyExtendedKeyUsage is not present. Similarly, certificate = policies and policy constrains extensions should be processed by the client= and if the require explicit policy state variable get turned on and the pa= th is not valid for some policy, it must be rejected. Finally, name constr= aint is very relevant. The certificate must be rejected if any of the name= forms in a certificate in the path violate name constraint state variable = values at that point in the path. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex Sent: Monday, April 07, 2014 4:23 PM To: Watson Ladd Cc: tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms Watson Ladd wrote: > > https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of=20 > many TLS implementations. Interestingly all tested implementations=20 > contain errors, and all but OpenSSL erroneous accepts. Cryptlib was=20 > not tested, because it doesn't validate certificates. That paper seems to contain a few flawed assumptions on what characteristic= s is to be expected from implementations of X.509 or PKIX, and on which specific checks a TLS client is supposed to do. As much as some may dislike this, the extendedKeyUsage in an end entity cer= tificate is completely irrelevant for TLS (rfc2246/rfc4346/rfc5246) as well as HTTP-over-TLS (rfc2818). I don't know whether there currently exists _any_ X-over-TLS protocol specification that addresses EKU. There seem to be very few protocols that specify requirements for the EKU v= alue in the end entity cert (such as OCSP: rfc2560 & bis) and timestamps (r= fc3161). Similar for certificate policies and policy constraints. They're completel= y irrelevant for any X-over-TLS, and it would be unwise to assume that they= are not simply ignored. Implementing name constraints (other than Distinguished Name) is a mere opt= ion. The usage of a subjectAltName name constraint alone (i.e. without a D= istinguished name name constraints to go with it) as depicted in Fig. 1 can= be a security problem for CRL checking because any CRL signer whose certif= icate can be verified under the same trust anchor is specified to be an acc= eptable CRL signer. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Apr 7 14:31: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 9229A1A047A for ; Mon, 7 Apr 2014 14:31: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 3uwg-TtngwEX for ; Mon, 7 Apr 2014 14:31:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1B1A02D7 for ; Mon, 7 Apr 2014 14:31:01 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s37LUpAo023613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Apr 2014 23:30:51 +0200 (MEST) In-Reply-To: <4262AC0DB9856847A2D00EF817E811391789E8@scygexch10.cygnacom.com> To: Santosh Chokhani Date: Mon, 7 Apr 2014 23:30:51 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4aHCuJoVH5AL9m1GfJdNthrJ2VE Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 07 Apr 2014 21:31:07 -0000 Santosh Chokhani wrote: > > While I am still reading the cited paper , the EKU if present should be > very relevant. The client should reject the server certificate if server > authentication or anhyExtendedKeyUsage is not present. There is *NO* such requirement (to look at EKU) anywhere in rfc5246 and rfc2818. The EKU processing within the PKIX certificate path validation applies only to path certificates, not to the leaf certificate (because the certificate path validation is context-free, i.e. independent of the actual usage of the certificate. KeyUsage is different, processing KeyUsage is explicitly described in rfc2246/rfc4346/rfc5246. Did you notice that the id-kp-serverAuth that is defined in rfc5280 is strictly limited to HTTP-over-TLS anyway, so would not apply to XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou. > > Similarly, certificate policies and policy constrains extensions should > be processed by the client and if the require explicit policy state > variable get turned on and the path is not valid for some policy, > it must be rejected. PolicyOIDs are completely meaningless for HTTP-over-TLS. Is there *ANY* X-over-TLS specification that gives a meaning to any policy OIDs? > > Finally, name constraint is very relevant. name constraints will be missing from a PKIX minimum requirements RP. And considering how broken the _definitions_ are, and how broken some of the CA software is that is creating them, simply ignoring name constraints seems like the only sane behaviour. > > The certificate must be rejected if any of the name forms in a > certificate in the path violate name constraint state variable > values at that point in the path. name constraints are a HUGE mess. PKIX does not really describe their processing at all, and neither gives an indication that when *ANY* name constraints are used that name constraints on distinguished names will have to be used as well, otherwise creating security problems for the permissible CRL signer logic. When looking at how X.509 describes processing of name constraints in the example section, you may realize that it talks about iteratively trying to build certification pathes and checking whether name constraints work from them. Ooops. building a certification path is declared out of scope by rfc5280, so logically, this spills the baby with the bathtub and makes name constraints in PKIX/rfc5280 optional in its entirety, because something that needs a feature that has been explicitly declared out of scope can never be a mandatory part of the spec. -Martin From nobody Mon Apr 7 15:03: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 04FC61A02D1 for ; Mon, 7 Apr 2014 15:03:28 -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 o3FvnffRp5_R for ; Mon, 7 Apr 2014 15:03:23 -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 38A8F1A0298 for ; Mon, 7 Apr 2014 15:03:22 -0700 (PDT) Received: (qmail 23297 invoked by uid 1000); 7 Apr 2014 22:03:15 -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, 07 Apr 2014 23:03:15 +0100 Message-ID: <534320A2.5030208@comodo.com> Date: Mon, 07 Apr 2014 23:03:14 +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: mrex@sap.com, Santosh Chokhani References: <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> In-Reply-To: <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GfbklwTcA7Tf0NSXJFMiFqT24FQ Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Apr 2014 22:03:28 -0000 On 07/04/14 22:30, Martin Rex wrote: > There is *NO* such requirement (to look at EKU) anywhere in rfc5246 > and rfc2818. The EKU processing within the PKIX certificate path validation > applies only to path certificates, not to the leaf certificate (because the > certificate path validation is context-free, i.e. independent of the > actual usage of the certificate. Martin, how about RFC6125? "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) ... 1.4. Applicability This document does not supersede the rules for certificate issuance or validation provided in [PKIX]. Therefore, [PKIX] is authoritative on any point that might also be discussed in this document. Furthermore, [PKIX] also governs any certificate-related topic on which this document is silent, including but not limited to certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths." > Did you notice that the id-kp-serverAuth that is defined in rfc5280 > is strictly limited to HTTP-over-TLS anyway, so would not apply to > XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou. You mean the "-- TLS WWW server authentication" comment in section 4.2.1.12? Or something else? Would you be happier if "WWW " wasn't in that comment? >> Similarly, certificate policies and policy constrains extensions should >> be processed by the client and if the require explicit policy state >> variable get turned on and the path is not valid for some policy, >> it must be rejected. > > PolicyOIDs are completely meaningless for HTTP-over-TLS. > Is there *ANY* X-over-TLS specification that gives a meaning > to any policy OIDs? Yes. The CA/Browser Forum EV SSL Guidelines and Baseline Requirements. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Apr 7 15: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 8AA551A028B for ; Mon, 7 Apr 2014 15:43:54 -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 GWLz3kFp0zAb for ; Mon, 7 Apr 2014 15:43:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9741A080D for ; Mon, 7 Apr 2014 15:43:42 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s37MhT94005000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 00:43:29 +0200 (MEST) In-Reply-To: <534320A2.5030208@comodo.com> To: Rob Stradling Date: Tue, 8 Apr 2014 00:43:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9UksDPK8ix-ufVxkwzkXdxAsjeA Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 07 Apr 2014 22:43:54 -0000 Rob Stradling wrote: > Martin Rex wrote: >> >> There is *NO* such requirement (to look at EKU) anywhere in rfc5246 >> and rfc2818. The EKU processing within the PKIX certificate path validation >> applies only to path certificates, not to the leaf certificate (because the >> certificate path validation is context-free, i.e. independent of the >> actual usage of the certificate. > > Martin, how about RFC6125? > > "Representation and Verification of Domain-Based Application Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS) > ... > 1.4. Applicability > > This document does not supersede the rules for certificate issuance > or validation provided in [PKIX]. Therefore, [PKIX] is authoritative > on any point that might also be discussed in this document. > Furthermore, [PKIX] also governs any certificate-related topic on > which this document is silent, including but not limited to > certificate syntax, certificate extensions such as name constraints > and extended key usage, and handling of certification paths." I do not see any specific requirements listed in the quoted paragraph (not even a MAY). PKIX deals with the black box called "certificate path validation" (within which EKU-processing is defined), and with requirements for "conforming CAs" which issue X.509v3 certs (of which there seem to exist very few, if any, considering how much junk X.509v3 certificates are floating around. Could it be that GoDaddy is issuing Server certs that aren't valid ASN.1 DER ? Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DEFAULT FALSE" correctly: BasicConstraints ::= SEQUENCE { cA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL } > > > > Did you notice that the id-kp-serverAuth that is defined in rfc5280 > > is strictly limited to HTTP-over-TLS anyway, so would not apply to > > XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou. > > You mean the "-- TLS WWW server authentication" comment in section > 4.2.1.12? Or something else? > > Would you be happier if "WWW " wasn't in that comment? This isn't about happiness. If this OID has any meaning at all, then this limitation "TLS WWW server authentication" will be an integral part of it. An implementation of TLS will be looking here: http://tools.ietf.org/html/rfc2246#page-38 when checking KeyUsage of the Server Certificate, and *NOT* in PKIX. And a TLS client that implements rfc2818 (HTTP-over-TLS) will look exactly at rfc2818 for any checks that the client will do on the Server certificate, and again *NOT* in PKIX. > > >> Similarly, certificate policies and policy constrains extensions should > >> be processed by the client and if the require explicit policy state > >> variable get turned on and the path is not valid for some policy, > >> it must be rejected. > > > > PolicyOIDs are completely meaningless for HTTP-over-TLS. > > Is there *ANY* X-over-TLS specification that gives a meaning > > to any policy OIDs? > > Yes. The CA/Browser Forum EV SSL Guidelines and Baseline Requirements. Ah--yes, the fancy Gui/chrome thingy for EV/OV/DV certs. programmatic clients don't look at CAB Forum baseline requirements (except maybe when looking for excuses to give to unhappy customers). -Martin From nobody Mon Apr 7 18: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 949181A000A for ; Mon, 7 Apr 2014 18:21:10 -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 0qGS_SJkmpFL for ; Mon, 7 Apr 2014 18:21:05 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 031351A0005 for ; Mon, 7 Apr 2014 18:21:04 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so228106ykq.7 for ; Mon, 07 Apr 2014 18:20:59 -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=WgIyuBAwP+R/wMVMFOBUvw0hptUDC37PQC8tgagFH/8=; b=daigjj68WPgP/+dnrXaLU4sAsw6nw5Csglz/rv3njTV6gLk1hka4YfvTpXUth/lFnv 0XoZal9OswKvf7/WDR0nEmJbvPkuOaFcLeEhMmsifYPC/qwo4I3ydCagAQj5VDBDcFZ1 RJTS35Zehc5+svb1Vxrp7amJfq9GGwSfJHOw9XRyqJ6bb2jXHnPRDxOqg3KflGlr4sdR 8zcDZz9jmoy9JW9kYzOk3nC2bzk+2rI2CCeq9CpXdXvmbBKbqMtsbUvW2R0Nk8bqY+uj msz0tD+qJztazloCiyYFmr5RpiwBbdFunNJiHgw3adVX4JrS/uAi0qo4dBBvXPcAQ/vs fiZw== MIME-Version: 1.0 X-Received: by 10.236.94.103 with SMTP id m67mr1087040yhf.104.1396920059186; Mon, 07 Apr 2014 18:20:59 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 7 Apr 2014 18:20:59 -0700 (PDT) In-Reply-To: <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> Date: Mon, 7 Apr 2014 18:20:59 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf3010e863e86fc804f67dcb0f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hs9RJGTAF3R_99FcSammNa-Wh00 Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 01:21:10 -0000 --20cf3010e863e86fc804f67dcb0f Content-Type: text/plain; charset=UTF-8 On Apr 7, 2014 3:44 PM, "Martin Rex" wrote: > > Rob Stradling wrote: > > Martin Rex wrote: > >> > >> There is *NO* such requirement (to look at EKU) anywhere in rfc5246 > >> and rfc2818. The EKU processing within the PKIX certificate path validation > >> applies only to path certificates, not to the leaf certificate (because the > >> certificate path validation is context-free, i.e. independent of the > >> actual usage of the certificate. > > > > Martin, how about RFC6125? > > > > "Representation and Verification of Domain-Based Application Service > > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > > Certificates in the Context of Transport Layer Security (TLS) > > ... > > 1.4. Applicability > > > > This document does not supersede the rules for certificate issuance > > or validation provided in [PKIX]. Therefore, [PKIX] is authoritative > > on any point that might also be discussed in this document. > > Furthermore, [PKIX] also governs any certificate-related topic on > > which this document is silent, including but not limited to > > certificate syntax, certificate extensions such as name constraints > > and extended key usage, and handling of certification paths." > > I do not see any specific requirements listed in the quoted paragraph > (not even a MAY). PKIX deals with the black box called "certificate > path validation" (within which EKU-processing is defined), and with > requirements for "conforming CAs" which issue X.509v3 certs (of which > there seem to exist very few, if any, considering how much junk > X.509v3 certificates are floating around. > > Could it be that GoDaddy is issuing Server certs that aren't valid ASN.1 DER ? > > Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DEFAULT FALSE" > correctly: > > BasicConstraints ::= SEQUENCE { > cA BOOLEAN DEFAULT FALSE, > pathLenConstraint INTEGER (0..MAX) OPTIONAL } > > Well, are they? Short of a hex dump of a GoDaddy certificate+chapter and verse of X509 I don't know how we are supposed to evaluate your claim. > > > > > > > > Did you notice that the id-kp-serverAuth that is defined in rfc5280 > > > is strictly limited to HTTP-over-TLS anyway, so would not apply to > > > XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou. > > > > You mean the "-- TLS WWW server authentication" comment in section > > 4.2.1.12? Or something else? > > > > Would you be happier if "WWW " wasn't in that comment? > > > This isn't about happiness. If this OID has any meaning at all, then this > limitation "TLS WWW server authentication" will be an integral part of it. > > An implementation of TLS will be looking here: > http://tools.ietf.org/html/rfc2246#page-38 > when checking KeyUsage of the Server Certificate, and *NOT* in PKIX. > > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look > exactly at rfc2818 for any checks that the client will do on the > Server certificate, and again *NOT* in PKIX. This is really a problem with RFC2818. The whole idea of X509v3 is that you should be able to issue certificates that have meaning beyond assertions of identity, such as for use as code-signing. But because implementations don't respect the PKIX standard, we can't do that. Instead you have to have separate trust roots, and the whole thing becomes a giant mess for people with lots of different keys to keep track of. (Imagine the janitor at a large institution and his key ring. Now imagine that if he uses the wrong key on a door, everything breaks. The poor sob isn't going to last long I'm afraid). It's particularly bad when you want to have a distributed agent-based authentication and authorization system. You end up needing Kerberos, which has a central server. > > > > >> Similarly, certificate policies and policy constrains extensions should > > >> be processed by the client and if the require explicit policy state > > >> variable get turned on and the path is not valid for some policy, > > >> it must be rejected. > > > > > > PolicyOIDs are completely meaningless for HTTP-over-TLS. > > > Is there *ANY* X-over-TLS specification that gives a meaning > > > to any policy OIDs? > > > > Yes. The CA/Browser Forum EV SSL Guidelines and Baseline Requirements. > > Ah--yes, the fancy Gui/chrome thingy for EV/OV/DV certs. > programmatic clients don't look at CAB Forum baseline requirements > (except maybe when looking for excuses to give to unhappy customers). Remind me what svn is used for again? Oh right, it downloads the FreeBSD ports tree. And what does the ports tree have? SHA256 hashes of all software in the ports tree used for checking authenticity of mirrored files. I can't imagine lacking necessary validation of certificates could possibly go wrong there. Now, Colin Percival developed a better way involving signed tarballs. I don't know how MacPorts does it. I know Apple signs its updates, and most people have realized that this is the way to go. (Especially given that you can sign on a hardened machine.) But you still have the problem of needing a PKI capable of expressing the policy you want to express. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --20cf3010e863e86fc804f67dcb0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 7, 2014 3:44 PM, "Martin Rex" <mrex@sap.com> wrote:
>
> Rob Stradling wrote:
> > Martin Rex wrote:
> >>
> >> There is *NO* such requirement (to look at EKU) anywhere in r= fc5246
> >> and rfc2818. =C2=A0The EKU processing within the PKIX certifi= cate path validation
> >> applies only to path certificates, not to the leaf certificat= e (because the
> >> certificate path validation is context-free, i.e. independent= of the
> >> actual usage of the certificate.
> >
> > Martin, how about RFC6125?
> >
> > "Representation and Verification of Domain-Based Application= Service
> > =C2=A0 Identity within Internet Public Key Infrastructure Using X= .509 (PKIX)
> > =C2=A0 =C2=A0 =C2=A0 Certificates in the Context of Transport Lay= er Security (TLS)
> > ...
> > 1.4. =C2=A0Applicability
> >
> > =C2=A0 =C2=A0 This document does not supersede the rules for cert= ificate issuance
> > =C2=A0 =C2=A0 or validation provided in [PKIX]. =C2=A0Therefore, = [PKIX] is authoritative
> > =C2=A0 =C2=A0 on any point that might also be discussed in this d= ocument.
> > =C2=A0 =C2=A0 Furthermore, [PKIX] also governs any certificate-re= lated topic on
> > =C2=A0 =C2=A0 which this document is silent, including but not li= mited to
> > =C2=A0 =C2=A0 certificate syntax, certificate extensions such as = name constraints
> > =C2=A0 =C2=A0 and extended key usage, and handling of certificati= on paths."
>
> I do not see any specific requirements listed in the quoted paragraph<= br> > (not even a MAY). =C2=A0 PKIX deals with the black box called "ce= rtificate
> path validation" (within which EKU-processing is defined), and wi= th
> requirements for "conforming CAs" which issue X.509v3 certs = (of which
> there seem to exist very few, if any, considering how much junk
> X.509v3 certificates are floating around.
>
> Could it be that GoDaddy is issuing Server certs that aren't valid= ASN.1 DER ?
>
> Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DE= FAULT FALSE"
> correctly:
>
> BasicConstraints ::=3D SEQUENCE {
> =C2=A0 =C2=A0 =C2=A0cA =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BOOLEAN DEFAULT FALSE,
> =C2=A0 =C2=A0 =C2=A0pathLenConstraint =C2=A0 =C2=A0 =C2=A0 INTEGER (0.= .MAX) OPTIONAL }
>
>

Well, are they? Short of a hex dump of a GoDaddy certificate+cha= pter and verse of X509 I don't know how we are supposed to evaluate you= r claim.

>
> >
> > <snip>
> > > Did you notice that the id-kp-serverAuth that is defined in = rfc5280
> > > is strictly limited to HTTP-over-TLS anyway, so would not ap= ply to
> > > XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.<= br> > >
> > You mean the "-- TLS WWW server authentication" comment= in section
> > 4.2.1.12? =C2=A0Or something else?
> >
> > Would you be happier if "WWW " wasn't in that comme= nt?
>
>
> This isn't about happiness. =C2=A0If this OID has any meaning at a= ll, then this
> limitation "TLS WWW server authentication" will be an integr= al part of it.
>
> An implementation of TLS will be looking here:
> =C2=A0 http://tools.ietf.org/html/rfc2246#page-38
> when checking KeyUsage of the Server Certificate, and *NOT* in PKIX. >
> And a TLS client that implements rfc2818 (HTTP-over-TLS) will look
> exactly at rfc2818 for any checks that the client will do on the
> Server certificate, and again *NOT* in PKIX.

This is really a pr= oblem with RFC2818. The whole idea of X509v3 is that you should be able to = issue certificates that have meaning beyond assertions of identity, such as= for use as code-signing. But because implementations don't respect the= PKIX standard, we can't do that. Instead you have to have separate tru= st roots, and the whole thing becomes a giant mess for people with lots of = different keys to keep track of. (Imagine the janitor at a large institutio= n and his key ring. Now imagine that if he uses the wrong key on a door, ev= erything breaks. The poor sob isn't going to last long I'm afraid).=

It's particularly bad when you want to have a distributed agent-base= d authentication and authorization system. You end up needing Kerberos, whi= ch has a central server.=C2=A0

> >
> > >> Similarly, certificate policies and policy constrains ex= tensions should
> > >> be processed by the client and if the require explicit p= olicy state
> > >> variable get turned on and the path is not valid for som= e policy,
> > >> it must be rejected.
> > >
> > > PolicyOIDs are completely meaningless for HTTP-over-TLS.
> > > Is there *ANY* X-over-TLS specification that gives a meaning=
> > > to any policy OIDs?
> >
> > Yes. =C2=A0The CA/Browser Forum EV SSL Guidelines and Baseline Re= quirements.
>
> Ah--yes, the fancy Gui/chrome thingy for EV/OV/DV certs.
> programmatic clients don't look at CAB Forum baseline requirements=
> (except maybe when looking for excuses to give to unhappy customers).<= /p>

Remind me what svn is used for again? Oh right, it downloads the Free= BSD ports tree. And what does the ports tree have? SHA256 hashes of all sof= tware in the ports tree used for checking authenticity of mirrored files. I= can't imagine lacking necessary validation of certificates could possi= bly go wrong there.

Now, Colin Percival developed a better way involving signed tarballs. I = don't know how MacPorts does it. I know Apple signs its updates, and mo= st people have realized that this is the way to go. (Especially given that = you can sign on a hardened machine.) But you still have the problem of need= ing a PKI capable of expressing the policy you want to express.

Sincerely,

Watson Ladd

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

--20cf3010e863e86fc804f67dcb0f-- From nobody Mon Apr 7 22: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 8FA681A012D for ; Mon, 7 Apr 2014 22:41:49 -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 1vFRY-ePEK4Z for ; Mon, 7 Apr 2014 22:41:45 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0462F1A012C for ; Mon, 7 Apr 2014 22:41:42 -0700 (PDT) Received: from fifthhorseman.net (unknown [107.19.144.191]) by che.mayfirst.org (Postfix) with ESMTPSA id 3E748F984 for ; Tue, 8 Apr 2014 01:41:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 22242200AF; Tue, 8 Apr 2014 01:41:35 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: <533622F3.2090406@fifthhorseman.net> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 08 Apr 2014 01:41:34 -0400 Message-ID: <87eh18xtrl.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AZZKtUm_8lodhL6DHJII-xrL9tQ Subject: [TLS] Negotiated Discrete Log DHE revision [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: Tue, 08 Apr 2014 05:41:49 -0000 --=-=-= Content-Type: text/plain On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor wrote: > 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 Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, i've updated the named groups in the above draft. I've also done another pass over the text: https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 Comments, questions and critiques welcome. --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTQ4wOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpckdMP/2iNoJbvnJRGLJ136Iw9C//Z KIwMvfuI+IuSYYYCj3oLLwviFYC8x91AUZUSXzO2AcAW8Drxoymiwotx1ulmSICr qCH3MxOpIp78hYVfitG6FMmSKGVuDvmHUe19Eru861enkxOpRwJYqIeo9s+kDxtr ZsQZSLQU2zPdkHAv4OG7Q3NOhkuWVb/a0+wlrUZinRlmu5d4HmUnYj18aQoeNCYq otlcLkXat4RQ9vQsdPnh4Z3IgkpSIMz3lPH3evqK1XwW+Dgo6zHHmEIReheB2gwt +5U4lyAbYA09MlleusVegN2yNUlaAgxyG6DMs3AFLCCUtxu8X1ta0xQMNuE4ifs7 AvL1lnaevdRjVdVtZRvpozb/0VeRO+R7cerfdwWNnbw+yu/laD0UJ4XMpxO5s3Iz sDnMVWYGxsXu6p5w/sYNelnhsjZtGChOwMwSDXzr+KDvWlWNva6BwwZnD7O5Oo+f 56KsR4aaRd0sUf2MJF5j9NdpiKPGZUAQQKdHOGTT+Wl+Lo/u/bhUO+pLRVG8oRys /yR2+s+IU/JclPN0MttX1fLiY47TFyHUd3f6tneQEnlZKEpY3U8j1lHFpboIqn5r 6O3bWqQbS4Qpj0qmFQt4LnL8q2wwy8XJ0WeuNPMYcpMNLOoILCxR6h2jIDKJ5z6r 0bXEuzUNEA42MXznM1/2 =8jqX -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 7 23: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 AE94D1A00C6 for ; Mon, 7 Apr 2014 23:25:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2_x7JlbJP9N for ; Mon, 7 Apr 2014 23:25:14 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id D0DC71A00AF for ; Mon, 7 Apr 2014 23:25:14 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta13.emeryville.ca.mail.comcast.net with comcast id nJGj1n00A0S2fkCADJR9NB; Tue, 08 Apr 2014 06:25:09 +0000 Received: from [192.168.1.8] ([71.202.164.227]) by omta09.emeryville.ca.mail.comcast.net with comcast id nJR71n00M4uhcbK8VJR8Bo; Tue, 08 Apr 2014 06:25:08 +0000 Message-ID: <53439643.5090004@brainhub.org> Date: Mon, 07 Apr 2014 23:25:07 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <5341EFA4.7070808@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1396938309; bh=MxBZE3M8UElNf/YFBE6FkpuBvZNO7TH5CIuyZxis3gQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DfWLfry2AQtH8TaGwkkAWcmyTV6/LxyZgOhB3i1irdoofC8F7DE6pi6W+sspH68Og LZty7uYmOI6molvHhOzIlk5IC/RjqVFGAIiZaOSHV8jRUWkVliiRUCxSN2HsE8ooil NlwOUgLR4xy/Y3Fqir3FpxbXg+Csqki30tHbTH05/XUqr8MVerCFsAP7D28/UR2Flc +7upeKWOjKflnwR2LxjEz0xvYyh6VhpuaqnH5dNucLx/VNlBsiuVr15iwxLQHY1c35 EL8l8HGAmrzidFK2Gx7Y9NgFJUdDn5pLj6lCg4v6bfxr+RZsgk5fM+y5o5xMdYcMi/ iF967na4YII7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e1GmxhRtfhGScevNH6vhq6mY4aY Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 06:25:19 -0000 On 04/07/2014 10:40 AM, Watson Ladd wrote: > > On Apr 7, 2014 10:21 AM, "Martin Thomson" > wrote: > > > > On 6 April 2014 17:21, Andrey Jivsov > wrote: > > > The spec would benefit from a suggestion about what the recommended > use of > > > the padding extension is (i.e. to which size one should pad). > > > > > > This has been discussed extensively, here and elsewhere. See for > > instance, http://www.ietf.org/mail-archive/web/tls/current/msg10423.html > > or https://www.imperialviolet.org/2013/10/07/f5update.html or > > https://code.google.com/p/chromium/issues/detail?id=315828 . > > > > I expect that the draft authors are being sensitive to the fact there > > is no need to create a more public, permanent record of what is a > > transient problem. I appreciate this concern, but I think that both goals can be achieved. I was looking for a generic description of what problem the draft solves and how from the viewpoint of somebody who is unfamiliar with the problem. Something along these lines: > The extension can mitigate defects in TLS message identification by > allowing the sender control the values of octets representing the > size of the ClientHello packet. The extension can also be used as a > testing tool for such issues. > > I read the F5 explaination. It's worth keeping it around so in the > future, when tempted to upgrade a binary protocol we ask the guy > proposing the upgrade how to distinguish old and new. True. One should always think about what kind of a state machine will be needed to handle the old and new protocol messages. From nobody Tue Apr 8 01: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 E867F1A01AC for ; Tue, 8 Apr 2014 01:07:16 -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 E3Omn0DxwvtP for ; Tue, 8 Apr 2014 01:07:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1160C1A01B0 for ; Tue, 8 Apr 2014 01:07:07 -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 s38871ma014712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 04:07:01 -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 s3886wkT028535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Apr 2014 04:06:59 -0400 Message-ID: <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Tue, 08 Apr 2014 10:06:58 +0200 In-Reply-To: References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> 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/3pItrEH8Axe0grOHTM5eafNYHq0 Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 08:07:17 -0000 On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote: > > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look > > exactly at rfc2818 for any checks that the client will do on the > > Server certificate, and again *NOT* in PKIX. > > This is really a problem with RFC2818. The whole idea of X509v3 is > that you should be able to issue certificates that have meaning beyond > assertions of identity, such as for use as code-signing. But because > implementations don't respect the PKIX standard, we can't do that. I think PKIX is far from being described as standard. It looks more than a set of rules that the implementer is expected to distill and select the relevant ones, as most of the described rules are legacy baggage (e.g. DN comparison rules that assume that the DN is copied by a secretary that introduces case changes and alters spaces, rather than a memcpy). PKIX's requirements are pretty strange to put it mildly. One example are the key purposes that Martin described. Another is the name constraints which is optional to implement for DNS or e-mails (that everyone uses), and mandatory for DistinguishedNames (that no-one uses); then it becomes an issue when people realize that no-one implements name constraints (and the only certificates that I've seen that contained constraints, had syntactical errors in them). There are much more issues in PKIX (and Peter Gutmann is much better in providing a good overview). We certainly need something better than rfc5280. regards, Nikos From nobody Tue Apr 8 06:39: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 029511A03DF for ; Tue, 8 Apr 2014 06:39:18 -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_50=0.8, 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 F8-aogOO6bih for ; Tue, 8 Apr 2014 06:39:13 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D461C1A03D9 for ; Tue, 8 Apr 2014 06:39:12 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id w10so265426bkz.9 for ; Tue, 08 Apr 2014 06:39: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=bQ2hBQFHxXvFjOFB+mH+ryBVu5PLYEKXnUHrsVXWq8A=; b=DPru992tlMYhb1uNWb2mCgjOBOaeZpWl3uUth9W9PABo2YHj19PhK86oYtww/9Qrc0 oT775/vLhE+rPaBCgz6H1yuWFzcPxJ3KHdA+XFyu3AG0QFFg3ACo0TW2CYnDvgMHz7D0 xZfv2/s3xi5VUXzsDkdcA1CHVKIjiPVVRfaEwv0sN/w44FhTaBrFEHT5u4U+wfE0VzoP /Rq2upascSxzImyzlIP6fcuM/h57xEdqQYpJpb0kqiUIsgWKT1Zig6hUZBGI9srdSXWk oB7KEEKI4JA7RwKYhj9jUcErAOJnL4QibYfGWQrfxTU+N8y8uVx/K0BH6mqaEzWKn0kl U6pg== MIME-Version: 1.0 X-Received: by 10.112.46.225 with SMTP id y1mr2819964lbm.12.1396964352064; Tue, 08 Apr 2014 06:39:12 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 8 Apr 2014 06:39:11 -0700 (PDT) In-Reply-To: <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> Date: Tue, 8 Apr 2014 09:39:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X5AGP6fvMGoHDoGDlgYUjmsd8zk Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 13:39:18 -0000 On Tue, Apr 8, 2014 at 4:06 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote: > >> > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look >> > exactly at rfc2818 for any checks that the client will do on the >> > Server certificate, and again *NOT* in PKIX. >> >> This is really a problem with RFC2818. The whole idea of X509v3 is >> that you should be able to issue certificates that have meaning beyond >> assertions of identity, such as for use as code-signing. But because >> implementations don't respect the PKIX standard, we can't do that. > > I think PKIX is far from being described as standard. It looks more than > a set of rules that the implementer is expected to distill and select > the relevant ones, as most of the described rules are legacy baggage > (e.g. DN comparison rules that assume that the DN is copied by a > secretary that introduces case changes and alters spaces, rather than a > memcpy). > > PKIX's requirements are pretty strange to put it mildly. One example are > the key purposes that Martin described. Another is the name constraints > which is optional to implement for DNS or e-mails (that everyone uses), > and mandatory for DistinguishedNames (that no-one uses); then it becomes > an issue when people realize that no-one implements name constraints > (and the only certificates that I've seen that contained constraints, > had syntactical errors in them). There are much more issues in PKIX (and > Peter Gutmann is much better in providing a good overview). We certainly > need something better than rfc5280. Name constraints are in use today. They are supported in all the browsers with the possible exception of OSX (which I am told is fixed but I have not checked). The issue with Name Constraints is that the Industry has rejected the IETF specification which requires that a Name Constraint be marked 'break backwards compatibility' aka the 'critical bit'. This requirement is stupid and wrong and so the industry has decided to override RFC5280 on this point and the correct specification as far as the industry is concerned is that the setting of the critical bit is at the option of the issuing CA. If IETF produces rubbish specifications we will ignore them. The requirement to mark the certificate critical enabled the NSA attack on Microsoft in the Flame malware attack. Marking the bit critical makes it impossible to issue a certificate with that extension as about half a billion deployed devices don't support name constraints. The consensus model does not really work when a specification has been poisoned by an attacker who can block changes to correct the spec. Fortunately IETF specifications are not definitive, industry practice is. The industry consensus on this point is unanimous: name constraints need not be marked critical. Industry consensus is also unanimous that RSA1024 is inadequate for any form of PKI infrastructure use including for ZSKs. So right now DNSSEC is not adequately deployed in the ICANN root or in .com in a form that can be considered fit for purpose. So the idea that the world is going to move to a DANE validity chain is rather peculiar. Fixing this situation requires a minor configuration change next time the keys are rolled. So don't take this as an argument against DNSSEC per se. I think it is just indicative of the reason why having ICANN in charge of global PKI is not exactly a sound proposition. -- Website: http://hallambaker.com/ From nobody Tue Apr 8 08:48: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 099701A0481 for ; Tue, 8 Apr 2014 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx1K7nHeAdcf for ; Tue, 8 Apr 2014 08:48:37 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4CF1A0467 for ; Tue, 8 Apr 2014 08:48:36 -0700 (PDT) Received: from [10.21.9.0] (unknown [107.19.144.191]) by che.mayfirst.org (Postfix) with ESMTPSA id 51B44F984; Tue, 8 Apr 2014 11:48:34 -0400 (EDT) Message-ID: <53441A51.2080800@fifthhorseman.net> Date: Tue, 08 Apr 2014 11:48:33 -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: Watson Ladd , Martin Thomson References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <5341EFA4.7070808@brainhub.org> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wP7gTh5pkdabgSdVGSCfOEAvbbLdnk0eM" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JrL8yDMg8vto-fkLU2DfPMnAjyg Cc: tls@ietf.org Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 15:48:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wP7gTh5pkdabgSdVGSCfOEAvbbLdnk0eM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/07/2014 01:40 PM, Watson Ladd wrote: > I read the F5 explaination. It's worth keeping it around so in the futu= re, > when tempted to upgrade a binary protocol we ask the guy proposing the > upgrade how to distinguish old and new. >=20 > In particular, tossing it down the memory hole out of misguided > professional courtesy would probably mean making the same mistake in th= e > future. >=20 > In particular treating this extension's proper use as something to be > passed on by word of mouth hurts new implementors who don't know the ma= gic > number. Embarrassment for F5 is nowhere near as serious. I agree with Watson here. Including some variant of Xiaoyong Wu's explanation [0] in the padding draft would be useful for future implementers. The global network *does* still have SSLv2 endpoints on it, and they connect to and listen on ports that SSLv3/TLSv1.{0,1,2} peers also use. I think Xiaoyong and F5 have done us all a favor by making this situation clear. This shouldn't be considered an embarrassment for them.= --dkg [0] https://www.ietf.org/mail-archive/web/tls/current/msg10423.html --wP7gTh5pkdabgSdVGSCfOEAvbbLdnk0eM 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/ iQJ8BAEBCgBmBQJTRBpRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcSyUP/RpSvLQ8ePwczzClw0M4t6gl oO6oF6og2yQPjf+nyDfGWW/CR9vhI+CbMhJOL8gZ4ba2bCKwSUUODC3xcszsC/N4 q64yEgYgK78OlaU7yKgTrLCPcHM70Tzg3Xp3swczXtQflzhq16J9ORzHrUUxEpkW FwcwSvTIUl76hjmfs2vb5uLnTMrVUliB9AZ+roQUuZrFivlkWdTBoTqZ8uAYAsEE I3TK37AJbV9u1ydRo+cKJsUfu4s5js/9LW6nACvyrMIxgb7k6CmPYmEU17fARLPM +KF3eHxWUJdfm2jF2WLMx+lcmsacQ0wU+ps3LejMzbaIPgkPDtc/ZHeGl9p0033c +d2J+xDIpnCo49+i7kdbNO1/06mKNl8aq/2oJ4eGePNswG4WrWkFJRnMDcqYeeef VQGq2Qfe8h05q7xkQtf2ZMytCupkSiCZH+foAtP9hbwQyiZA9yFv8NCHQppcqHxj p61GJoE52TZRcFXduauBZaIcz3R4jDuiLQvay39YoXP1x1/bod1FCPBJf8l+f8LF Tr1KumCMGLtBH+IueTYEyPFADzolNqWBbPNzdHj3cZZavDbb7vyX+RNziijt31lj BXP8fv46K/RzgE37fZ8q56spJI19cDwZXu68ELW8ujvcZOs+GnBpubeBV9rbAkff UTAXg7Wcyeog4pNb5j0M =WJBZ -----END PGP SIGNATURE----- --wP7gTh5pkdabgSdVGSCfOEAvbbLdnk0eM-- From nobody Tue Apr 8 09: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 0CFBC1A049F for ; Tue, 8 Apr 2014 09:05: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 Q-wF-BDnNlLE for ; Tue, 8 Apr 2014 09:05:37 -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 5C33C1A03DF for ; Tue, 8 Apr 2014 09:05:27 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so992369ykq.14 for ; Tue, 08 Apr 2014 09:05: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=qDqFAGrzHaenkODzJCWxr6HonzxcRjRaexju+ocv8RE=; b=rOobCUOWoz1FSI2RPkLqU2wdPiuYHY9oNnGLiFJg8QVYUn6jo2N0Wcic9aGmBUfqgN 0r1rs7DBgZwLMAWe4XVLDTfaVKFAUBoKiHUYrRUEq1k0QHDUtsrEap1Rd2FT9Klg0Zp/ Y6KoEiWp3Bak+zOH26zoMRie8bomJiq0DuWtgkAjOaR9OBFhGcTeGlao0LdATEzd1RH/ 7OjMufmKATPDXlRmJsPShe+J/T/j3oVqdaVvt3W23v9vKe83OZBueHPOQBBewor/XDmD 1Y3P0rwtai87hcUHv1ujKktwnjN10+5kNLJOxJ8c9Oqu+++tY99GlTjmol/RIjHSJxOI SjFQ== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr6408771yhj.63.1396973127144; Tue, 08 Apr 2014 09:05:27 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 8 Apr 2014 09:05:26 -0700 (PDT) In-Reply-To: References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> Date: Tue, 8 Apr 2014 09:05:26 -0700 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A3X4-c_oKu49Dw-ZadKB14O1Rk8 Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 16:05:46 -0000 On Tue, Apr 8, 2014 at 6:39 AM, Phillip Hallam-Baker wrote: > On Tue, Apr 8, 2014 at 4:06 AM, Nikos Mavrogiannopoulos wrote: >> On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote: >> >>> > And a TLS client that implements rfc2818 (HTTP-over-TLS) will look >>> > exactly at rfc2818 for any checks that the client will do on the >>> > Server certificate, and again *NOT* in PKIX. >>> >>> This is really a problem with RFC2818. The whole idea of X509v3 is >>> that you should be able to issue certificates that have meaning beyond >>> assertions of identity, such as for use as code-signing. But because >>> implementations don't respect the PKIX standard, we can't do that. >> >> I think PKIX is far from being described as standard. It looks more than >> a set of rules that the implementer is expected to distill and select >> the relevant ones, as most of the described rules are legacy baggage >> (e.g. DN comparison rules that assume that the DN is copied by a >> secretary that introduces case changes and alters spaces, rather than a >> memcpy). >> >> PKIX's requirements are pretty strange to put it mildly. One example are >> the key purposes that Martin described. Another is the name constraints >> which is optional to implement for DNS or e-mails (that everyone uses), >> and mandatory for DistinguishedNames (that no-one uses); then it becomes >> an issue when people realize that no-one implements name constraints >> (and the only certificates that I've seen that contained constraints, >> had syntactical errors in them). There are much more issues in PKIX (and >> Peter Gutmann is much better in providing a good overview). We certainly >> need something better than rfc5280. > > Name constraints are in use today. They are supported in all the > browsers with the possible exception of OSX (which I am told is fixed > but I have not checked). > > The issue with Name Constraints is that the Industry has rejected the > IETF specification which requires that a Name Constraint be marked > 'break backwards compatibility' aka the 'critical bit'. This > requirement is stupid and wrong and so the industry has decided to > override RFC5280 on this point and the correct specification as far as > the industry is concerned is that the setting of the critical bit is > at the option of the issuing CA. > > If IETF produces rubbish specifications we will ignore them. > > The requirement to mark the certificate critical enabled the NSA > attack on Microsoft in the Flame malware attack. Marking the bit > critical makes it impossible to issue a certificate with that > extension as about half a billion deployed devices don't support name > constraints. ?? Flame was a MD5 collision. Nothing saves you from that one. > > The consensus model does not really work when a specification has been > poisoned by an attacker who can block changes to correct the spec. > Fortunately IETF specifications are not definitive, industry practice > is. The industry consensus on this point is unanimous: name > constraints need not be marked critical. Which makes them useless: the point of name constraints is that I can issue a name constrained certificate without issuing a global intermediate CA certificate. If the extension is not marked critical, then I've issued a global intermediate CA certificate for those who don't check it, and so need to be just as strict as if it was an intermediate CA certificate, so I might as well not bother with the constraint. > > > Industry consensus is also unanimous that RSA1024 is inadequate for > any form of PKI infrastructure use including for ZSKs. So right now > DNSSEC is not adequately deployed in the ICANN root or in .com in a > form that can be considered fit for purpose. So the idea that the > world is going to move to a DANE validity chain is rather peculiar. > > Fixing this situation requires a minor configuration change next time > the keys are rolled. So don't take this as an argument against DNSSEC > per se. I think it is just indicative of the reason why having ICANN > in charge of global PKI is not exactly a sound proposition. No, this one is IETF. The spec for ECDSA in DNSSEC is only from 2012. As a result there wasn't an alternative when the root zone was being signed. Furthermore, changing the root key is an interesting exercise. Sincerely, Watson Ladd > > -- > Website: http://hallambaker.com/ -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Apr 8 09:53: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 276621A041E for ; Tue, 8 Apr 2014 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH7MRQhgHeeD for ; Tue, 8 Apr 2014 09:53:26 -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 3EC7F1A045F for ; Tue, 8 Apr 2014 09:53:26 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A1CF7100AD; Tue, 8 Apr 2014 12:53:25 -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=uamkWBwqf506 csooq7WkEkl9vcI=; b=loCtC0yDcsBj/JSojsVZLc6dLiEhHIDknR95CAKYDo1P WZTdDfz+U2Psi0Mwe3fb3kURkSxxdtcc7lux0hyuvQVGUYLLyjCagfpbgXSGXJMa UvHGJxnBcAn5qBbs361jCCqrup4w+5s2Ebl+zEBrXg9B8UW5pJgnCaAFBqxFxcA= 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=TSVAGH kSPyGV+lBcF5mnSo+gD/wzVexQR2kbqlw5Z592tu+maGrWtm7DSqVw16uVJ26nfH J9m9MXa+WWjuwoSAHw8uAvrpfMBQZVRf+CLREeWJKd5xLheqWfe23iBzGydAD7+e b/GS+k3blKZdD7ml6eWdrFavBZtWSIiFiUKzI= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9AFC8100AC; Tue, 8 Apr 2014 12:53:25 -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 7C5E6100AB; Tue, 8 Apr 2014 12:53:24 -0400 (EDT) Message-ID: <53442983.1030703@pobox.com> Date: Tue, 08 Apr 2014 09:53:23 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> In-Reply-To: <87eh18xtrl.fsf@alice.fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4CB36814-BF3E-11E3-9B61-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YKb4M9eLQMa2TP3s4CYAAHidRcs Cc: tls@ietf.org Subject: Re: [TLS] Negotiated Discrete Log DHE revision [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: Tue, 08 Apr 2014 16:53:31 -0000 There is already a list of DH groups managed by the IANA for IKE that was established by RFC 2409 and includes the MODP groups from RFC 3526 plus others. Why not just use this existing registry and add your new e-based groups to it? Mike Daniel Kahn Gillmor wrote: > On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor wrote: >> 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 > > Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, > i've updated the named groups in the above draft. > > I've also done another pass over the text: > > https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 > > Comments, questions and critiques welcome. > > --dkg From nobody Tue Apr 8 10:06: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 761AA1A058E for ; Tue, 8 Apr 2014 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jCBUCR2UMj0 for ; Tue, 8 Apr 2014 10:06:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 753F41A0641 for ; Tue, 8 Apr 2014 10:06:17 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s38H6AJf025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 19:06:10 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Tue, 8 Apr 2014 19:06:10 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140408170610.A40831ACB0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/10EsdSlcS7CWnsyk9EiWPuZRDTo Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 08 Apr 2014 17:06:25 -0000 Watson Ladd wrote: > "Martin Rex" wrote: >> >> PKIX deals with the black box called "certificate >> path validation" (within which EKU-processing is defined), and with >> requirements for "conforming CAs" which issue X.509v3 certs (of which >> there seem to exist very few, if any, considering how much junk >> X.509v3 certificates are floating around. >> >> Could it be that GoDaddy is issuing Server certs that aren't valid >> ASN.1 DER ? >> >> Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DEFAULT FALSE" >> correctly: >> >> BasicConstraints ::= SEQUENCE { >> cA BOOLEAN DEFAULT FALSE, >> pathLenConstraint INTEGER (0..MAX) OPTIONAL } >> > > Well, are they? Short of a hex dump of a GoDaddy certificate+chapter and > verse of X509 I don't know how we are supposed to evaluate your claim. openssl asn1dump for Server cert from https://www.verisign.com/ 1087:d=4 hl=2 l= 9 cons: SEQUENCE 1089:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1094:d=5 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 openssl asn1dump for Server cert from https://www.godaddy.com/ 784:d=4 hl=2 l= 15 cons: SEQUENCE 786:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 791:d=5 hl=2 l= 1 prim: BOOLEAN :255 794:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:3003010100 801:d=4 hl=2 l= 29 cons: SEQUENCE 803:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage 808:d=5 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:301406082B060105050703 0106082B06010505070302 The godaddy ASN.1 DER encoding problem might be specific to the BasicConstraints extension. The criticality Boolean is correctly omitted in their non-critical ExtendedKeyUsage encoding, but not within the BasicConstraints extension. -Martin From nobody Tue Apr 8 10:22: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 164241A0473 for ; Tue, 8 Apr 2014 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQVi_8kWlCCN for ; Tue, 8 Apr 2014 10:22:24 -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 C71041A0660 for ; Tue, 8 Apr 2014 10:22:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 663BD10284; Tue, 8 Apr 2014 13:22:06 -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=3W8XjBWNnqCz tDWsgYw3abNeG6c=; b=x08+2YHf6A/rNCFjwCjdyKcJf1ymbq1C7knXAQ93k+fj ZhNUPRZLAr/dBD2dj1IQFGq0pUYGVpxA/+PKjx9l05P/9AJXuVw8iQMZC/4xnhAD UUg9/5Y9crO5rQq8XoDugSLiCKXrgkJCyRXKFDdnn+cAB9RReY3ibeFwGOInnnM= 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=dccCB5 FxzlvcoC/KE1zVrFsuveyyUrm0JTGjs90K5rOA1H9bh9aDCRRZlIxJ86BNXrOWvw v/HGU5XEuIF4nZa6eVs0B+9ojpsB8g2Ga3ImI9eQe3UMh9cD1GHPmYZbBJfcOlX+ 0rlLConmNKGOiCzyu/aDq0WXSFmpQUrWEAkKE= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5EB2110283; Tue, 8 Apr 2014 13:22:06 -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 49B4010282; Tue, 8 Apr 2014 13:22:05 -0400 (EDT) Message-ID: <5344303C.2050607@pobox.com> Date: Tue, 08 Apr 2014 10:22:04 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> In-Reply-To: <53442983.1030703@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4E5CD12E-BF42-11E3-8074-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/glkk3djX26JOrb5KcO_L1sqZr-Q Cc: tls@ietf.org Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 17:22:30 -0000 Also, I'm curious why "e" is chosen for constructing these primes. Since the natural log of e is 1, doesn't it seem like a bad idea to stick a bunch of bits of e in a prime where the security is based on logarithms? Mike Michael D'Errico wrote: > There is already a list of DH groups managed by the IANA for IKE that was > established by RFC 2409 and includes the MODP groups from RFC 3526 plus > others. Why not just use this existing registry and add your new e-based > groups to it? > > Mike > > > > Daniel Kahn Gillmor wrote: >> On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor >> wrote: >>> 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 >> >> Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, >> i've updated the named groups in the above draft. >> >> I've also done another pass over the text: >> >> https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 >> >> Comments, questions and critiques welcome. >> >> --dkg From nobody Tue Apr 8 11:07: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 0899A1A0684 for ; Tue, 8 Apr 2014 11:07:38 -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 aCJixnIR04cW for ; Tue, 8 Apr 2014 11:07:34 -0700 (PDT) Received: from vsp10.ballou.se (vsp10.ballou.se [91.189.40.106]) by ietfa.amsl.com (Postfix) with SMTP id DAA561A047B for ; Tue, 8 Apr 2014 11:07:33 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp10.ballou.se (Halon Mail Gateway) with ESMTP for ; Tue, 8 Apr 2014 20:04:43 +0200 (CEST) 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 34B6A11CE4A for ; Tue, 8 Apr 2014 20:07:30 +0200 (CEST) Message-ID: <53443ADD.3040008@streamsec.se> Date: Tue, 08 Apr 2014 20:07:25 +0200 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: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> In-Reply-To: <5344303C.2050607@pobox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjPTNW8vfSiXbo35V_6_PVvXDpc Subject: Re: [TLS] Negotiated Discrete Log DHE revision 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: Tue, 08 Apr 2014 18:07:38 -0000 There is no discrete logarithm algorithm that can take advantage of the fact you mention. However, e might be a less optimal choice for another reason, namely that the next higher safe prime is relatively far away from the starting points you get when you use e this way. For instance, in the case of the 6144 bit prime, it is more than 2^33 steps away from the starting point, which means it will take a lot of time to verify the correctness of these primes (once you found them). On 2014-04-08 19:22, Michael D'Errico wrote: > Also, I'm curious why "e" is chosen for constructing these primes. Since > the natural log of e is 1, doesn't it seem like a bad idea to stick a bunch > of bits of e in a prime where the security is based on logarithms? > > Mike > > > > Michael D'Errico wrote: >> There is already a list of DH groups managed by the IANA for IKE that was >> established by RFC 2409 and includes the MODP groups from RFC 3526 plus >> others. Why not just use this existing registry and add your new e-based >> groups to it? >> >> Mike >> >> >> >> Daniel Kahn Gillmor wrote: >>> On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor >>> wrote: >>>> 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 >>> >>> Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, >>> i've updated the named groups in the above draft. >>> >>> I've also done another pass over the text: >>> >>> https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 >>> >>> Comments, questions and critiques welcome. >>> >>> --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 8 11:40: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 D6BCB1A06B0 for ; Tue, 8 Apr 2014 11:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG7aLPYPFIZg for ; Tue, 8 Apr 2014 11:40:41 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id C75C41A06A7 for ; Tue, 8 Apr 2014 11:40:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,819,1389762000"; d="scan'208";a="2562349" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 08 Apr 2014 14:40:38 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Tue, 8 Apr 2014 14:40:37 -0400 From: Santosh Chokhani To: "mrex@sap.com" Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: AQHPUG9nRS10t5Ha0EyLKsoi0FgTh5sG4JsA///FM+CAAE2tgIABHNfA Date: Tue, 8 Apr 2014 18:40:36 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> References: <4262AC0DB9856847A2D00EF817E811391789E8@scygexch10.cygnacom.com> <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> In-Reply-To: <20140407213051.8B5E11ACAA@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.117.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/Hjjpt721r5KRrUS6pA5EMqJpFwI Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 18:40:46 -0000 Martin, There are several misunderstandings on your part. The EKU is generally only applies to the leaf certificate (per X.509 and RF= C 5280) and is not involved in path processing. I would think that if EKU = is present at least a browser application will ensure that the certificate = has server auth OID. While TLS applications may or may not be able to set policies, the interact= ions among policy related extensions and path validation state machine can = make the path invalid if the policy intersection is null and the require ex= plicit policy flag has been turned on. Path building need not be tied to path validation. That is your choice. N= ame constraints for the hierarchical name form types are not a mess as you = say. 5280 and X.509 are pretty clear on how to implement them and I know o= f and have been involved in a few successful implementations. I see lot of misunderstandings and exaggerations about problems in X.509 an= d RFC 5280 and folks with incorrect implementations having an axe to grind.= =20 Our time is better spent in implementing a well-designed RFC properly, addr= essing issues it has as opposed to justifying poor implementations. We have enough problems implementing good specs. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, April 07, 2014 5:31 PM To: Santosh Chokhani Cc: mrex@sap.com; Watson Ladd; tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms Santosh Chokhani wrote: > > While I am still reading the cited paper , the EKU if present should=20 > be very relevant. The client should reject the server certificate if=20 > server authentication or anhyExtendedKeyUsage is not present. There is *NO* such requirement (to look at EKU) anywhere in rfc5246 and rfc= 2818. The EKU processing within the PKIX certificate path validation appli= es only to path certificates, not to the leaf certificate (because the cert= ificate path validation is context-free, i.e. independent of the actual usa= ge of the certificate. KeyUsage is different, processing KeyUsage is explicitly described in rfc22= 46/rfc4346/rfc5246. Did you notice that the id-kp-serverAuth that is defined in rfc5280 is stri= ctly limited to HTTP-over-TLS anyway, so would not apply to XMPP-over-TLS, = SIP-over-TLS, SMTP-over-TLS and whathaveyou. > > Similarly, certificate policies and policy constrains extensions=20 > should be processed by the client and if the require explicit policy=20 > state variable get turned on and the path is not valid for some=20 > policy, it must be rejected. PolicyOIDs are completely meaningless for HTTP-over-TLS. Is there *ANY* X-over-TLS specification that gives a meaning to any policy = OIDs? > > Finally, name constraint is very relevant. name constraints will be missing from a PKIX minimum requirements RP. And considering how broken the _definitions_ are, and how broken some of the CA software is that is creating them, simply ignoring name constraints seems like the only sane behaviour. > > The certificate must be rejected if any of the name forms in a > certificate in the path violate name constraint state variable > values at that point in the path. name constraints are a HUGE mess. PKIX does not really describe their processing at all, and neither gives an indication that when *ANY* name constraints are used that name constraints on distinguished names will have to be used as well, otherwise creating security problems for the permissible CRL signer logic. When looking at how X.509 describes processing of name constraints in the example section, you may realize that it talks about iteratively trying to build certification pathes and checking whether name constraints work from them. Ooops. building a certification path is declared out of scope by rfc5280, so logically, this spills the baby with the bathtub and makes name constraints in PKIX/rfc5280 optional in its entirety, because something that needs a feature that has been explicitly declared out of scope can never be a mandatory part of the spec. -Martin From nobody Tue Apr 8 12:06: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 6FB5E1A069A for ; Tue, 8 Apr 2014 12:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4PW1s7crGVh for ; Tue, 8 Apr 2014 12:06:52 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3381A06EC for ; Tue, 8 Apr 2014 12:06:49 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 8E13C1DE070 for ; Tue, 8 Apr 2014 12:06:49 -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=lom+Vhje3M3g5vjz/kmR bMTIkz0=; b=XNA6XTS5YAV+STVf/cFHaPipsUqVbn0uliI0DRwDhIbElin+QOI9 IA8nqvuM1Q+S5ZTgwNS6qIJFJByRnJv9kOWeJ/l2o9fFu+WfWx7/NoiOdhO3Tc9k RZP452+68ECN+Tm+WqDhWYsUkjdWqoFeejJLnPXMBf2EUbppWjbZ1Jc= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 1797B1DE05D for ; Tue, 8 Apr 2014 12:06:48 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so1437134wgh.20 for ; Tue, 08 Apr 2014 12:06:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr5952176wib.5.1396984007886; Tue, 08 Apr 2014 12:06:47 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Tue, 8 Apr 2014 12:06:47 -0700 (PDT) In-Reply-To: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> References: <4262AC0DB9856847A2D00EF817E811391789E8@scygexch10.cygnacom.com> <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> Date: Tue, 8 Apr 2014 14:06:47 -0500 Message-ID: From: Nico Williams To: Santosh Chokhani Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gSQKMyHNHvaGnPPih2AQAS1DJnI Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Apr 2014 19:06:56 -0000 On Tue, Apr 8, 2014 at 1:40 PM, Santosh Chokhani wrote: I agree with what you say, but there is one area where I think name constraints could be improved: when a certificate has no subjectAlternativeNames, or only directoryNames when it does, and those names are RFC6125-style, then if the CA certs in the validation path have dNSName name constraints then those should be applied to the CN RDNs of the subjectName and/or dirname SANs that bear the domainnames. To my knowledge this isn't codified, but correct me if I'm wrong. Nico -- From nobody Tue Apr 8 12:33: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 225491A023E for ; Tue, 8 Apr 2014 12:33:17 -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 JUmoiuyb3Q5C for ; Tue, 8 Apr 2014 12:33:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 001A71A070B for ; Tue, 8 Apr 2014 12:33:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s38JXBAj019504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 21:33:11 +0200 (MEST) In-Reply-To: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> To: Santosh Chokhani Date: Tue, 8 Apr 2014 21:33:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140408193311.61C931ACB0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ETRW2f2dvctvfPfdcscWhhAT4dw Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 08 Apr 2014 19:33:17 -0000 Santosh Chokhani wrote: > > The EKU is generally only applies to the leaf certificate > (per X.509 and RFC 5280) and is not involved in path processing. EKU applies *ONLY* to higher layer protocols where the higher layer protocol specifies behaviour for a list of EKUs. For TLS, such specification simply do not exist. Potentially, there is something in the CABrowser Forum Baseline requirements. But I'm not a Browser implementor, so I don't know and don't care. I'm a maintainer of a TLS library and application level wrapper to TLS for programmatic use. > > While TLS applications may or may not be able to set policies, > the interactions among policy related extensions and path validation > state machine can make the path invalid if the policy intersection > is null and the require explicit policy flag has been turned on. Aside from what the CABForum & Browser folks may have defined to create fancy GUI chrome, I'm not currently aware of any X-over-TLS spec that gives meaning to policies. So the easiest approach is to entirely ignore them -- during path validation as well as on the end entity certs. > > Path building need not be tied to path validation. That is your choice. > Name constraints for the hierarchical name form types are not a mess > as you say. To me, the idea behind X.509 11/2008 Appendix G.3.3 looks like a pretty big mess, and it requires an iterative approach of building a certification path, failing, building an alternative path and succeeding, and this is where the whole name constraints processing becomes out of scope of PKIX/rfc5280. > > I see lot of misunderstandings and exaggerations about problems in X.509 > and RFC 5280 and folks with incorrect implementations having an axe to grind. I see a huge amount of needless complexity A while ago I had an inquiry from a governmental customer because our library rejected their "pretty" certificate chains on the TLS server cert. They had a critical policy constraints extension in one of their path CA certs https://tools.ietf.org/html/rfc5280#section-4.2.1.11 with the field "inhibitPolicyMapping" present(!) To me, this particular extension looks like a pretty stupid design flaw. -Martin From nobody Tue Apr 8 13:42: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 163101A0412 for ; Tue, 8 Apr 2014 13:41:59 -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 PKZhBRBigxl3 for ; Tue, 8 Apr 2014 13:41:54 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA91A034E for ; Tue, 8 Apr 2014 13:41:54 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s38KfoW1028710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Apr 2014 22:41:50 +0200 (MEST) In-Reply-To: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> To: Santosh Chokhani Date: Tue, 8 Apr 2014 22:41:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140408204150.9505B1ACB3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WrjK0UM8J5nwlmI8IujY2Q3Jlaw Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms 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, 08 Apr 2014 20:41:59 -0000 Santosh Chokhani wrote: > > The EKU is generally only applies to the leaf certificate (per X.509 > and RFC 5280) and is not involved in path processing. > I would think that if EKU is present at least a browser application > will ensure that the certificate has server auth OID. There is one central statement in rfc5280/PKIX that you seem to be unaware of: https://tools.ietf.org/html/rfc5280#section-6.1 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. Whit this "this profile RECOMMENDS against including such checks" says explicitly to an TLS implementor: you SHOULD NOT implement any conformance checks to stuff that is described in section 4 & 5 of this document. (so you do not have to read, let alone understand what all the stuff in that part of the document means). -Martin From nobody Tue Apr 8 17: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 0C40A1A06F6 for ; Tue, 8 Apr 2014 17:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1M_x3ehciny for ; Tue, 8 Apr 2014 17:41:08 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 48E691A0192 for ; Tue, 8 Apr 2014 17:41:07 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id my13so1609424bkb.36 for ; Tue, 08 Apr 2014 17:41: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=vccs9ueOPOrASzUaXGnWh97dyLopaYtYJzGrXn7uVIU=; b=mLwbU9x64cTwD9DsE2b5VnGNfEateXsQcOV/AK9AkIscKv2mMG608r1rPxvbkCSsI8 SN8WZK6d71jNJgCgbguATD9XSiuK59Uy3i4PJGbjp255qHptOQneVPIAfcEDsiEnj1sD ISm5nZl+QyGpqzxWWKayeIukV/T3pDtoh5t51qWU9eAXQblPdMErggjfiNT8Aod/Dubp Nfl99GlDFoOKSpGlKODLJDThWKyJpWNLFf+4EOao8p43os5Uy3HAuw3sqFauo1vDRlWL tjrZIlL8Wc/TT9UAG8LqSCv6f2iD0h+YvjuNTofT5v5aoRfZFH0/iBnPEFXV9SzL1+WA RumA== MIME-Version: 1.0 X-Received: by 10.152.87.71 with SMTP id v7mr5079747laz.10.1397004067329; Tue, 08 Apr 2014 17:41:07 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 8 Apr 2014 17:41:07 -0700 (PDT) In-Reply-To: References: <534320A2.5030208@comodo.com> <20140407224329.4A71F1ACAA@ld9781.wdf.sap.corp> <1396944418.11019.10.camel@dhcp-2-127.brq.redhat.com> Date: Tue, 8 Apr 2014 20:41:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZJgoAodJYFy9jh1Woqqy9i3P1Pw Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 00:41:12 -0000 On Tue, Apr 8, 2014 at 12:05 PM, Watson Ladd wrote: >> The requirement to mark the certificate critical enabled the NSA >> attack on Microsoft in the Flame malware attack. Marking the bit >> critical makes it impossible to issue a certificate with that >> extension as about half a billion deployed devices don't support name >> constraints. > > ?? Flame was a MD5 collision. Nothing saves you from that one. Had name constraints been deployable and deployed, the Microsoft CA that the NSA attacked could have been locked down to mitigate the consequences of a breach. >> The consensus model does not really work when a specification has been >> poisoned by an attacker who can block changes to correct the spec. >> Fortunately IETF specifications are not definitive, industry practice >> is. The industry consensus on this point is unanimous: name >> constraints need not be marked critical. > > Which makes them useless: the point of name constraints is that I can > issue a name constrained certificate without issuing a global > intermediate CA certificate. If the extension is not marked critical, > then I've issued a global intermediate CA certificate for those who > don't check it, and so need to be just as strict as if it was an > intermediate CA certificate, so I might as well not bother with the > constraint. Again, you don't get the idea that redundant controls have value. Even though I have full control over the signing key for a sub-ca, there is no reason for the sub-ca to have the power to issue any cert so why grant it? Least privilege is a powerful tool. The IETF had no business telling people they couldn't use it. You have no idea what my requirements or constraints are. So why presume to tell us what is or is not useful? The IETF was following an outdated mode of security thinking. One that is unfortunately very common in US government contractor circles. A MUST is only justified when there is a serious negative consequence from not following it. There is no serious consequence that follows from not marking a name constraint critical in the context in which it is now used in the industry. The clear industry consensus is that name constraints MAY be marked as non-critical. -- Website: http://hallambaker.com/ From nobody Tue Apr 8 17:53: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 419471A075A for ; Tue, 8 Apr 2014 17:53:51 -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 A5O7n9nL4t3f for ; Tue, 8 Apr 2014 17:53:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5211A0192 for ; Tue, 8 Apr 2014 17:53:49 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id E14E2F984; Tue, 8 Apr 2014 20:53:46 -0400 (EDT) Message-ID: <53449A18.9000803@fifthhorseman.net> Date: Tue, 08 Apr 2014 20:53:44 -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: Michael D'Errico References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> In-Reply-To: <53442983.1030703@pobox.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q1XAIIIf3EqmoSmftJwbuEjPluKesn4td" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8jGfKto0cjnkolMcBxAN4jQRjLw Cc: tls@ietf.org Subject: Re: [TLS] Negotiated Discrete Log DHE revision [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, 09 Apr 2014 00:53:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q1XAIIIf3EqmoSmftJwbuEjPluKesn4td Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/08/2014 12:53 PM, Michael D'Errico wrote: > There is already a list of DH groups managed by the IANA for IKE that w= as > established by RFC 2409 and includes the MODP groups from RFC 3526 plus= > others. Why not just use this existing registry and add your new e-bas= ed > groups to it? I tried to address this question in section 8.4 of the current draft: https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01#sectio= n-8.4 ----------------- 8.4. Choice of groups Other lists of named discrete log Diffie-Hellman groups [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for several reasons: Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group. The IKE groups include weak groups like MODP768 which are unacceptable for secure TLS traffic. Mixing group parameters across multiple implementations leaves open the possibility of some sort of cross-protocol attack. This shouldn't be relevant for ephemeral scenarios, and even with non- ephemeral keying, services shouldn't share keys; however, using different groups avoids these failure modes entirely. Other lists of named DL DHE groups are not collected in a single IANA registry, or are mixed with non-DL DHE groups, which makes them inconvenient for re-use in a TLS DHE key exchange context. ----------------- Do you find these arguments unconvincing, or do you have suggestions for how the text should be changed? --dkg --q1XAIIIf3EqmoSmftJwbuEjPluKesn4td 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/ iQJ8BAEBCgBmBQJTRJobXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcxSAP/3V/6iwoEMBnhdIrHByI52pR VSyi3VoQBBNl43nQwcP6VpwIvRBdYNQHjtPeGY5X6X9uKoGyKcak4a4wMs4fk9Tg +rsaJuVWkTxsnlcEghtTc+cxeoALGXHIFzQjQMAo15LF+9OZ5fzCVoDfQnDCJbNf VarNvKt2somxoBNZYt7OaLnWdCWMBbHPcU5AdYkTSjMw58gE84br29CHonIHA3U/ erpiLGTv9lSYRDD8E1EE7cMacNocQRjrKkvEc2HX+TiZktzBosEAw3F7zBoS0+xT WG50YNo2ftcmCocFdjNvPTrbKBUjOU01xv8+dvKVEDCkBLHng6fOLp7AOnXf3ZPh ynkUvJ9KubhJ/d4XJANNSTW/vjDk8ev8eEZ6CtWUWaLfwumaK6Ig340vQJHgFI7R ARg9VwfGgCbW2XZa+nLg8cYYoKunKvz2HuntJEQOZbwrTFXLRMQlbVcavq4+MBb0 w5UPohmAT9iDssj0E6NLWrPyUp1FIwFYAkFawCj14wCPnfhkbd6X6NtG1JTOCKPx nSfKi+OkKlQJJ/PppyJGPk09jysWhLEwn0MSc10Vb6FyWKbbgW6OGDn1YDbQJrqc LLNB1a5aosRDeXJniKqBp1LpXoCcbDZlzo57H865woNChRCCV5boPp+drBY4nevW HoVyWMu9dJnRzcdnWZhA =xXHC -----END PGP SIGNATURE----- --q1XAIIIf3EqmoSmftJwbuEjPluKesn4td-- From nobody Tue Apr 8 18:07: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 1F7CE1A0758 for ; Tue, 8 Apr 2014 18:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_m1yKT_q94z for ; Tue, 8 Apr 2014 18:07:50 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD251A0735 for ; Tue, 8 Apr 2014 18:07:50 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 23949F984; Tue, 8 Apr 2014 21:07:48 -0400 (EDT) Message-ID: <53449D64.8070806@fifthhorseman.net> Date: Tue, 08 Apr 2014 21:07:48 -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: henrick@streamsec.se, tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> <53443ADD.3040008@streamsec.se> In-Reply-To: <53443ADD.3040008@streamsec.se> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JuWhQ9knw7c1EpjdVTXeLvCTo3oksRqWa" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kQQ3T8gw-bW_pvNz7ZW7x2Dtq2s Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 01:07:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JuWhQ9knw7c1EpjdVTXeLvCTo3oksRqWa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/08/2014 02:07 PM, Henrick Hellstr=C3=B6m wrote: > However, e might be a less optimal choice for another reason, namely > that the next higher safe prime is relatively far away from the startin= g > points you get when you use e this way. For instance, in the case of th= e > 6144 bit prime, it is more than 2^33 steps away from the starting point= , > which means it will take a lot of time to verify the correctness of > these primes (once you found them). Have you done the calculations to derive the 6144-bit prime in this series? If so, are you willing to share your code? I confess i don't see why the safe primes should be farther for this construction than a similar construction with pi, but it certainly seems to be the case. Is there a reference that i should read to understand this better? --dkg --JuWhQ9knw7c1EpjdVTXeLvCTo3oksRqWa 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/ iQJ8BAEBCgBmBQJTRJ1kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc49wP/2gqPahWpHZLYgvg/Ikau9g2 uQuvDmGFIlYeQ9MRJTKPAgJpBZmKVfA/KqfaCF+Z47e5ywvztegtJ20JmJLuZwMS z1pYXZCuokAf3DykqSe03XPZ7UTUi5CLSjcqPa9P3RSlaZ5PhcXbaXxC6XjHkg7u tiGHCp1kLHF/aLqqBFLSvS8h5Ix6yBvWMNpZuAOd6P1MeRVPtIqUsG1y7faiPQ+J BDym0sQEzmLzhffUa8coM1rxYe8CvwQOgrdugXxFfur3xUq1w1xjIXGGAL/AwIge FHasIlKxNLdfbnN4xFoOeGECd/vMOE2ybfTBYlliwfy8Wm9Y1BSgiCtg2h5fNjUl TGNUMyKcA1lHRHU1GNBIW9DY8a7jU8w6yzg1hMbuWE8kViuSwogx7Oe5ztBt0Wbu TEdVdiCyg4DpYGaZ3NCjEr11y4Ma82KVYt3ozRZPH/pL75P4/TgcUr2072ecRaHw ijP6qzScH5e/+wJjY90cheCKYits/iZ6YqcspgsxrxR91PjXkqzvyiXXDYWcZCDY HimxQhXyr1jYG4hDKzI6JwXGfGqLHMldbSJFx2toMHDSSISpMUo+9GB1fUDC2bVw 61RUDpzVgCrRRZZXas+k1NefYeO7630zjHoU76x7px2Iu160vCnlTAk5GNnuYmRy jmwFYoOFcyJBkRXvb/r7 =ItGg -----END PGP SIGNATURE----- --JuWhQ9knw7c1EpjdVTXeLvCTo3oksRqWa-- From nobody Tue Apr 8 19:37: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 59CF91A079E for ; Tue, 8 Apr 2014 19:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtuSC2KKSzRS for ; Tue, 8 Apr 2014 19:37:02 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by ietfa.amsl.com (Postfix) with ESMTP id D4A451A005F for ; Tue, 8 Apr 2014 19:37:01 -0700 (PDT) Received: from [192.168.1.64] (bl16-207-18.dsl.telepac.pt [188.81.207.18]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id s392axOT007798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 9 Apr 2014 03:37:05 +0100 Message-ID: <5344B22F.5010903@dei.uc.pt> Date: Wed, 09 Apr 2014 03:36:31 +0100 From: Samuel Neves 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: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> <53443ADD.3040008@streamsec.se> <53449D64.8070806@fifthhorseman.net> In-Reply-To: <53449D64.8070806@fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080204090901040301000806" X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: s392axOT007798 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.15, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, HTML_MESSAGE 0.10, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lv5464zMe1CAInd-hEf0-tFmlsw Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 02:37:04 -0000 This is a multi-part message in MIME format. --------------080204090901040301000806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09-04-2014 02:07, Daniel Kahn Gillmor wrote: > > I confess i don't see why the safe primes should be farther for this > construction than a similar construction with pi, but it certainly seems > to be the case. Is there a reference that i should read to understand > this better? > It seems to be an unlucky choice. The probability that p is prime is roughly 1/log(p) by the Prime Number Theorem. Assuming independence, the probability that (p-1)/2 is also prime can be given by the same expression. Thus we can get a rough approximation of the number of integers to go through: log(p)^2. In the case of p ~ 2^6144, the expected iteration number is ~2^24. --------------080204090901040301000806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09-04-2014 02:07, Daniel Kahn Gillmor wrote:
>
> I confess i don't see why the safe primes should be farther for this
> construction than a similar construction with pi, but it certainly seems
> to be the case.  Is there a reference that i should read to understand
> this better?
>

It seems to be an unlucky choice. The probability that p is prime is roughly 1/log(p) by the Prime Number Theorem. Assuming independence, the probability that (p-1)/2 is also prime can be given by the same expression. Thus we can get a rough approximation of the number of integers to go through: log(p)^2. In the case of p ~ 2^6144, the expected iteration number is ~2^24.

--------------080204090901040301000806-- From nobody Tue Apr 8 20:24: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 11F1E1A0061 for ; Tue, 8 Apr 2014 20:24:46 -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 fFl64Vev2chl for ; Tue, 8 Apr 2014 20:24:44 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6551A0055 for ; Tue, 8 Apr 2014 20:24:44 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id B3D61F984 for ; Tue, 8 Apr 2014 23:24:42 -0400 (EDT) Message-ID: <5344BD77.2020106@fifthhorseman.net> Date: Tue, 08 Apr 2014 23:24: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: "tls@ietf.org" References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SL3SUphCQwcCF8JX1SJAq7IiXvomxjx2K" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JUJ17xhpwPGHcLvgbIMSnwknADM Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 03:24:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SL3SUphCQwcCF8JX1SJAq7IiXvomxjx2K Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/07/2014 10:55 AM, Watson Ladd wrote: > On Mon, Apr 7, 2014 at 2:51 AM, Simon Josefsson w= rote: >> To move the draft forward in the RFC process, we need find an AD to >> sponsor the draft or (I guess) the TLS WG to adopt it. >=20 > Does anyone object to the WG adopting it? I support WG adoption of draft-josefsson-tls-curve25519. --dkg --SL3SUphCQwcCF8JX1SJAq7IiXvomxjx2K 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/ iQJ8BAEBCgBmBQJTRL13XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+koP/1fMyZ8Z7m/G+zQEXCRsJtPk 80ovHrzl9b+e1uLUJ9m1O5pRDghxen2fDXNLWJPxW5LVETJvq513jhnIOAwO2ptR YnwsTviQ9/8wfheqve9F6O+QsB+1XZx8VPX4lsC8vW9xYmOvQLXQWG+fkt9nCkeu 5rDwffx7S4rSfRPjKJ48gP0eYpZjBQn7pqM4LymUvTCaLaADbMgXF8htv5AHgMih DeGlARtvRDC+SuuF5pYIW3XrXwbtpXOep+Cg4flVHRsdD61fIsfAAGVxI2TbgiAh xE0YV/nmkllOt5jqElAMlVP9+q8J7MJyyw0CYyLv5HEVDMymkPSiiVbKe2flyurg dVL6IwedleD40465/viItfW6LZlSC3lpyLEYliGNvNrxfQ6+f/u11EFN2niR1eyG JsVK+gRy/LQnLLGMZsEjUs4+a7dnsIU9ocB/w+Ec+gDjsMbrHbPleEy2lcrD/5+c Szl+589QBgwVS0QBXSJmPcgVXZEM9ToE6JU4gxdpyxsdjROHxYfVFkjLRL4uVlvE u7/ITzMXDGheGu7goP12oZzSRBJSfhCBXVtDuAxjJwnLVn3E/ifrP+jndnTBWOEd mUVNJ1+XZ6T6847O6RzbG5M96t3190vOgQwX/tmxWC/5vXgtYQVHxyIFyfSUWITM zTgVHPVecGuaPODjb3Yf =lYjT -----END PGP SIGNATURE----- --SL3SUphCQwcCF8JX1SJAq7IiXvomxjx2K-- From nobody Tue Apr 8 21:07: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 BFEF21A0089 for ; Tue, 8 Apr 2014 21:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta6rrdG7infp for ; Tue, 8 Apr 2014 21:07:18 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE1F1A0090 for ; Tue, 8 Apr 2014 21:07:17 -0700 (PDT) Received: from mail-bk0-f44.google.com ([209.85.214.44]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKU0THdZhugh1me8SOWkj0y/4XILjF+X1S@postini.com; Tue, 08 Apr 2014 21:07:17 PDT Received: by mail-bk0-f44.google.com with SMTP id mz13so1869212bkb.3 for ; Tue, 08 Apr 2014 21:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Ndt9hPQHPsep0CHEX5B8sC+1BAg1Xt5JHlbzcqodrw=; b=llBoifFnU+htUKlMfto/lTK+EvCUVGL7PPwcBD3DlcwKqxkWLlQs3RtC9esJQshZVL vStePKD95lfJEHL8qWl80yEpWgagLUBZpZB4dd5F24XNopvENjZYTRnTCCwRJkDIXe9U GgmvsYsPypSN/Uby8npHeiwxm6Tdfnfdyl3ec= 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=4Ndt9hPQHPsep0CHEX5B8sC+1BAg1Xt5JHlbzcqodrw=; b=jq055Vm/kREQgjPs5LqR2HL32QtA+D1CG7Pt+aehZIClNz1MywcEQe6V7RXpQRxq9L l5sG+f6zPLF8SntD4skuXEKjRjAuFE8TBRl7E9jqgFyTV29EA2pHtiQrNJHzw5CQuu1Y H4elGnkHcmghjuoVfHXD1vc4dGkrsmfgTwz+Gf6vvkyxGUJklXv6sVPSn4avAkYeCTYx H6xKXY5iz/z7A2Mk2aWr+U8SEqXjWrxMaIQN2+GyBg5PTEh6jaF70/hZWJLM/wGtL2fW Gfcjq3jnTcDcgvnA3XpSVwj3bvXWYoduK1vYlOZfgQ7YeTPsMay52vUqn9igRvJZpMf8 JRkA== X-Gm-Message-State: ALoCoQl3cCzTd6NwA0o/3IRNz/NubVoEUph75WVCW4DmM7zJmraUucPBCg4wdv1g0TRX7ciZM43l8uXjRjTJCL+C3pi/IwTjrePL5FD9ws0d7RUuahbOTEHEx26KUP1JJ9B4MhTgjKqX X-Received: by 10.112.119.208 with SMTP id kw16mr5340174lbb.19.1397016435940; Tue, 08 Apr 2014 21:07:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.119.208 with SMTP id kw16mr5340158lbb.19.1397016435737; Tue, 08 Apr 2014 21:07:15 -0700 (PDT) Received: by 10.112.83.166 with HTTP; Tue, 8 Apr 2014 21:07:15 -0700 (PDT) In-Reply-To: <3eea5a90ed4b766b00589e61c30d6137.squirrel@www.trepanning.net> References: <533BBC3C.6000704@gmx.net> <7a41ee191d22df1f5924a68034c74a49.squirrel@www.trepanning.net> <533C3D12.7040802@gmx.net> <3a1e30958a4e240be96d8a822a1fcdae.squirrel@www.trepanning.net> <397fd5afead8db2b71444a0ad36196b2.squirrel@www.trepanning.net> <3eea5a90ed4b766b00589e61c30d6137.squirrel@www.trepanning.net> Date: Wed, 9 Apr 2014 13:07:15 +0900 Message-ID: From: SeongHan Shin To: Dan Harkins Content-Type: multipart/alternative; boundary=047d7b873c0c65cea604f6943c05 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xmgaseQgea-UaTM-GWwumWXrDCE Cc: "tls@ietf.org" Subject: Re: [TLS] The PAKE question and PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 04:07:22 -0000 --047d7b873c0c65cea604f6943c05 Content-Type: text/plain; charset=ISO-8859-1 Dear all, >> Failing that, make AugPAKE work on ECC by grabbing the draft and fixing >> it, then submit that instead. > > You should stop telling people to do things you are unwilling to do >yourself. In the next version, I would include ECC version of AugPAKE. Best regards, Shin On Thu, Apr 3, 2014 at 3:52 AM, Dan Harkins wrote: > > On Wed, April 2, 2014 11:15 am, Watson Ladd wrote: > > On Apr 2, 2014 10:55 AM, "Dan Harkins" wrote: > >> > >> > >> On Wed, April 2, 2014 10:26 am, Nico Williams wrote: > >> > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins > > wrote: > >> >> EKE doesn't do RSA. And, as Nico pointed out, observing a single > >> >> exchange > >> >> can eliminate a large majority of the potential passwords. Even an > >> >> infrequent > >> >> use can give an adversary a high probability of successfully > > determining > >> >> the secret. > >> > > >> > But if you use Elligator then that problem goes away. That's the key > >> > point. > >> > >> Yes, as I mentioned back in December on this list, EKE with Elligator > >> would make a very good alternative to TLS-pwd. And if there was a mature > >> draft ready for publication that specified such a scheme it would be > >> worth > >> considering. But there isn't. And we're 2+ years away from having such a > >> thing. Probably more since we have not identified a stuckee willing to > >> edit it. > >> > >> As Cullen mentioned, the IETF is a volunteer organization and telling > >> people that they should go write a draft specifying your alternative to > >> their draft is not really productive. > >> > >> I have received and resolved comments on the draft dealing with > >> protection of the username from passive observers and on mitigating > >> side channel attacks. There is no technical problem with TLS-pwd and it > >> solves real problems right now. I see no reason why it should not ease > >> away from the curb (and out of its parked position). > > > > What about the complete absence of any positive security analysis? You've > > known this was going to be an issue since you invented Dragonfly. I feel > > completely uncompelled to be 'productive' at the expense of security. > > You're overstating things a bit. There is no formal proof but that > doesn't > mean there is a complete absence of any positive security analysis. > > Being uncompelled and upset at the lack of a formal proof are not > technical comments, they are just whines. > > > Quit fussing and whining about how hard it is to write drafts. You could > > have started with something provably secure and avoided wasting your > > efforts. > > "Quit fussing and whining" works both ways. You've been fussing and > whining since you joined this list and it might be a good time to quit. > > To be clear, I have not said that it is hard to write a draft, I said it > is time > consuming. And I already have a draft (and running code) that solves the > problems I have identified. I have no reason to volunteer to write another > draft to do something that you want and I don't think you can afford my > consulting rate. > > > Failing that, make AugPAKE work on ECC by grabbing the draft and fixing > > it, then submit that instead. > > You should stop telling people to do things you are unwilling to do > yourself. > > Dan. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- ------------------------------------------------------------------ SeongHan Shin Research Institute for Secure Systems (RISEC), National Institute of Advanced Industrial Science and Technology (AIST), Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan Tel : +81-29-861-2670/5284 Fax : +81-29-861-5285 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --047d7b873c0c65cea604f6943c05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

>> Failing that, make AugPAKE work = on ECC by grabbing the draft and fixing
>> it, then submit that instead.
>
>=A0 You should stop telling people to do things you are unwilling to do=
>yourself.

In the next version, I would include ECC version of AugPAKE.

<= /div>
Best regards,
Shin


On Thu, Apr 3, 2014 at 3:52 AM, Dan Harkins <dharkins@lounge.org&g= t; wrote:

On Wed, April 2, 2014 11:15 am, Watson Ladd wrote:
> On Apr 2, 2014 10:55 AM, "Dan Harkins" <dharkins@lounge.org> wrote:
>>
>>
>> On Wed, April 2, 2014 10:26 am, Nico Williams wrote:
>> > On Wed, Apr 2, 2014 at 12:18 PM, Dan Harkins <dharkins@lounge.org>
> wrote:
>> >> =A0 EKE doesn't do RSA. And, as Nico pointed out, obs= erving a single
>> >> exchange
>> >> can eliminate a large majority of the potential passwords= . Even an
>> >> infrequent
>> >> use can give an adversary a high probability of successfu= lly
> determining
>> >> the secret.
>> >
>> > But if you use Elligator then that problem goes away. =A0That= 's the key
>> > point.
>>
>> =A0 Yes, as I mentioned back in December on this list, EKE with El= ligator
>> would make a very good alternative to TLS-pwd. And if there was a = mature
>> draft ready for publication that specified such a scheme it would = be
>> worth
>> considering. But there isn't. And we're 2+ years away from= having such a
>> thing. Probably more since we have not identified a stuckee willin= g to
>> edit it.
>>
>> =A0 As Cullen mentioned, the IETF is a volunteer organization and = telling
>> people that they should go write a draft specifying your alternati= ve to
>> their draft is not really productive.
>>
>> =A0 I have received and resolved comments on the draft dealing wit= h
>> protection of the username from passive observers and on mitigatin= g
>> side channel attacks. There is no technical problem with TLS-pwd a= nd it
>> solves real problems right now. I see no reason why it should not = ease
>> away from the curb (and out of its parked position).
>
> What about the complete absence of any positive security analysis? You= 've
> known this was going to be an issue since you invented Dragonfly. I fe= el
> completely uncompelled to be 'productive' at the expense of se= curity.

=A0 You're overstating things a bit. There is no formal pro= of but that doesn't
mean there is a complete absence of any positive security analysis.

=A0 Being uncompelled and upset at the lack of a formal proof are not
technical comments, they are just whines.

> Quit fussing and whining about how hard it is to write drafts. You cou= ld
> have started with something provably secure and avoided wasting your > efforts.

=A0 "Quit fussing and whining" works both ways. You've = been fussing and
whining since you joined this list and it might be a good time to quit.

=A0 To be clear, I have not said that it is hard to write a draft, I said i= t
is time
consuming. And I already have a draft (and running code) that solves the problems I have identified. I have no reason to volunteer to write another<= br> draft to do something that you want and I don't think you can afford my=
consulting rate.

> Failing that, make AugPAKE work on ECC by grabbing the draft and fixin= g
> it, then submit that instead.

=A0 You should stop telling people to do things you are unwilling to = do
yourself.

=A0 Dan.



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



--
---------------------------------------------= ---------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC)= ,
National Institute of Advanced Industrial Science and Technology (AIST= ),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan= .shin@aist.go.jp
------------------------------------------------------------------
--047d7b873c0c65cea604f6943c05-- From nobody Tue Apr 8 22:07: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 7B7991A00E1 for ; Tue, 8 Apr 2014 22:07:14 -0700 (PDT) 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_05=-0.5, 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 QH_r9wyxi_hc for ; Tue, 8 Apr 2014 22:07:10 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5C1A00BC for ; Tue, 8 Apr 2014 22:07:09 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id z6so1887491yhz.36 for ; Tue, 08 Apr 2014 22:07: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:content-transfer-encoding; bh=EpqDrax/+5FSMsOQ7vw0dNSHlkRqG4b1bq/JYtqk1r4=; b=kKNp2o4aZ1qGzfHdJFCQtiwsMpF+FXvpuV+XuFJAA2OspZrJAY8KKih9e51yr7t5wv Dj0OuoNeEBSsQxpbowD8gjfuTa2dB8gNNJ5I8mrev9dNYfQ2cSwBuJYKt6lcWPECnClK 8fuxYKOsGk0naBvz4T2QX9kT1FlQ6nd4+C0MGxY8KZl2zd3E4g5zUZRdAwwm/TyspbI+ Rk7cKuQA+Y1cbtEUbTs2ZlLUAGADCoMIcYFYHHq982RKxiAy6wU/t9f4n9Cz8dJc8nwy rSmJZ/aSPIPq12GckIo48X1AALjB4FERf0fhBazVk8y1fD4yLHxpGDVO2x8//Zs70U71 IswA== MIME-Version: 1.0 X-Received: by 10.236.230.41 with SMTP id i39mr11748421yhq.14.1397020029208; Tue, 08 Apr 2014 22:07:09 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 8 Apr 2014 22:07:09 -0700 (PDT) In-Reply-To: <5344B22F.5010903@dei.uc.pt> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> <53443ADD.3040008@streamsec.se> <53449D64.8070806@fifthhorseman.net> <5344B22F.5010903@dei.uc.pt> Date: Tue, 8 Apr 2014 22:07:09 -0700 Message-ID: From: Watson Ladd To: Samuel Neves Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PNu7MSdXi_UafCcK7eSWhI11uv0 Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 05:07:14 -0000 On Tue, Apr 8, 2014 at 7:36 PM, Samuel Neves wrote: > On 09-04-2014 02:07, Daniel Kahn Gillmor wrote: >> >> I confess i don't see why the safe primes should be farther for this >> construction than a similar construction with pi, but it certainly seems >> to be the case. Is there a reference that i should read to understand >> this better? >> > > It seems to be an unlucky choice. The probability that p is prime is roug= hly > 1/log(p) by the Prime Number Theorem. Assuming independence, the probabil= ity > that (p-1)/2 is also prime can be given by the same expression. Thus we c= an > get a rough approximation of the number of integers to go through: log(p)= ^2. > In the case of p ~ 2^6144, the expected iteration number is ~2^24. I don't see why e inherently has this property. Granted this is probably deep (and nobody at Berkeley does this, so I have no clue), although it is worth noting that the bounds on pi(x) are quite weak in comparison to the asymptotics. (It could of course be a quirk of small numbers). Burn enough computer time and generation will stop. Once it does validation (not of minimality) is fairly quick, and we can make a certificate to enable fast ECPP checking. Minimality certification is tough: even safecurves.cr.yp.to doesn't do it. If you give up and want another transcendental constant, \zeta(3) (Ap=C3=A9ry's constant) could be worth a look. So could \e^{\pi}. Logs of small integers could also work. Alternatively we could use the precomputed groups for the larger orders: the damage from shared factor bases is most acute when the group size is close to breakable. 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 Apr 9 03:51: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 CD7221A0217 for ; Wed, 9 Apr 2014 03:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9qc78wpqDrg for ; Wed, 9 Apr 2014 03:51:22 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6F1A01FA for ; Wed, 9 Apr 2014 03:51:21 -0700 (PDT) Received: from [194.210.172.187] ([194.210.172.187]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id s39ApGvt024859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2014 11:51:22 +0100 Message-ID: <53452609.9040304@dei.uc.pt> Date: Wed, 09 Apr 2014 11:50:49 +0100 From: Samuel Neves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Watson Ladd References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> <53443ADD.3040008@streamsec.se> <53449D64.8070806@fifthhorseman.net> <5344B22F.5010903@dei.uc.pt> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: s39ApGvt024859 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qvqGqPWDxd3205hE3YPP00uAaC8 Cc: "tls@ietf.org" Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:51:27 -0000 On 09-04-2014 06:07, Watson Ladd wrote: > On Tue, Apr 8, 2014 at 7:36 PM, Samuel Neves wrote: >> On 09-04-2014 02:07, Daniel Kahn Gillmor wrote: >>> I confess i don't see why the safe primes should be farther for this >>> construction than a similar construction with pi, but it certainly seems >>> to be the case. Is there a reference that i should read to understand >>> this better? >>> >> It seems to be an unlucky choice. The probability that p is prime is roughly >> 1/log(p) by the Prime Number Theorem. Assuming independence, the probability >> that (p-1)/2 is also prime can be given by the same expression. Thus we can >> get a rough approximation of the number of integers to go through: log(p)^2. >> In the case of p ~ 2^6144, the expected iteration number is ~2^24. > I don't see why e inherently has this property. Granted this is > probably deep (and nobody at Berkeley does this, so I have no clue), > although it is worth noting that the bounds on pi(x) are quite weak in > comparison to the asymptotics. (It could of course be a quirk of small > numbers). Sorry, I was not clear. I was not associating any particular property with e; any choice of constant will have roughly the same expected ~2^24 attempts. That e happens to require more is a statistical accident. From nobody Wed Apr 9 03:57: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 290321A01D1 for ; Wed, 9 Apr 2014 03:57: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 6Lquue65ZWPM for ; Wed, 9 Apr 2014 03:57:35 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFBB1A01EA for ; Wed, 9 Apr 2014 03:57:34 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id w7so999046lbi.16 for ; Wed, 09 Apr 2014 03:57: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=vLu+noB/wW5ZlZyZm+OodmaApNIi1k4sdWdRmpIsvf8=; b=rxnt1O6A3Hx+XwFRT75ahXR78fNYRVzvunzqQ78Eez5HTDhdTFHklKpmic3xRByB4n K8LnWXWxTi05xeHBvDLIQKPQ07vMDUWCG67kZClwRAsbXXkxWm/sGVlzzEB4q5+2wJeE CopcTBTyUhVtIY/9NZzsOKzFJVmU9+c4ysOJXfba5ZF7VB2EwH7NqtpPg4dfKJYGnEhx V4XWn+iNz91+AgUqFfazW+fH3SHcbYDdpKugmHaRRQhf3LT62X/W8rMkdg5rfhiQu2Nt DTAaCJtqTu3GbGqabi3RjidevNB+i3GEADgJMXbcAXEDRFYNvLqufXGYL9giEij7GvrC 49UA== MIME-Version: 1.0 X-Received: by 10.112.139.166 with SMTP id qz6mr6669106lbb.13.1397041053764; Wed, 09 Apr 2014 03:57:33 -0700 (PDT) Received: by 10.152.18.133 with HTTP; Wed, 9 Apr 2014 03:57:33 -0700 (PDT) Received: by 10.152.18.133 with HTTP; Wed, 9 Apr 2014 03:57:33 -0700 (PDT) In-Reply-To: <5344303C.2050607@pobox.com> References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <5344303C.2050607@pobox.com> Date: Wed, 9 Apr 2014 03:57:33 -0700 Message-ID: From: Liz meeks To: "Michael D'Errico" Content-Type: multipart/alternative; boundary=001a11c26692bf11e304f699f74e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X4bw6KtYO45pHgXwC9QHv1vp420 Cc: tls@ietf.org Subject: Re: [TLS] Negotiated Discrete Log DHE revision X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 10:57:40 -0000 --001a11c26692bf11e304f699f74e Content-Type: text/plain; charset=ISO-8859-1 Stop sending me these msgs On Apr 8, 2014 10:22 AM, "Michael D'Errico" wrote: > Also, I'm curious why "e" is chosen for constructing these primes. Since > the natural log of e is 1, doesn't it seem like a bad idea to stick a bunch > of bits of e in a prime where the security is based on logarithms? > > Mike > > > > Michael D'Errico wrote: > >> There is already a list of DH groups managed by the IANA for IKE that was >> established by RFC 2409 and includes the MODP groups from RFC 3526 plus >> others. Why not just use this existing registry and add your new e-based >> groups to it? >> >> Mike >> >> >> >> Daniel Kahn Gillmor wrote: >> >>> On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor < >>> dkg@fifthhorseman.net> wrote: >>> >>>> 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 >>>> >>> >>> Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, >>> i've updated the named groups in the above draft. >>> >>> I've also done another pass over the text: >>> >>> https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 >>> >>> Comments, questions and critiques welcome. >>> >>> --dkg >>> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c26692bf11e304f699f74e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Stop sending me these msgs

On Apr 8, 2014 10:22 AM, "Michael D'Err= ico" <mike-list@pobox.com> wrote:
Also, I'm curious why "e" is chosen for constructing these pr= imes. =A0Since
the natural log of e is 1, doesn't it seem like a bad idea to stick a b= unch
of bits of e in a prime where the security is based on logarithms?

Mike



Michael D'Errico wrote:
There is already a list of DH groups managed by the IANA for IKE that was established by RFC 2409 and includes the MODP groups from RFC 3526 plus
others. =A0Why not just use this existing registry and add your new e-based=
groups to it?

Mike



Daniel Kahn Gillmor wrote:
On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wro= te:
I've submitted an initial stab at a proposal for negotiated discrete lo= g
diffie-hellman ciphersuites:

=A0http://tools.ietf.org/html/draft-gillmor-tls= -negotiated-dl-dhe-00

Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG,
i've updated the named groups in the above draft.

I've also done another pass over the text:

=A0 https://tools.ietf.org/html/draft-gillmor-= tls-negotiated-dl-dhe-01

Comments, questions and critiques welcome.

=A0 =A0 --dkg

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--001a11c26692bf11e304f699f74e-- From nobody Wed Apr 9 04:37: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 706A01A00E6 for ; Wed, 9 Apr 2014 04:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm0G1EL97WkA for ; Wed, 9 Apr 2014 04:37:33 -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 A73E21A0214 for ; Wed, 9 Apr 2014 04:37:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 137F928593; Wed, 9 Apr 2014 11:37:32 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 01C932858F; Wed, 9 Apr 2014 11:37:32 +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 F1C7A80040; Wed, 9 Apr 2014 11:37:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 9 Apr 2014 07:37:31 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , "tls@ietf.org" Date: Wed, 9 Apr 2014 07:37:31 -0400 Thread-Topic: [TLS] Curve25519 in TLS and Additional Curves in TLS Thread-Index: Ac9To2iSNpWniFYTQEiOX1dgfZFQLQARJolQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> In-Reply-To: <5344BD77.2020106@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/nSbpkbv9Wq1KJq6_EeXCyZVmeD4 Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 11:37:35 -0000 SSBzdXBwb3J0IGl0IHRvLCBidXQgSSB3YW50IHRvIHNlZSBpdCBpbiBsaXR0bGUtZW5kaWFuIGZv cm1hdCwgd2hpY2ggcmVxdWlyZXMgYSBiaXQgbW9yZSBjb29yZGluYXRpb24gYmVmb3JlIGl0IGNv dWxkIGJlIHB1Ymxpc2hlZC4NCg0KCS9yJA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5n aW5lZXINCkFrYW1haSBUZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoNCg== From nobody Wed Apr 9 04:50: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 B57FF1A0234 for ; Wed, 9 Apr 2014 04:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 ngCXuttY_XdC for ; Wed, 9 Apr 2014 04:50:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 49B911A021C for ; Wed, 9 Apr 2014 04:50:38 -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 s39BoYgL001123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Apr 2014 07:50:35 -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 s39BoVQN020094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2014 07:50:32 -0400 Message-ID: <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Wed, 09 Apr 2014 13:50:31 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@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.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gzjcCE6Uiu7nMuAgIW-Tam47e38 Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 11:50:39 -0000 On Wed, 2014-04-09 at 07:37 -0400, Salz, Rich wrote: > I support it to, but I want to see it in little-endian format, which requires a bit more coordination before it could be published. I believe you have already made your point several times. I think it is important to see comments from people who plan or work on implementing this draft, how each format affects them and whether there is a need for little-endian. regards, Nikos From nobody Wed Apr 9 05:17: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 08F881A027E for ; Wed, 9 Apr 2014 05:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-eUwyA31hbr for ; Wed, 9 Apr 2014 05:17:54 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 54A081A020A for ; Wed, 9 Apr 2014 05:17:54 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Wed, 09 Apr 2014 13:17:47 +0100 To: tls@ietf.org Message-ID: <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CJLtl_iG2nNcGnNobv-y9Yiz53E Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 12:17:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 9 April 2014 12:50:31 BST, Nikos Mavrogiannopoulos wrote: >I believe you have already made your point several times. I think it is >important to see comments from people who plan or work on implementing >this draft, how each format affects them and whether there is a need >for >little-endian. Don't we already seem to have consensus on little-endian, and that is what will be in the revised draft-04? Was the revised draft not what we're talking about? Sorry if I'm misunderstanding. [The significant fallout from the "Heartbleed" bug may be causing a little more disruption at present than is normally typical.] Subject to that (see the previous comments in my summary), I have no objections to the WG adopting the revised draft -04 with the amendments discussed (as little-endian). As previously stated, implementation of the draft is notably simplified by using the native little-endian format already used by all implementations of curve25519. (As everyone will no doubt have fresh in their mind, the simpler an implementation is able to be, the less likely it is to have nasty bugs, in general at least.) - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTRTpqGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6FdoQAIOt8sBgtiErMNtMURiYN3kuw7yvij1mvzumrx0vqp2mCSQ0MULm qY3Z3bS9EDQ0u52dAnh6SFfm1sq7BKOzvJzJ9t2FObapAwdS1eHuu36bIqNZTnKK iKwal/HrKt6++MkloP9GWrlz/AHBMSdn0GdSsaES1qoFSABadlzsGOW5REEqURE4 h1nLzTMoqUiAEtxuMqfdnauCv7oCF3qOsGhMgQZZXjhrHLzFVcdYFWYVqNgTIigH n9H/JZNMqkNruVpZRSUCkeOhEuMxifsLFzXUnB2RCLepZajP37LQSySvqg5Yrhs/ ust13YiIV7ngCfgkdJFhQSQp6sja8BTRtICchvbD7sp/hSx+ALP2Zi3vDCwYFmo8 FYnf1rtdGcBNt9BtIUPUEZGd2f5bkICLv7O/VzLCu2FT0sy7ZyPrCM8A8Lgv8pIH 9rggsRK923kmN/hm7EPoljwpltX0+F20uEDzne96ZrWqQMSAXnvyd123yW+O+5e0 6RtrlSOAyve9zovv/jU/SqZ22hEzXHyNmpi69E56RJYgf4wS7+nbSzuP/LHzCsg/ meAfoMQ9LylL1tMc8UBaDqdVHZ8F5QYtbDSuVy105gpENmCVSmvIHIpabzr0YrN0 heBuQBUV1efa28+pG2z8Zuc0/B6PQouU7Q+z5YVsGl9Tk1I7BRFDa03o =QS0o -----END PGP SIGNATURE----- From nobody Wed Apr 9 05:44: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 1D4E91A019E for ; Wed, 9 Apr 2014 05:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 DGATNpeZPCRX for ; Wed, 9 Apr 2014 05:44:40 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 900C11A0136 for ; Wed, 9 Apr 2014 05:44:40 -0700 (PDT) X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (tor.nordsupport.com [81.7.8.11]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id E57518B for ; Wed, 9 Apr 2014 14:44:31 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk E57518B 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: <534540AC.9070404@azet.sk> Date: Wed, 09 Apr 2014 14:44:28 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> In-Reply-To: <87eh18xtrl.fsf@alice.fifthhorseman.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vj1jDx1HpkpHTreSB0hbQtjcHnnOCkrkH" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OLMEVASZu78axHMu8aLI7AjJbGQ Subject: Re: [TLS] Negotiated Discrete Log DHE revision [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, 09 Apr 2014 12:44:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vj1jDx1HpkpHTreSB0hbQtjcHnnOCkrkH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are you refering to Java TLS clients in section 1. Introduction ? " Some widely-distributed TLS clients are not capable of DH groups where p > 1024. " This limitation has been fixed in Java 8 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=3D7044060 https://stackoverflow.com/questions/6851461/java-why-does-ssl-handshake-g= ive-could-not-generate-dh-keypair-exception Fedor On 08.04.2014 07:41, Daniel Kahn Gillmor wrote: > On Fri 2014-03-28 21:33:39 -0400, Daniel Kahn Gillmor wrote: >> I've submitted an initial stab at a proposal for negotiated discrete l= og >> diffie-hellman ciphersuites: >> >> http://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 > Thanks to feedback from Watson Ladd and Samuel Neves over on the CFRG, > i've updated the named groups in the above draft. > > I've also done another pass over the text: > > https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-01 > > Comments, questions and critiques welcome. > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --vj1jDx1HpkpHTreSB0hbQtjcHnnOCkrkH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTRUCsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOt0bUP/0LLRO3AtrMxK4bK3/PlqLv/ tU4OHF/pnOul0+8E4zIDFA5h7PehcnZmL1Bi7hSpzeiCll9SPOnuv+XlLWfEaWO6 QvgJPXbm0TKl2SV9jtketrkeWPd4wmFKp+yVytaa3ZxHvdwvDJl7EQMgIBzEkle6 oYzKgL4UotToYVvN7lanNltrqToQFlIpPjlrO6cpG4Nr3aR6G9nhfwTsDZ2gvYxb 9XpaTxW9srgHES5Deul+fIsu6l4zeKcLWSUuDAlwxUOE7TD/t6DOTa2OHoagDFFl 5TKbVhlmu3JOaI6VE0XTVq5UPg+/XABTlVreqGXtrZ5XqWuSp8U0Hga4rbcqxzBh Zz3CLffIOTUTOHbJhLKI59a/uUlOsvRRd8+JhO+SbMD6rlSsIoxvyt640lcT1hSc yrdcWULrVJWIDEJo5LMEwnAVtA1JK4SsqowdHh73ZpE7Gt16wxYNQXzFSfFYQj2k v1KWjmJHyLWTs4ULKy3ZBKofeGMif8oSjI/Ap8OheQBOOlSbo9e0Oi8kN5lvyqyV iwUksF/4JK/Ir10CW0g4yM6rfV6gw87O3pZt1HHEl3pxER8I/oceiFJvOilWFJED NiX08B0a5jDfaSv5jAK8iQgdT8seqRv4RBoYGnGcEV8rZpNfXxr7VcdMIs08Digm 2syIoYmJHvjwFLHDw70K =YIAs -----END PGP SIGNATURE----- --vj1jDx1HpkpHTreSB0hbQtjcHnnOCkrkH-- From nobody Wed Apr 9 06:01: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 1EDBC1A02A4 for ; Wed, 9 Apr 2014 06:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 qa4xYCOl9Qhg for ; Wed, 9 Apr 2014 06:01:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id BF9DC1A02A1 for ; Wed, 9 Apr 2014 06:01:07 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s39D10i2025259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Apr 2014 09:01:01 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s39D0vEe009303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Apr 2014 09:00:59 -0400 Message-ID: <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Alyssa Rowan Date: Wed, 09 Apr 2014 15:00:57 +0200 In-Reply-To: <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b72Qj2iA1oU2MZDMB7Vffudi7pM Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 13:01:09 -0000 On Wed, 2014-04-09 at 13:17 +0100, Alyssa Rowan wrote: > >I believe you have already made your point several times. I think it is > >important to see comments from people who plan or work on implementing > >this draft, how each format affects them and whether there is a need > >for > >little-endian. > Don't we already seem to have consensus on little-endian, and that is what will be in the revised draft-04? I believe that you summarized the issue very nicely in a previous e-mail, but my reading of having a consensus for little-endian is different than yours. As far as I am concerned, I do not see why an implementation which will not use the existing code, must treat the endianness of points from curve25519 differently than the points of any other curve in TLS. In any case, the arguments are already presented and that's what I mentioned to Rich. I think we need more input from other people who plan or are already implementing this curve in TLS. regards, Nikos From nobody Wed Apr 9 07:15: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 B84F71A0318 for ; Wed, 9 Apr 2014 07:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rThgXojXUCjs for ; Wed, 9 Apr 2014 07:15:13 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5A1A031B for ; Wed, 9 Apr 2014 07:15:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,826,1389762000"; d="scan'208";a="2571314" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 09 Apr 2014 10:15:12 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 9 Apr 2014 10:15:12 -0400 From: Santosh Chokhani To: Nico Williams Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: AQHPUG9nRS10t5Ha0EyLKsoi0FgTh5sG4JsA///FM+CAAE2tgIABHNfAgABNPYCAAPmJEA== Date: Wed, 9 Apr 2014 14:15:11 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E81139179393@scygexch10.cygnacom.com> References: <4262AC0DB9856847A2D00EF817E811391789E8@scygexch10.cygnacom.com> <20140407213051.8B5E11ACAA@ld9781.wdf.sap.corp> <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vADIKYc4oRRe_j3OLwWX5B7_lcI Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 14:15:17 -0000 TmljbywNCg0KQXMgZmFyIGFzIENOIGlzIGNvbmNlcm5lZCwgYXNzdW1pbmcgdGhhdCB0aGUgcGF0 aCB2YWxpZGF0aW9uIGVuZ2luZSByZXNpZGVzIGluIGEgbG93ZXIgbGF5ZXIgaW4gdGhlIHNvZnR3 YXJlIHN0YWNrIGFuZCBzZXJ2aWNlcyBhIHZhcmlldHkgb2YgcHJvdG9jb2xzIGFuZCBhcHBsaWNh dGlvbnMsIGl0IHdvdWxkIG5vdCBtYWtlIHNlbnNlIGZvciBSRkMgNTI4MCB0byBzcGVjaWZ5IHRo aXMuICBCdXQsIGluIG9yZGVyIHRvIGZhY2lsaXRhdGUgd2hhdCB5b3UgYXJlIHNheWluZywgSSBh bSBhbiBhZHZvY2F0ZSBvZiBvdXRwdXR0aW5nIHRoZSBzdGF0ZSBvZiB0aGUgbmFtZSBjb25zdHJh aW50cyBhcyBwYXJ0IG9mIFNlY3Rpb24gNi4xLjYgb2YgUkZDIDUyODAuICBUaGlzIHdvdWxkIGNv bnNpc3Qgb2YgcGVybWl0dGVkIHN1YnRyZWVzIHNldHMgYW5kIGV4Y2x1ZGVkIHN1YnRyZWVzIHNl dHMuICBUaGlzIG91dHB1dCB3aWxsIGFsbG93IGhpZ2hlciBsYXllciBwcm90b2NvbHMgYW5kIGFw cGxpY2F0aW9ucyB0byBwZXJmb3JtIG5hbWUgY29uc3RyYWludHMgb24gQ04uICBGb3IgZXhhbXBs ZSwgUy9NSU1FIGFwcGxpY2F0aW9uIGNhbiB2ZXJpZnkgaWYgdGhlIGUtbWFpbCBhZGRyZXNzIGlu IHRoZSBDTiBwYXNzZXMgbmFtZSBjb25zdHJhaW50cy4NCg0KQnkgeW91ciBzZWNvbmQgcGFydCwg SSBhc3N1bWUgeW91IG1lYW4gd2hlbiB0aGUgRE4gY29udGFpbnMgZG9tYWluQ29tcG9ubmVudCBh dHRyaWJ1dGVzLiAgU2VjdGlvbiA0LjEuMi40IG9mIDUyODAgc2F5cyB0aGVzZSBhcmUgbm90IHJl cXVpcmVkIHRvIGJlIGNvbnZlcnRlZCB0byBETlMgbmFtZXMuICBUaHVzLCBvbmUgbmVlZCBub3Qg YXBwbHkgRE5TIGJhc2VkIG5hbWUgY29uc3RyYWludHMgdG8gc3VjaCBETi4gIEkgY2FuIHNlZSB3 aGVuIHRoZSBETiBoYXMgYSBtaXggb2YgYXR0cmlidXRlcyB0aGlzIGxlYWRpbmcgdG8gcHJvYmxl bXMuICBJdCBpcyBiZXR0ZXIgdG8gcHJvdmlkZSBndWlkYW5jZSB0byB0aGUgQ0FzIHRvIGFzc2Vy dCB0aGUgY29ycmVzcG9uZGluZyBuYW1lcyBhcyBETlMgbmFtZSBhcyB3ZWxsLiAgQlRXLCBhbnl0 aGluZyBvbmUgZG9lcyBpbiB0aGlzIGFyZWEgc2hvdWxkIGJlIGFwcGxpZWQgdW5pZm9ybWx5IHRv IHRoZSBTdWJqZWN0IEROIG9yIEROIGluIFNBTi4gIEkgYWxzbyBkaWQgbm90IHNlZSB0aGUgZGlz Y3Vzc2lvbiBvZiB0aGlzIGluIFJGQyA2MTI1LiAgTWF5IGJlIEkgbWlzc2VkIGl0IG9yIHlvdSBt ZWFudCBzb21ldGhpbmcgZWxzZSBhbHRvZ2V0aGVyLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogTmljbyBXaWxsaWFtcyBbbWFpbHRvOm5pY29AY3J5cHRvbmVjdG9yLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwOCwgMjAxNCAzOjA3IFBNDQpUbzogU2FudG9zaCBDaG9r aGFuaQ0KQ2M6IG1yZXhAc2FwLmNvbTsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10g Q2VydGlmaWNhdGUgdmFsaWRhdGlvbiBjYW4gb2Ygd29ybXMNCg0KT24gVHVlLCBBcHIgOCwgMjAx NCBhdCAxOjQwIFBNLCBTYW50b3NoIENob2toYW5pIDxTQ2hva2hhbmlAY3lnbmFjb20uY29tPiB3 cm90ZToNCg0KSSBhZ3JlZSB3aXRoIHdoYXQgeW91IHNheSwgYnV0IHRoZXJlIGlzIG9uZSBhcmVh IHdoZXJlIEkgdGhpbmsgbmFtZSBjb25zdHJhaW50cyBjb3VsZCBiZSBpbXByb3ZlZDogd2hlbiBh IGNlcnRpZmljYXRlIGhhcyBubyBzdWJqZWN0QWx0ZXJuYXRpdmVOYW1lcywgb3Igb25seSBkaXJl Y3RvcnlOYW1lcyB3aGVuIGl0IGRvZXMsIGFuZCB0aG9zZSBuYW1lcyBhcmUgUkZDNjEyNS1zdHls ZSwgdGhlbiBpZiB0aGUgQ0EgY2VydHMgaW4gdGhlIHZhbGlkYXRpb24gcGF0aCBoYXZlIGROU05h bWUgbmFtZSBjb25zdHJhaW50cyB0aGVuIHRob3NlIHNob3VsZCBiZSBhcHBsaWVkIHRvIHRoZSBD TiBSRE5zIG9mIHRoZSBzdWJqZWN0TmFtZSBhbmQvb3IgZGlybmFtZSBTQU5zIHRoYXQgYmVhciB0 aGUgZG9tYWlubmFtZXMuICBUbyBteSBrbm93bGVkZ2UgdGhpcyBpc24ndCBjb2RpZmllZCwgYnV0 IGNvcnJlY3QgbWUgaWYgSSdtIHdyb25nLg0KDQpOaWNvDQotLQ0K From nobody Wed Apr 9 08:00: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 B43641A034A for ; Wed, 9 Apr 2014 08:00:43 -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 fUK5z5OO7uT1 for ; Wed, 9 Apr 2014 08:00:41 -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 1C5B11A02AA for ; Wed, 9 Apr 2014 08:00:41 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so2263962ykb.2 for ; Wed, 09 Apr 2014 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MHSXUq95KrTzR2ypoVU2MKUvPxQM4Do+cATuhkrjF7s=; b=G8E6lwFNM7WX4QXHF/QMYzXcTSXzpHe6tpqsaSMjLyeXcqxn7JmWsNVZ+eoBHQP32l MZmff5zqdodcSrpK8AELKYKcc4YK7E3MegarHwZDk1M5N0oYDthSrVKbRM2vHjhuAHdO /oGDseUQJkFNAIBU/F/uSNjzaXiloyU6/rn742oqUHa0QOC+Km7gr08ZvzOi8Y/NJ2B0 TNaspdfMsrC6Vwpf05OoVV00A8HfSwmhGEdUUJ7CkiRvj8xcqC+LNi5LE5sqTcmMnaGM nGX70u+ykbugpO0L3T04lq1QYMChL3X6OSAzj2og3jUbNRyY20YrkdApe0kge3XoPKij n5dQ== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr330468yhn.139.1397055640466; Wed, 09 Apr 2014 08:00:40 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 9 Apr 2014 08:00:40 -0700 (PDT) In-Reply-To: <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> Date: Wed, 9 Apr 2014 08:00:40 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G437jXUN6RrumZgZWooWixc3GxQ Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 15:00:43 -0000 On Wed, Apr 9, 2014 at 6:00 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-04-09 at 13:17 +0100, Alyssa Rowan wrote: > >> >I believe you have already made your point several times. I think it is >> >important to see comments from people who plan or work on implementing >> >this draft, how each format affects them and whether there is a need >> >for >> >little-endian. >> Don't we already seem to have consensus on little-endian, and that is what will be in the revised draft-04? > > I believe that you summarized the issue very nicely in a previous > e-mail, but my reading of having a consensus for little-endian is > different than yours. > > As far as I am concerned, I do not see why an implementation which will > not use the existing code, must treat the endianness of points from > curve25519 differently than the points of any other curve in TLS. In any > case, the arguments are already presented and that's what I mentioned to > Rich. I think we need more input from other people who plan or are > already implementing this curve in TLS. Your code should not use the bignum library you already have. It should call into libnacl or the guts that are in libsodium, both quite liberally licensed. This is because DJB writes and distributes perfect code, and you do not. Your bignum implementation has data-dependent branches and so leaks information to an attacker on the same hardware, as well as taking different times depending on branch state. If particularly bad, you have data dependent loops in reduction modulo a prime. libnacl avoids all these problems. In fact, because you are the GnuTLS developer, I know exactly what your bignum library, gmp does. And it isn't pretty: operations can take different paths depending on argument size, which includes lopping off zero limbs. Modulo is computed by division, which involves an instruction that is notoriously variable-time on many architectures. Your bignum implementation is also slow. This is because it has to permit arbitrary chains of addition between multiplications, which don't happen in ECC. As a result it needs to reduce each sum, which is unnecessary and slow. The libnacl implementations defer this reduction until the end, and partially reduce products for additional speed, taking advantage of the prime. The gap between the implementation you will write, and the implementation you can just use, in security, speed, and safety, is enormous. If you do decide to persist in this folly, reversing the bytes won't stop you, sadly. But I wish it could. Sincerely, Watson Ladd > > regards, > Nikos > > > _______________________________________________ > 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 Apr 9 08:01: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 5BEF51A0383 for ; Wed, 9 Apr 2014 08:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA41dSuLjrL4 for ; Wed, 9 Apr 2014 08:01:38 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id DAF0C1A0390 for ; Wed, 9 Apr 2014 08:01:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,826,1389762000"; d="scan'208";a="2572120" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 09 Apr 2014 11:01:35 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 9 Apr 2014 11:01:34 -0400 From: Santosh Chokhani To: "mrex@sap.com" Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: Ac9UBI7wP8Z5efIqQg2ahHeBtf2x5A== Date: Wed, 9 Apr 2014 15:01:33 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113917947B@scygexch10.cygnacom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.117.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/ZnkwGoh5C4Wji8mJMCor5ELVchY Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 15:01:42 -0000 Martin, TLS probably is not a good forum to have this debate. It seems like PKIX d= iscussion. We should drop it. Here are my final comments on it. On EKU, while the RFC may not say it, it seems to be a proper thing to do a= nd the RFC for TLS should be revised. On policies, as I mentioned, regardless of what the protocol or application= does, there is a possibility of path not being valid. On name constraints, Annex G is informative. I also do not see why you nee= d to mix path building and path validation You can always have multiple pa= ths even without name constraints and some of them will be valid and others= will not be due to other reasons. Inhibit policy mapping is a tool used to reject cross certificates. The me= chanism is useful when you only want to trust enterprise certificates. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, April 08, 2014 3:33 PM To: Santosh Chokhani Cc: mrex@sap.com; Watson Ladd; tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms Santosh Chokhani wrote: >=20 > The EKU is generally only applies to the leaf certificate (per X.509=20 > and RFC 5280) and is not involved in path processing. EKU applies *ONLY* to higher layer protocols where the higher layer protoco= l specifies behaviour for a list of EKUs. For TLS, such specification simp= ly do not exist. Potentially, there is something in the CABrowser Forum Baseline requirement= s. But I'm not a Browser implementor, so I don't know and don't care. I'm= a maintainer of a TLS library and application level wrapper to TLS for pro= grammatic use. >=20 > While TLS applications may or may not be able to set policies, the=20 > interactions among policy related extensions and path validation state=20 > machine can make the path invalid if the policy intersection is null=20 > and the require explicit policy flag has been turned on. Aside from what the CABForum & Browser folks may have defined to create fan= cy GUI chrome, I'm not currently aware of any X-over-TLS spec that gives me= aning to policies. So the easiest approach is to entirely ignore them -- d= uring path validation as well as on the end entity certs. >=20 > Path building need not be tied to path validation. That is your choice. > Name constraints for the hierarchical name form types are not a mess=20 > as you say. To me, the idea behind X.509 11/2008 Appendix G.3.3 looks like a pretty big= mess, and it requires an iterative approach of building a certification pa= th, failing, building an alternative path and succeeding, and this is where= the whole name constraints processing becomes out of scope of PKIX/rfc5280= . >=20 > I see lot of misunderstandings and exaggerations about problems in=20 > X.509 and RFC 5280 and folks with incorrect implementations having an axe= to grind. I see a huge amount of needless complexity A while ago I had an inquiry from a governmental customer because our libra= ry rejected their "pretty" certificate chains on the TLS server cert. They had a critical policy constraints extension in one of their path CA ce= rts https://tools.ietf.org/html/rfc5280#section-4.2.1.11 with the field "inhibitPolicyMapping" present(!) To me, this particular extension looks like a pretty stupid design flaw. -Martin From nobody Wed Apr 9 08:26: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 6DEDA1A030F for ; Wed, 9 Apr 2014 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOAjm6Giz3FV for ; Wed, 9 Apr 2014 08:26:38 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB661A02AA for ; Wed, 9 Apr 2014 08:26:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,826,1389762000"; d="scan'208";a="2572577" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 09 Apr 2014 11:26:37 -0400 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 9 Apr 2014 11:26:37 -0400 From: Santosh Chokhani To: "mrex@sap.com" Thread-Topic: [TLS] Certificate validation can of worms Thread-Index: AQHPUG9nRS10t5Ha0EyLKsoi0FgTh5sG4JsA///FM+CAAE2tgIABHNfAgABnzACAAPY3QA== Date: Wed, 9 Apr 2014 15:26:36 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811391794FB@scygexch10.cygnacom.com> References: <4262AC0DB9856847A2D00EF817E81139178FE7@scygexch10.cygnacom.com> <20140408204150.9505B1ACB3@ld9781.wdf.sap.corp> In-Reply-To: <20140408204150.9505B1ACB3@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.117.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/1Qis2MvkseZWrTosIha_3lY0SjQ Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate validation can of worms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 15:26:42 -0000 Martin, You are misreading this. This is talking about things such as must be crit= ical. For example, 5280 requires some extensions to be critical. Some of = the path validation software was checking if the extension was marked criti= cal or not and then was throwing an error if not marked critical. There is= no need for that. CA has already produced an object. The consumer unders= tands the extension and should go ahead and process it. CA having not set = it critical does not and should not make a difference. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, April 08, 2014 4:42 PM To: Santosh Chokhani Cc: mrex@sap.com; Watson Ladd; tls@ietf.org Subject: Re: [TLS] Certificate validation can of worms Santosh Chokhani wrote: >=20 > The EKU is generally only applies to the leaf certificate (per X.509=20 > and RFC 5280) and is not involved in path processing. > I would think that if EKU is present at least a browser application=20 > will ensure that the certificate has server auth OID. There is one central statement in rfc5280/PKIX that you seem to be unaware = of: https://tools.ietf.org/html/rfc5280#section-6.1 Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. Whit this "this profile RECOMMENDS against including such checks" says explicitly to an TLS implementor: you SHOULD NOT implement any conform= ance checks to stuff that is described in section 4 & 5 of this document. = (so you do not have to read, let alone understand what all the stuff in tha= t part of the document means). -Martin From nobody Wed Apr 9 08: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 BC7351A03AD for ; Wed, 9 Apr 2014 08:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw_T7S-rXgdb for ; Wed, 9 Apr 2014 08:54:29 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 078BD1A03AA for ; Wed, 9 Apr 2014 08:54:03 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta12.westchester.pa.mail.comcast.net with comcast id no9m1n0031HzFnQ5Cru3od; Wed, 09 Apr 2014 15:54:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id nru31n00L3ZTu2S3aru3dY; Wed, 09 Apr 2014 15:54:03 +0000 Message-ID: <53456D1B.1010804@alum.mit.edu> Date: Wed, 09 Apr 2014 11:54:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397058843; bh=ClxOPWKtyt72dY681irhpfmcdKpeEE4rfFm6sJY4JnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Za7L6VhmUcFRvI+rLOzM0xtlyZ1K8hbP81dkS/Mbg2yLuyD2RYiyMtmxH5pPJ8yyL 4JO1lnonUStCHrMXi9GuZdXimoif33s3NHcgPf4m/mhygzoYCh/5eausIMHlTvzRtx 2EyYtnvAZR1qLU9K/V6FvLwqaUtsf9jURV/bbcfZfllC9gnE7pXGjbQzEfz1NUN8jM 0korHQiDWjscE7XffiAXe9KZRSvzz4dEMzLVLHo5Ar1PsiKqHH89puNoGeVSnqDJ+I azTIghOTB/y0D8WZp1kiQSiZajHiyNK1kDBaZVcNl5NWM1E8ZlDE7nycZd6OXZVap0 cgVf0Uy0zZz5g== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/crf6-T4wRL32olVSdEsQkTWLX0M Subject: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 15:54:29 -0000 [Disclaimer: I'm new here - I just subscribed to this list so that I could discuss this point. So don't assume I have much context.] I've been seeing suggestions here and there recently to use ALPN as a registry of protocols for various purposes. So I went looking to find out what that was. And I found draft-friedl-tls-applayerprotoneg. IIUC this is *the* authoritative definition of ALPN. From the friedl draft I understand its use in the context of TLS. I would like to understand if the *intended* scope of applicability is broader, and if so, what it is. For instance, the draft doesn't mention DTLS. But I have found discussion elsewhere that says it is intended to be used for DTLS. I do understand that DTLS and TLS are closely related, and apparently it is intended that both will share the same Next Protocol Negotiation mechanism. And that means that each will need a registry of protocol names that may be used within this negotiation. OTOH, it is far from clear that the *same* registry should be used for both TLS and DTLS. The two transports have significantly different characteristics, so that many application protocols will only work over one or the other. (Or if they work over both, they might arguably be *different* protocol variants.) And what about using the ALPN registry for protocols that run on top of transports other that TLS and DTLS? Is that appropriate? IMO at the very least the IANA Considerations section of this draft should be beefed up as follows: - Specify the policy IANA is to use for deciding whether to accept a new registration in the ALPN registry. (You can't define a new registry without this.) - Specify clearly the information that is to appear in the ALPN registry. IMO, in addition to the name this needs to include *at least* the transport protocol(s) over which the application layer protocol is valid. - Specify the transport layer protocols that are valid transports of ALPN protocols. - Specify the acceptable syntax of ALPN names - Specify guidelines for when it is appropriate to add a new protocol to the ALPN registry. (E.g., when it is intended to be used in NPN negotiation in TLS and DTLS.) Without some clarity here I fear that people will be tempted to use this registry for registering names of arbitrary protocols that run over arbitrary other protocols. (E.g., as an alternative to the IANA registry of SDP "proto" values.) Thanks, Paul From nobody Wed Apr 9 08:57:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B75E1A0389 for ; Wed, 9 Apr 2014 08:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7bQjG3_iTOt for ; Wed, 9 Apr 2014 08:57:38 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF01A035C for ; Wed, 9 Apr 2014 08:57:38 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta01.emeryville.ca.mail.comcast.net with comcast id nqar1n0051Y3wxoA1rxePQ; Wed, 09 Apr 2014 15:57:38 +0000 Received: from [192.168.1.8] ([71.202.164.227]) by omta15.emeryville.ca.mail.comcast.net with comcast id nrxd1n0074uhcbK8brxdnZ; Wed, 09 Apr 2014 15:57:38 +0000 Message-ID: <53456DF1.7080904@brainhub.org> Date: Wed, 09 Apr 2014 08:57:37 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397059058; bh=kgwDCrgdGBZX1DQ0PiqkwDwiHnpTkI6CSpczL9E5f+Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JDPzziaAJCyxqdOSc4EUGPgYglHsV1IWyEnYZBrzwLrCYRd6eZlyXDxfRKHr/moXw Dzi9lRfdLZdnUeQZo7nW77nbYXRVBpNHEp3yCUFdUtF+rTLkG9JA2al7VtncMPp9V9 KQm+k48/9RkjCAoQvJXAUjYuzDddAZ62ZIKwBTMdBTA5dlR7Mq+Hmv+zGJ3oVImxnk tAgSY6mzukGoRBscMYn7d8JojxcrO5jWjMpzZZHjUngTaDGBP1b5e4x4BwBRQ0pzzx gqnTWZLnoskN2KB5bzg4YylCLsetdlfJi+Zsgk205DIoRqzY2IyW/uIZ1jq8+b+dnY RCTSpm2EFvLjg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AIhWCiyUDBk0lS13MW2aUyqw8xg Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 15:57:40 -0000 Re endianess, shouldn't the decision here be based on the current distribution of little v.s. big endian architecture on CPUs that are likely used in TLS servers and accelerators? ( It doesn't matter much for end-clients, I suppose. One may argue that this doesn't matter for the rest either. But then the argument goes that the big endian is the traditional canonical representation. ) From nobody Wed Apr 9 09:04: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 212CB1A035B for ; Wed, 9 Apr 2014 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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.272, 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 uMqEIMfrxB2T for ; Wed, 9 Apr 2014 09:04:29 -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 6CAE91A031F for ; Wed, 9 Apr 2014 09:04:29 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so2216234vcb.22 for ; Wed, 09 Apr 2014 09:04:28 -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=A/UmfCkwP0TrlM49eMkH/HPj0vdGpQ7oNoB0HZyTu4s=; b=ToKdlnHs8PLO0MdiOwFZMoLQ3fa3jxKZM6/PyrEVUdD0ZdG7GTLEFekfqOhv+oKtYl oqemZ4MFTl4rN//nRlodWyKbuK3I3hp8XTfE0DLrkQAeYxmhr9XLV5poVUam4jFfmMdP v1i7/mpWkzGslAL044jFWshop/SbFfOokIYO0loeVXDrOQZ+yeb+A+U63NhqMT1+aimQ ACGUMuLH7nX0eVUaGaLUJ5In3Nkx8nE9witc0KncaV7pTlAUDQ2rC6kjQ6rehhz99qr5 H4lyrB4MF0te8S/otgjuMJf+mZZaROw676BRwidjg/l4U0tQD1fT3YUmy9GDMl9u4Utz 0/zQ== 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=A/UmfCkwP0TrlM49eMkH/HPj0vdGpQ7oNoB0HZyTu4s=; b=IVEi1nDPEvTIj7QN4VakZp1u6k+MiiWP+GkBWmgkRgG/0dU/PF5jnbfWPpxq3ByIQQ xVo7h3O36wd66+Y561qeUpDId6kzIA3ioBQKIW4UoDUYlsPfo0YdoQ9zgBEr9biczouA R5sqtFaN9/5jV7VIeVHXwut+ry36ssKEgfGqZCWV378s1gRrGPNOmnnOwuHIXHAPyYKn Wxo6aA2fRjwrqFC3H8LL5dT0uZL91RWkCwc4fyhsHvkSOmrcVfBlpd9/02Ne09Tt1Hjl qfCaZUVk9g2hfiJuvN7PdxLm16bfCsGlY0bJ5gqpMppqyR6/7pUR/J6ZTNqw9iFbj9Py hEvw== X-Gm-Message-State: ALoCoQmovcKZz5qx6cRnReWcwux8xsb5ElNFs+tg0FFNLogsAL5rbcbTZ9nmhY4iJ4JMvGtklnKzbsNaUGRvBTBO2fhwJHinNrWS9k5qKCYo66yHHUhUYZpIvksKdKuvUhbbaXUB4NB/PEwLzpAwC6jyg1DJlFi/QDtbnRMnfUvr6RhI94uoqhs5vjfJ+O0o8B0BFedI8dYX X-Received: by 10.52.108.164 with SMTP id hl4mr7692231vdb.25.1397059468705; Wed, 09 Apr 2014 09:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Wed, 9 Apr 2014 09:04:07 -0700 (PDT) In-Reply-To: <53456D1B.1010804@alum.mit.edu> References: <53456D1B.1010804@alum.mit.edu> From: Adam Langley Date: Wed, 9 Apr 2014 09:04:07 -0700 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/811-jETeXSHA3Gh-svSgv-OWdIs Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 16:04:31 -0000 On Wed, Apr 9, 2014 at 8:54 AM, Paul Kyzivat wrote: > For instance, the draft doesn't mention DTLS. But I have found discussion > elsewhere that says it is intended to be used for DTLS. Yes, it applies to DTLS also, although I don't know anyone use it for such yet. > OTOH, it is far from clear that the *same* registry should be used for both > TLS and DTLS. The two transports have significantly different > characteristics, so that many application protocols will only work over one > or the other. (Or if they work over both, they might arguably be *different* > protocol variants.) I believe there is only one registry. I don't think that there's danger of ambiguity here. If the connection is DTLS then it's obviously the DTLS varient of the protocol that should be used. > And what about using the ALPN registry for protocols that run on top of > transports other that TLS and DTLS? Is that appropriate? I don't think so. > - Specify the policy IANA is to use for deciding whether to accept > a new registration in the ALPN registry. (You can't define a new > registry without this.) The policy is Expert Review as given in the draft. > - Specify clearly the information that is to appear in the ALPN > registry. IMO, in addition to the name this needs to include > *at least* the transport protocol(s) over which the application > layer protocol is valid. I don't think this additional bureaucracy is useful. I can't imagine a situation where this is going to help someone. > - Specify the transport layer protocols that are valid transports > of ALPN protocols. Mentioning DTLS is something that I think has general agreement for inclusion in the next revision of the draft. > - Specify the acceptable syntax of ALPN names ALPN names are bytestrings, there's no syntax. > - Specify guidelines for when it is appropriate to add a new protocol > to the ALPN registry. (E.g., when it is intended to be used in > NPN negotiation in TLS and DTLS.) I would hope the expert in the Expert Review would notice a request that was so confused that they were applying for an ALPN string when not using (D)TLS! Cheers AGL From nobody Wed Apr 9 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 6DE231A03A1 for ; Wed, 9 Apr 2014 09:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfQ1V5EWntDw for ; Wed, 9 Apr 2014 09:09:40 -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 573231A03B8 for ; Wed, 9 Apr 2014 09:09:40 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so2066337eei.33 for ; Wed, 09 Apr 2014 09:09:39 -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=uH6/OuwRWl4j/4Ulv7R+wx4qOpn6HuZLA+32wlN1q0g=; b=PwfosChkZPiH2SZsnVGXtNHvZZkAl1m+4SixyJKFDVJgMrN94MTfAj2lHBx4+07+7+ 5dWFbRo8opXCwx/+z3zPu52DH711BjeR0MdsRSSm4XmTkt03s7Sumd9kuQ+JdaudbO4+ mo8H3o+uJjyemc+2V+KXY80YSndN/w9d5VukZrQm7SKYR8MsRCEsK5MU6hiwCUwoRBBX EUZkEQHysxtOV8wrmvZ5wGdWSvEhBLL0TQJDokHcaTGz5bpk+OlIEuoTj28Lzgi51OjM qzpxjQPJWRkX9qRt/zkru1f8RJJzcBS1C/pMT1ELTsZBkt3boeDqGKZhWib/6YReEWh9 /uSQ== X-Received: by 10.15.10.3 with SMTP id f3mr13348541eet.1.1397059779399; Wed, 09 Apr 2014 09:09:39 -0700 (PDT) Received: from [192.168.243.52] ([192.116.177.210]) by mx.google.com with ESMTPSA id e42sm3194523eev.32.2014.04.09.09.09.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 09:09:38 -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: <53456DF1.7080904@brainhub.org> Date: Wed, 9 Apr 2014 19:09:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <29C7A26E-6B79-44F0-ADFD-C14FFB4AA6BC@gmail.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <53456DF1.7080904@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fMjgss9H1v0kNfKsYpBd_vA-AsU Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 16:09:45 -0000 On Apr 9, 2014, at 6:57 PM, Andrey Jivsov wrote: > Re endianess, >=20 > shouldn't the decision here be based on the current distribution of = little v.s. big endian architecture on CPUs that are likely used in TLS = servers and accelerators? >=20 > ( It doesn't matter much for end-clients, I suppose. One may argue = that this doesn't matter for the rest either. But then the argument goes = that the big endian is the traditional canonical representation. ) It became the canonical representation when the Internet ran on Sun = boxes with Sparc chips, which were Big-endian, and a little bit on other = platforms such as mainframes and powerPCs (which were also big-endian) = and VAX and Intel (which were little-endian). Now Intel dominates the = servers, and the clients are split among Intel and ARM, both of which = are little-endian.=20 Regardless, reversing a string of bytes is such an efficient process, = that it probably makes no measurable difference in performance which way = the bits on the wire are read and written. I think the decision should be made based on convenience and the chance = for errors, although I can=92t tell which way that goes. BTW: the same = decision should be made for ChaCha/Salsa and Poly1305. Yoav From nobody Wed Apr 9 09:28: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 326771A03BE for ; Wed, 9 Apr 2014 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3Ilni3Dajci for ; Wed, 9 Apr 2014 09:28:40 -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 C5FE71A0380 for ; Wed, 9 Apr 2014 09:28:39 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so2715069wgg.2 for ; Wed, 09 Apr 2014 09:28: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=4RzAfyuRMqL++arsFiPLuyV2khlzLngC8NwDcjoeHsU=; b=HM0JE3NXxX2v9/FyLz9iMbe1v3IjuHDMAPyh/8+Vlsb13LD6pS9l0IDRsx4w5fP9FZ LDAmINMZKLTw0Sdl80dTm5FwDrUoAJYuIgvugy5MIBLNd8VDnfqAxXCMxaSUTFyG8FJT wKtDqUWLcDgYoYsilWFHupBmr1jUyZRbnN3yXVwFtjamZdiTjQB0e5fYf7kb1hsLWYyR YqdzzlglizNt9cvgSS2LHmXULhOV6iwHb1Nx5cwK1L2/8/XKnOHungqbN2qDWikxLRcY zxVYSO2ZNskXE+eJqowqp4Wb4sjY1YbjDq8Ts2j2Vq9O1Ff3rx29XbE2LwUw0Az6/bBw xHjA== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr10916542wib.50.1397060918257; Wed, 09 Apr 2014 09:28:38 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 09:28:38 -0700 (PDT) In-Reply-To: References: <53456D1B.1010804@alum.mit.edu> Date: Wed, 9 Apr 2014 09:28:38 -0700 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2ZwAC5kTaXMFlY_ll0F6AWYDwDQ Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 16:28:41 -0000 What Adam said, except... On 9 April 2014 09:04, Adam Langley wrote: >> - Specify guidelines for when it is appropriate to add a new protocol >> to the ALPN registry. (E.g., when it is intended to be used in >> NPN negotiation in TLS and DTLS.) > > I would hope the expert in the Expert Review would notice a request > that was so confused that they were applying for an ALPN string when > not using (D)TLS! Oops: http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-11.1 Actually, I think that this is a good (re)use of the registry. Sure, it doesn't make sense to identify protocols within (D)TLS, but often non-(D)TLS protocols need to be identified alongside (D)TLS protocols, as is the case with the above. (If you are confused about the where this happens exactly, see http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11). From nobody Wed Apr 9 09: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 1D0101A03E7 for ; Wed, 9 Apr 2014 09:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 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.272, 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 SNoeeajSBVpn for ; Wed, 9 Apr 2014 09:49:54 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 231D91A032E for ; Wed, 9 Apr 2014 09:49:54 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so2392019veb.29 for ; Wed, 09 Apr 2014 09:49:53 -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=G3sViBB40V4T2l+JTfzPOMjRs8KPZ087C21tC/B5KG4=; b=SSavo/pJK8OQqiVHoVsYv32o/7CxmJd67ClT9qYcCpaITDCI54jTIC2inpr0Bb9xP4 T2MCXZUP9o5Eq9PrhAaNtgGa6/CMOt/X11uP6cqYcKK9ybxszCOnwImzujUJAgI6E1ER 5bGM7FQTBsngi61edFK6RMsuBINp5k0in4pvG2eOgp4k+iSQ44id4gaPsYH2Otfv51ve Vt8jM5KX0UumfVZ8Y3uLB8Qf+pWhbdhe9I8KNjmI4O/Lf5qWFtlY0QzDQHinD2ZHu1KW ic2iRUBcUv3+zgqCpPjOYa4NSr8ubpCh+ufBlWdSTS4tezvRletwFm7zWxiv40+tsaQa TcTw== 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=G3sViBB40V4T2l+JTfzPOMjRs8KPZ087C21tC/B5KG4=; b=Ujx0oFT/X9iLzXBdeq1ecgKnDpnKiW72SWnS5unFREAPmgA37e7sZZ0nBJjT4CaCC4 4ULr4RoVnRls2lWcadSlbyNMRSHhjFwf5YXdLzKWOdCI9BJR1yrfavH/oieQzj6c4pt/ tz4E7xFhS1rlzcJM2ABNxoDkDNA9zV9prKhVzPUhew4h5Vz2UvfBk/y7dIQwnXRLyr87 CtnlAOIL/3CiFjDbYiHBVdwpDxt90+6bzWi1WCfh4Z+iol9Q30tKPDnfswSKf0shgyzc 5187pSZCRnGImQzvA9c8/Q35t3v/CPEpS0Ry8CYxicoNJV4nDWNk7gzaK1BVcu/Uek35 ZAaw== X-Gm-Message-State: ALoCoQnor7erc1YSGErd647NAjdYP/8zpv5Um5ODxc0mgVpKfDjquI7vXURPi50CDXXQD19oPAwrIYZCBZpoPtbUOLzdNdzO9Uy0BVp21r5+mGC6+R2tLsZmMOKz2XOCOc/JD2V4PUh1iEU50K5urdShiWB7Prq+NqUGcp++mNas7pA5vOe8dKPPEOBXqmSA01RGSeaMoPnW X-Received: by 10.220.147.16 with SMTP id j16mr9752430vcv.14.1397062193411; Wed, 09 Apr 2014 09:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Wed, 9 Apr 2014 09:49:33 -0700 (PDT) In-Reply-To: References: <53456D1B.1010804@alum.mit.edu> From: Adam Langley Date: Wed, 9 Apr 2014 09:49:33 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hWTUhloU6ZDm4_L9CIreuHvgFKw Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 16:49:55 -0000 On Wed, Apr 9, 2014 at 9:28 AM, Martin Thomson wrote: > Oops: > http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-11.1 > > Actually, I think that this is a good (re)use of the registry. Sure, > it doesn't make sense to identify protocols within (D)TLS, but often > non-(D)TLS protocols need to be identified alongside (D)TLS protocols, > as is the case with the above. (If you are confused about the where > this happens exactly, see > http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11). I wouldn't add h2c to the ALPN registry for this case, but I don't feel strongly. Cheers AGL From nobody Wed Apr 9 09:52: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 48BC21A03E6 for ; Wed, 9 Apr 2014 09:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLRSIbcAbE6V for ; Wed, 9 Apr 2014 09:52:50 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD41A03EF for ; Wed, 9 Apr 2014 09:52:42 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id nnnw1n0030mv7h051ssiad; Wed, 09 Apr 2014 16:52:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id nssh1n00n3ZTu2S3XssiyG; Wed, 09 Apr 2014 16:52:42 +0000 Message-ID: <53457AD9.2020409@alum.mit.edu> Date: Wed, 09 Apr 2014 12:52:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Adam Langley References: <53456D1B.1010804@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397062362; bh=Qrx5jIMSTIehoGdkQgY9lQbpMQn5V7WfeFtQ8wA6hWI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lkto0DxUww3QEsYWMK5AjDgZYcrx6ttLeYRZdf+iq4Fk5bGYCA0I14ip9mBgfr4qN VEGYleDQmP0PsicBWCNQjqQXH5Cb40qdkJtFlfyDTBN+c3h8AZCn4TaWB6ygvMfHbn G3Z5hAjk4QZgDaZP2XZQ6r3hH3r6RfS0iWg4TpScKvGyeyIO0srwq7j1fDvU7Cpefo V40j8rBaeLSnfnsLcEC9u+sHq4cNv3+zReqz9t5ie7wq2X41q16hJbcBarNMk5pnJY BAGgUpI/XFBJmHiSZgxcF4C5HoBgYsbwDTQFdgxcfKgAxxdFgsbZ2l5rGYwVhNjbd0 wQvZFd9AmjXSg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vgpLckvvwavgQ8hdKHjzSLdStBM Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 16:52:51 -0000 On 4/9/14 12:04 PM, Adam Langley wrote: > On Wed, Apr 9, 2014 at 8:54 AM, Paul Kyzivat wrote: >> For instance, the draft doesn't mention DTLS. But I have found discussion >> elsewhere that says it is intended to be used for DTLS. > > Yes, it applies to DTLS also, although I don't know anyone use it for such yet. > >> OTOH, it is far from clear that the *same* registry should be used for both >> TLS and DTLS. The two transports have significantly different >> characteristics, so that many application protocols will only work over one >> or the other. (Or if they work over both, they might arguably be *different* >> protocol variants.) > > I believe there is only one registry. I don't think that there's > danger of ambiguity here. If the connection is DTLS then it's > obviously the DTLS varient of the protocol that should be used. > >> And what about using the ALPN registry for protocols that run on top of >> transports other that TLS and DTLS? Is that appropriate? > > I don't think so. > >> - Specify the policy IANA is to use for deciding whether to accept >> a new registration in the ALPN registry. (You can't define a new >> registry without this.) > > The policy is Expert Review as given in the draft. Sorry - I was looking at an old version that didn't have that. >> - Specify clearly the information that is to appear in the ALPN >> registry. IMO, in addition to the name this needs to include >> *at least* the transport protocol(s) over which the application >> layer protocol is valid. > > I don't think this additional bureaucracy is useful. I can't imagine a > situation where this is going to help someone. Doesn't seem like much "bureaucracy" to me. But the reference to the protocol specification probably is sufficient. (That wasn't in the old version I was looking at.) >> - Specify the transport layer protocols that are valid transports >> of ALPN protocols. > > Mentioning DTLS is something that I think has general agreement for > inclusion in the next revision of the draft. Good! >> - Specify the acceptable syntax of ALPN names > > ALPN names are bytestrings, there's no syntax. OK. It would be good to instruct IANA on uniqueness constraints. Clearly the Identification Sequence must be unique. I guess that the protocol name should also be unique. >> - Specify guidelines for when it is appropriate to add a new protocol >> to the ALPN registry. (E.g., when it is intended to be used in >> NPN negotiation in TLS and DTLS.) > > I would hope the expert in the Expert Review would notice a request > that was so confused that they were applying for an ALPN string when > not using (D)TLS! Now that I know Expert Review is being used, that helps. I am a designated expert reviewer for a few IANA registries. And I can say from experience that I would like the document that establishes the registry to provide guidelines to me about what to look for. This may be obvious to the authors. But as time passes it can become less obvious. Thanks, Paul From nobody Wed Apr 9 10:29: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 D6FE11A02DF for ; Wed, 9 Apr 2014 10:29:42 -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 6X8_yJTTIdL7 for ; Wed, 9 Apr 2014 10:29:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 40A8F1A02D3 for ; Wed, 9 Apr 2014 10:29:38 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 17:29:37 +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.0913.002; Wed, 9 Apr 2014 17:29:36 +0000 From: Andrei Popov To: Adam Langley , Martin Thomson Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUw Date: Wed, 9 Apr 2014 17:29:35 +0000 Message-ID: <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(51444003)(189002)(199002)(51704005)(13464003)(377454003)(74316001)(81342001)(81542001)(80022001)(2656002)(4396001)(87936001)(50986999)(76176999)(54356999)(77096999)(77982001)(79102001)(74662001)(83322001)(86362001)(80976001)(76576001)(31966008)(15202345003)(76482001)(85852003)(83072002)(74502001)(19580395003)(19580405001)(20776003)(46102001)(33646001)(15975445006)(92566001)(99396002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:FC3CF135.1B3057EA.DE6734F.8426984A.201EE; 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/ZzHPlrvSFIGWDGUrqvEHym8IRTY Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 17:29:43 -0000 I'm with Adam on this: ALPN registry is defined under the "Transport Layer = Security (TLS)" heading, so adding protocol IDs that will never be negotiat= ed in the course of the (D)TLS handshake to this registry could be confusin= g. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Adam Langley Sent: Wednesday, April 9, 2014 9:50 AM To: Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Questions about ALPN On Wed, Apr 9, 2014 at 9:28 AM, Martin Thomson w= rote: > Oops: > http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-11.1 > > Actually, I think that this is a good (re)use of the registry. Sure,=20 > it doesn't make sense to identify protocols within (D)TLS, but often=20 > non-(D)TLS protocols need to be identified alongside (D)TLS protocols,=20 > as is the case with the above. (If you are confused about the where=20 > this happens exactly, see=20 > http://tools.ietf.org/html/draft-ietf-httpbis-http2-11#section-6.11). I wouldn't add h2c to the ALPN registry for this case, but I don't feel str= ongly. Cheers AGL _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 9 11:04: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 B70531A0303 for ; Wed, 9 Apr 2014 11:04: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 fZlJrcY-Tjc2 for ; Wed, 9 Apr 2014 11:04:17 -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 4A1701A0420 for ; Wed, 9 Apr 2014 11:03:39 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so2810607wgh.0 for ; Wed, 09 Apr 2014 11:03: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=fo1lNWmhx+uVAUDd7cjRkLV/yI4JBLV3+AKYyCN8GMg=; b=N3D5ht9pxuZet10cjIPKPhkCobi2xhWcnmszfjBQ5UjDvDYHKEsy/Mw6y09jEz8HrS NnGywm9D5E+P2jixfxD6nD11eK7LmgPS5OeZU6XuE3D8mmXYW1AMTcgk1Ut6w2ztE3FC PJ0TCsIACcUxXi9czBkgbb3VlCJaqcm2tfNFza0M4PtUisaf6cDcqTMtnNv6AqGn79rj OIelyW0M1w7GRNKdxmYkS8UPLArhYBPCNbsb7QtXOMfqk7ar/XmfkwYOvyaoxwTNB0WD 6mbROspZHLzFZgvWh6lMSxdQkzFkCl8XU7iphABAoHQFLg1+5tdHhK0LyFBlP5YWTM4t CQ6Q== MIME-Version: 1.0 X-Received: by 10.180.108.13 with SMTP id hg13mr3221241wib.56.1397066618176; Wed, 09 Apr 2014 11:03:38 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 11:03:38 -0700 (PDT) In-Reply-To: <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 9 Apr 2014 11:03:38 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KvSqG41ILYfil-3Kz8LCH3XB-dA Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 18:04:18 -0000 On 9 April 2014 10:29, Andrei Popov wrote: > ALPN registry is defined under the "Transport Layer Security (TLS)" heading Maybe we should instead consider whether that is an appropriate location for the registry. This is a very interesting property from an application perspective, I'd certainly be disappointed if this were to be pigeon-holed into a TLS-only thing. (I'll point out that I tend to think that most, if not all, application protocols would benefit from exclusively using TLS. But that's not a universally shared view :) From nobody Wed Apr 9 11:19: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 E66861A03D3 for ; Wed, 9 Apr 2014 11:19:20 -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 XfmE3NOs2F4D for ; Wed, 9 Apr 2014 11:19:19 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id ACD0B1A03C4 for ; Wed, 9 Apr 2014 11:19:18 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 18:19:17 +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.0913.002; Wed, 9 Apr 2014 18:19:17 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MA== Date: Wed, 9 Apr 2014 18:19:16 +0000 Message-ID: References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(377454003)(189002)(199002)(85852003)(80976001)(77982001)(74316001)(76482001)(19580395003)(92566001)(50986999)(76176999)(54356999)(77096999)(46102001)(19580405001)(79102001)(83322001)(2656002)(83072002)(74662001)(80022001)(31966008)(81542001)(99396002)(76576001)(20776003)(87936001)(74502001)(4396001)(33646001)(86362001)(81342001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:BC9EFA25.A732C71A.BCF3F3BB.9AE1D249.20249; 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/VQ-AMRM0mVFoOGYvxJkkaqOk6hM Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 18:19:21 -0000 VGhlIG9yaWdpbmFsIGludGVudCB3YXMgdG8gY3JlYXRlIGEgcmVnaXN0cnkgb2YgYXBwbGljYXRp b24gcHJvdG9jb2xzIG5lZ290aWFibGUgd2l0aGluIHRoZSAoRClUTFMgaGFuZHNoYWtlLCBzbyB0 aGF0IGFwcGxpY2F0aW9ucyB3b3VsZCBrbm93IHdoaWNoIHByb3RvY29sIHRvIHNwZWFrIG9uY2Ug dGhlIChEKVRMUyBjaGFubmVsIGlzIGVzdGFibGlzaGVkLCBhbmQgYXZvaWQgZXh0cmEgcm91bmQt dHJpcHMuDQoNCklmIHdlIHdlcmUgdG8gYnJvYWRlbiB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlz IHJlZ2lzdHJ5IGJleW9uZCAoRClUTFMsIGhvdyB3b3VsZCB5b3Ugc3VnZ2VzdCBzY29waW5nIGl0 PyBXb3VsZCBpdCBiZSBqdXN0IGEgZ2VuZXJhbCwgYWxsLXB1cnBvc2UgbGlzdCBvZiBhcHBsaWNh dGlvbiBwcm90b2NvbCBJRHM/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBN YXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBX ZWRuZXNkYXksIEFwcmlsIDksIDIwMTQgMTE6MDQgQU0NClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBB ZGFtIExhbmdsZXk7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFF1ZXN0aW9ucyBh Ym91dCBBTFBODQoNCk9uIDkgQXByaWwgMjAxNCAxMDoyOSwgQW5kcmVpIFBvcG92IDxBbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IEFMUE4gcmVnaXN0cnkgaXMgZGVmaW5lZCB1 bmRlciB0aGUgIlRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIgDQo+IGhlYWRpbmcNCg0K TWF5YmUgd2Ugc2hvdWxkIGluc3RlYWQgY29uc2lkZXIgd2hldGhlciB0aGF0IGlzIGFuIGFwcHJv cHJpYXRlIGxvY2F0aW9uIGZvciB0aGUgcmVnaXN0cnkuDQoNClRoaXMgaXMgYSB2ZXJ5IGludGVy ZXN0aW5nIHByb3BlcnR5IGZyb20gYW4gYXBwbGljYXRpb24gcGVyc3BlY3RpdmUsIEknZCBjZXJ0 YWlubHkgYmUgZGlzYXBwb2ludGVkIGlmIHRoaXMgd2VyZSB0byBiZSBwaWdlb24taG9sZWQgaW50 byBhIFRMUy1vbmx5IHRoaW5nLg0KDQooSSdsbCBwb2ludCBvdXQgdGhhdCBJIHRlbmQgdG8gdGhp bmsgdGhhdCBtb3N0LCBpZiBub3QgYWxsLCBhcHBsaWNhdGlvbiBwcm90b2NvbHMgd291bGQgYmVu ZWZpdCBmcm9tIGV4Y2x1c2l2ZWx5IHVzaW5nIFRMUy4gIEJ1dCB0aGF0J3Mgbm90IGEgdW5pdmVy c2FsbHkgc2hhcmVkIHZpZXcgOikNCg== From nobody Wed Apr 9 11:24:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49941A041A for ; Wed, 9 Apr 2014 11:24: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 sfr_7qex34Gn for ; Wed, 9 Apr 2014 11:24:37 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD81A03F4 for ; Wed, 9 Apr 2014 11:24:37 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kx10so2827389pab.5 for ; Wed, 09 Apr 2014 11:24:37 -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=9BFhml8tub5jpVhotKRmS8i5QtGG2r7lHdKeNBxTyFw=; b=hqPA4Y0J7PyPpwnihYH7WelRgwM8DKFNjhjFDOBsyNUxLe/NjYlWuJkreSZmsRIGXF +qJ4yc8KT0W9tuNbhVeyeT/uJosUdHDm5w+MRFrTswx2PVJV1JKhFogWcdu+jmiwfwU6 whctPTepElTVRfGiEj4tgVjZj42YDh5+VNiDwKiyNmUqluTucQ+rlkx3waP9YaRb861M 6V2qO5hQvhJ7I0qZULI3mS5Qp7L5MoPbBVbz6ivlVZiFXXJdW0/MmEIzE5UEo6fdgyCA H4cxuh6QBOjqUMsDoQ6PNjki4ZbuJk+rZyW0Ayddq2XgrawGjLIO+cPoCp3O9ly5swBI cIzQ== X-Received: by 10.68.211.164 with SMTP id nd4mr14045739pbc.44.1397067877104; Wed, 09 Apr 2014 11:24:37 -0700 (PDT) Received: from [17.244.2.23] ([17.244.2.23]) by mx.google.com with ESMTPSA id kl1sm3968675pbd.73.2014.04.09.11.24.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 11:24:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D167) In-Reply-To: <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> Date: Wed, 9 Apr 2014 11:24:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B9DA67A-165F-4337-8135-D308E2906653@gmail.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1sMFzU_b5B4N5mXT0em0vduzb7Y Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Wed, 09 Apr 2014 18:24:39 -0000 > On Apr 9, 2014, at 4:50, Nikos Mavrogiannopoulos wrote: >=20 >> On Wed, 2014-04-09 at 07:37 -0400, Salz, Rich wrote: >> I support it to, but I want to see it in little-endian format, which requ= ires a bit more coordination before it could be published. >=20 > I believe you have already made your point several times. I think it is > important to see comments from people who plan or work on implementing > this draft, how each format affects them and whether there is a need for > little-endian. As a possible implementer of this, I don't care one bit. I would most likely= use an existing little endian implementation, but I can also reverse a byte= string when needed. -- Fabrice >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 9 11:37: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 7B2641A02D4 for ; Wed, 9 Apr 2014 11:37: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 B-pt29SE_lk8 for ; Wed, 9 Apr 2014 11:37:29 -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 C25DE1A042E for ; Wed, 9 Apr 2014 11:37:28 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so2923397wes.32 for ; Wed, 09 Apr 2014 11:37: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=GQyCyHdtyICB6trryp7SHivXjdFlW/m/JBCkixOgq6k=; b=0D3AamomMiZxR1JI5wGMnFHh4cpjS67LWm81MscKZmej5PyJDcUBFWns2DCV+YVaxE 1R+bse9xBfDm5/2ccy2FbPmZGrKCYuKpcMnXD/WOfSQdsgtY5IVXZU2F8OOWuRt1N1qr JcVicaNQdmrUk2t2p03kILOV0m74QSXgQHgYprt5fxonYBBGm8krUFqMdKQ1x3gtF9V3 LM4+h89g3KIJOU9zNSS9XImHAu+Oe3l0D7BVFq+Jl2n+pQqOISMfyrKFu3+u567Wyxee anjSeYMD8MBPaW8kBiK/fm7OKLwPMhRgK2xkfEmDzeWQ9DJBOzFvh32jgXL3ACLoA/ud jLWQ== MIME-Version: 1.0 X-Received: by 10.180.108.13 with SMTP id hg13mr3337746wib.56.1397068647237; Wed, 09 Apr 2014 11:37:27 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 11:37:27 -0700 (PDT) In-Reply-To: References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 9 Apr 2014 11:37:27 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UKHx1a07dttnQT-G7v7PQtWjV5w Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 18:37:30 -0000 On 9 April 2014 11:19, Andrei Popov wrote: > If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs? That's pretty much it. From nobody Wed Apr 9 11:49:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C45A1A0432 for ; Wed, 9 Apr 2014 11:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAmlbIeI5jwG for ; Wed, 9 Apr 2014 11:49:29 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 4790E1A0161 for ; Wed, 9 Apr 2014 11:49:29 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id nuaY1n0051uE5Es56upUHp; Wed, 09 Apr 2014 18:49:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id nupU1n00J3ZTu2S3cupUaa; Wed, 09 Apr 2014 18:49:28 +0000 Message-ID: <53459638.50309@alum.mit.edu> Date: Wed, 09 Apr 2014 14:49:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: tls@ietf.org References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397069368; bh=2rjD60laO4O6YcMdBY91NF3yji7P3lo2knE64BH5Ik0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TUxLVYZ+ud+4BYOf01bMj1paVZOriLDaPhSte8rtvmOijiXJvwUAyIWANt3RouCs9 VknBKQ7VgTAaJkia9SrSK7GqsTpjEhNNaUF8fTTZRTRJWs3wdKr1c6yXuyRmtwAOyu 551uvDOUh/l4Dsg4KaHVhR3HbCAX2F+EQs81TQp4BfkyMWwjYV2n8rXFYJF+e/Ej14 qubAlLiUBuR9OvG4ov06FK3RzPZHHtA5oqhWEY8MhZw/ljGhK3Khwjb8pzjwG9mhMf qy94o2tCZLAeufeJ4mTSkwtjDyzF7+KcT5FTSFl6C/cEO38+DXaXv86TR7+aDu4G8n lN1ApMNS8G/fA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n8jytzXKS7lPGMFVcTs1cSd4oBo Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 18:49:30 -0000 On 4/9/14 2:37 PM, Martin Thomson wrote: > On 9 April 2014 11:19, Andrei Popov wrote: >> If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs? > > That's pretty much it. What is your definition of "application level protocol"? I could understand it if it was protocols that are defined to run over some common transport, or set of transports with some common characteristics. For instance, over reliable, bidirectional, byte stream protocols. That would cover TLS, TCP, and possibly some forms of data channels, among others. But that would exclude DTLS. BTW, this could also encompass websocket sub-protocols. Thanks, Paul From nobody Wed Apr 9 11:59: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 D662F1A0439 for ; Wed, 9 Apr 2014 11:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmiOkifB8GZH for ; Wed, 9 Apr 2014 11:59:23 -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 40FDC1A0437 for ; Wed, 9 Apr 2014 11:59:23 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 18:59:21 +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.0913.002; Wed, 9 Apr 2014 18:59:21 +0000 From: Andrei Popov To: Paul Kyzivat , "tls@ietf.org" Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MIAAB3aAgAADWwCAAADc8A== Date: Wed, 9 Apr 2014 18:59:20 +0000 Message-ID: References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> In-Reply-To: <53459638.50309@alum.mit.edu> 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: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(24454002)(13464003)(479174003)(51704005)(377454003)(189002)(199002)(85852003)(80976001)(77982001)(74316001)(76482001)(19580395003)(92566001)(15975445006)(50986999)(76176999)(54356999)(77096999)(46102001)(19580405001)(79102001)(83322001)(2656002)(83072002)(74662001)(80022001)(81542001)(31966008)(2171001)(76576001)(99396002)(20776003)(87936001)(74502001)(4396001)(33646001)(86362001)(81342001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:F41EF5E5.97139FE9.BCD2FF83.4616EA61.2024D; 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/6q_Y_w3iZ4QcWBeHYp1Oyk893_w Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 18:59:27 -0000 If the ALPN registry is scoped to (D)TLS (as it is in the current ALPN draf= t), then we can say ALPN protocol IDs are for those protocols running withi= n the (D)TLS channel. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, April 9, 2014 11:49 AM To: tls@ietf.org Subject: Re: [TLS] Questions about ALPN On 4/9/14 2:37 PM, Martin Thomson wrote: > On 9 April 2014 11:19, Andrei Popov wrote: >> If we were to broaden the applicability of this registry beyond (D)TLS, = how would you suggest scoping it? Would it be just a general, all-purpose l= ist of application protocol IDs? > > That's pretty much it. What is your definition of "application level protocol"? I could understand it if it was protocols that are defined to run over some= common transport, or set of transports with some common characteristics. F= or instance, over reliable, bidirectional, byte stream protocols. That woul= d cover TLS, TCP, and possibly some forms of data channels, among others. B= ut that would exclude DTLS. BTW, this could also encompass websocket sub-protocols. Thanks, Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 9 12:24: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 0D9D71A0435 for ; Wed, 9 Apr 2014 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eblBYtvBk9BX for ; Wed, 9 Apr 2014 12:24:29 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8B1A0416 for ; Wed, 9 Apr 2014 12:24:28 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta07.westchester.pa.mail.comcast.net with comcast id ntbr1n0020ldTLk57vQUQ6; Wed, 09 Apr 2014 19:24:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id nvQT1n00F3ZTu2S01vQTVT; Wed, 09 Apr 2014 19:24:28 +0000 Message-ID: <53459E6B.4030900@alum.mit.edu> Date: Wed, 09 Apr 2014 15:24:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andrei Popov , "tls@ietf.org" References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397071468; bh=URktvo3MdjKD1DkPQ1Su8lzywznrFsDAiE3wth+xXkU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iE67bvnl35NLFjb8zFY//QNt+JAd3eEqJqCPmCspiMltVKIzRPwo09S8eJWAU2S8V b8D16k1V9I4qooYqWGwj8zMLvQJUqlK4rWKdgGbTC4ASSzjWEKAzb6YQVsC0UE2i0V HxrN+MNle88Tazlks/o70JmgS1gGe1x2tjpxJCeeOoC0R1xrJRN/GHqvKYDBuXkYv5 RwmEpucc8GnxtwXPI2D3ggSz/dujIzolFI7gXWtkNITmlwT9jmlj6Z+da075d0VLsj fV3XdyUZLRpSsgAutAldKeW0Bn43TOm5/QuVudfVoN1uSZNPdJE8JAhTuQQDi0JVPp lO2x9kasTpkhw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ovYZ1l82RXr18-aGFaFEZcs6ewg Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 19:24:30 -0000 On 4/9/14 2:59 PM, Andrei Popov wrote: > If the ALPN registry is scoped to (D)TLS (as it is in the current ALPN draft), then we can say ALPN protocol IDs are for those protocols running within the (D)TLS channel. That would work for me. But Martin seems to be suggesting going a different way. So that it would include things that could run over TCP or TLS. And then if you are going to allow DTLS, then why not UDP? Then we can talk about things that could run over websockets, and data channels. But then you have gotten to naming pretty much anything over anything. IMO there is a choice to be made: - define this operationally, as things negotiated with NPN - OR, things that run over a lower layer with a common set of characteristics. In this case, either pick a single set of characteristics (e.g., reliable, bidirectional, byte stream) or define a separate sub-registry for each set of characteristics. Thanks, Paul > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, April 9, 2014 11:49 AM > To: tls@ietf.org > Subject: Re: [TLS] Questions about ALPN > > On 4/9/14 2:37 PM, Martin Thomson wrote: >> On 9 April 2014 11:19, Andrei Popov wrote: >>> If we were to broaden the applicability of this registry beyond (D)TLS, how would you suggest scoping it? Would it be just a general, all-purpose list of application protocol IDs? >> >> That's pretty much it. > > What is your definition of "application level protocol"? > > I could understand it if it was protocols that are defined to run over some common transport, or set of transports with some common characteristics. For instance, over reliable, bidirectional, byte stream protocols. That would cover TLS, TCP, and possibly some forms of data channels, among others. But that would exclude DTLS. > > BTW, this could also encompass websocket sub-protocols. > > Thanks, > Paul > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 9 12:40: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 280121A044F for ; Wed, 9 Apr 2014 12:40:31 -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 iDHftjr9B3rV for ; Wed, 9 Apr 2014 12:40:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 413A41A0416 for ; Wed, 9 Apr 2014 12:40:24 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 19:40:23 +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.0913.002; Wed, 9 Apr 2014 19:40:23 +0000 From: Andrei Popov To: Paul Kyzivat , "tls@ietf.org" Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MIAAB3aAgAADWwCAAADc8IAACOqAgAAAgsA= Date: Wed, 9 Apr 2014 19:40:22 +0000 Message-ID: <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> In-Reply-To: <53459E6B.4030900@alum.mit.edu> 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: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(13464003)(189002)(199002)(377454003)(479174003)(24454002)(164054003)(83072002)(85852003)(74502001)(19580395003)(76482001)(31966008)(33646001)(99396002)(92566001)(15975445006)(19580405001)(46102001)(20776003)(81542001)(74316001)(81342001)(86362001)(79102001)(83322001)(74662001)(76576001)(80976001)(2171001)(2656002)(4396001)(87936001)(80022001)(77982001)(50986999)(76176999)(54356999)(77096999)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:F81EF1E5.97229FE9.BCD1FD83.215E961.20393; 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/yJ6wAWqZCGx1vWAiyM-APC0v3yc Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 19:40:31 -0000 My preference is to keep ALPN registry (D)TLS specific, otherwise the requi= rements for the registry become too nebulous. Also, IMHO things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs o= f individual protocols because they describe entire stacks of protocols. Wh= ile there may be uses for such identifiers, I don't think they belong in th= e ALPN registry. Cheers, Andrei -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Wednesday, April 9, 2014 12:24 PM To: Andrei Popov; tls@ietf.org Subject: Re: [TLS] Questions about ALPN On 4/9/14 2:59 PM, Andrei Popov wrote: > If the ALPN registry is scoped to (D)TLS (as it is in the current ALPN dr= aft), then we can say ALPN protocol IDs are for those protocols running wit= hin the (D)TLS channel. That would work for me. But Martin seems to be suggesting going a different way. So that it would i= nclude things that could run over TCP or TLS. And then if you are going to = allow DTLS, then why not UDP? Then we can talk about things that could run = over websockets, and data channels. But then you have gotten to naming pretty much anything over anything. IMO there is a choice to be made: - define this operationally, as things negotiated with NPN - OR, things that run over a lower layer with a common set of characteristics. In this case, either pick a single set of characteristics (e.g., reliable, bidirectional, byte stream) or define a separate sub-registry for each set of characteristics. Thanks, Paul > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, April 9, 2014 11:49 AM > To: tls@ietf.org > Subject: Re: [TLS] Questions about ALPN > > On 4/9/14 2:37 PM, Martin Thomson wrote: >> On 9 April 2014 11:19, Andrei Popov wrote: >>> If we were to broaden the applicability of this registry beyond (D)TLS,= how would you suggest scoping it? Would it be just a general, all-purpose = list of application protocol IDs? >> >> That's pretty much it. > > What is your definition of "application level protocol"? > > I could understand it if it was protocols that are defined to run over so= me common transport, or set of transports with some common characteristics.= For instance, over reliable, bidirectional, byte stream protocols. That wo= uld cover TLS, TCP, and possibly some forms of data channels, among others.= But that would exclude DTLS. > > BTW, this could also encompass websocket sub-protocols. > > Thanks, > Paul > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 9 12:41: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 9B71A1A0265 for ; Wed, 9 Apr 2014 12:41: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHBVBUUn87iB for ; Wed, 9 Apr 2014 12:41:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A45541A0416 for ; Wed, 9 Apr 2014 12:41:09 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 81582F986; Wed, 9 Apr 2014 15:41:06 -0400 (EDT) Message-ID: <5345A248.7050602@fifthhorseman.net> Date: Wed, 09 Apr 2014 15:40:56 -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: Martin Thomson References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KSxRu3dj3DsWsFaoKfkHaSFSmGEaxt9Mq" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zfyY3hEy_SyAYwu6erUMRrhrHQc Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 19:41:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KSxRu3dj3DsWsFaoKfkHaSFSmGEaxt9Mq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/09/2014 02:03 PM, Martin Thomson wrote: > On 9 April 2014 10:29, Andrei Popov wrote:= >> ALPN registry is defined under the "Transport Layer Security (TLS)" he= ading >=20 > Maybe we should instead consider whether that is an appropriate > location for the registry. whether we place the alpn registry under (D)TLS or not, including all the httpbis labels becomes slightly weird. if ALPN is *not* just for (D)TLS, then h2 is weird because it seems to specify not only the inner protocol in question but also the outer protocol -- what would h2 mean if it was specified in, say, an novel SSH ALPN-identified channel? would it be SSH-wrapping-TLS-wrapping-HTTP? or just SSH-wrapping-HTTP? if ALPN is just for (D)TLS, then h2c is weird because it is defined to not be usable in (D)TLS either. out of curiosity, how is h2c expected to interact with tcpcrypt, (if that ever gets off the ground) or with IPSEC? By definition, it's http over "cleartext TCP". But TCP over IPSEC is encrypted, as would be TCPCrypt. The obvious answer (which is "yeah yeah, it's still h2c, ignore that your TCP channel itself is encrypted") doesn't line up with the explicit wording of the draft ("cleartext TCP"). maybe it should say something like "HTTP directly inside TCP" to head off this hairsplitting. regards, --dkg --KSxRu3dj3DsWsFaoKfkHaSFSmGEaxt9Mq 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/ iQJ8BAEBCgBmBQJTRaJIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcUr0QAIk6QlIzMWNCUSeT4CyiZCZn VaBMymCoPNhrT8TCIjEOBXZzM9jU8IMxZsfWusrov9Ad8ypCWDanbIx8ie5W8J9r xbC20rJGQJ7yqcyVF6sz9RzazVYXW5W8viDby1bwkhAD6uu+BryVBHemWtfEAXA8 RrLA4AeDbd5g5Q4qY4iH+ZyfzQ/EgJwK3huNukULu6EpdJ7sGDILAxVCJztwcr2a 2i0/Qg7/n2za35gml4P8XqsVfRbDlh73Tz7+sUbbGcTWEL9hCRWanAQtaEuR8MGR UjAGfVrW/5zf1vKPinPtPsrMkxedmBA5Xfgl5pr4K4DWaAGA4R4WUy7MpKYktK1I 8vCthP6/eZMJmjD2OZW+bFlXMQ/n7eA51rlOUfBopGtjji2K7soACDLQ1/HM+yrh KvBbEr6qrEKDpfQbrvBntHqXT8uIoLqFEl+tqpCFGIyl4rVHab4rGcFjdHq8+3tN Wu3jwC7NwtmvnTnhmz96TJmeNA9xvW74qiCnCOMPusBezMmJkTAtDOmMg0KkqtWz was0rKG5IVdYuUBqmMdOEb6MQgbRDT17NIn6pMgxz+mIFqD46v2kB0hwuLJvRYWI 76RKYmqkbEP55cYR3gzWg4/iOiIhdvzSUgIt6kNkHpy7am9YP9pxpFRcAiutqmoP aub/kK4+S46oYmmbQrOW =ZqhZ -----END PGP SIGNATURE----- --KSxRu3dj3DsWsFaoKfkHaSFSmGEaxt9Mq-- From nobody Wed Apr 9 13:04: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 13C4E1A01B3 for ; Wed, 9 Apr 2014 13:04: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 gRC8q2sxJRxg for ; Wed, 9 Apr 2014 13:04:14 -0700 (PDT) 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 1CDBB1A00DC for ; Wed, 9 Apr 2014 13:04:13 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so3000613wes.30 for ; Wed, 09 Apr 2014 13:04: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=GuhQJdIt5D8gyoeRzAvbFbYlhEFeapmQeONflLa1fL4=; b=vrz9B06dk43QcmF0ZH4sxHR8bwtfFRp48xPwP3HU5OUPIVqzaBDvhI/QHas9rw/F38 CB2AfiXyLa7VbQMjdt0HOpenqTgF01mvipzoWFSbG9q/DqJug2EwjNaWouNMHGuFEden qO8g+nqSbbfaGzcsyKYq92924rWeGoqX2+dBSm9Lz7e0Om9lfSLhC0Ei1UEIeEk0qNf0 cNqzdzw8QPQFmrCLNFcD3os9/3uImUD6fyZQweLe9bLj+wjman/twu+32rxy/5cm8ym+ inRF2uL8AzQT3Z7fpLOdL6vRZq6TaiSjlf7gu/KRMc3YwSFMoK4ssh9GA6IP04OV19sP BngA== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr38752186wib.58.1397073853030; Wed, 09 Apr 2014 13:04:13 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 13:04:12 -0700 (PDT) In-Reply-To: <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 9 Apr 2014 13:04:12 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uQLYOzyOh1iLV_atNDbXV0PFPIE Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 20:04:16 -0000 On 9 April 2014 12:40, Andrei Popov wrote: > things like "HTTP/2 over TLS" and "HTTP/2 over TCP" aren't IDs of individual protocols because they describe entire stacks of protocols A protocol that is layered on another protocol includes all the properties of that protocol in the same way that I gain all the advantages (and disadvantages) of a library when I link to it. But that protocol presents a new API that completely subsumes the included protocol. To the users of that protocol, they see HTTP/2 (over TCP, over IP, over 1Gb Ethernet, over copper) and that is similar, but necessarily different to HTTP/2 (over TLS, over TCP, etc...). Therefore they can - and should - be identified differently. It might be that we use a single identifier to refer to things that are, in all the aspects we care about, identical. That's called generalization, and it might not always be appropriate. The idea that X over Y and X over Z might be nice in theory, but it's rare that this abstraction isn't leaky at some level. There are cases that we might not care to distinguish between, particularly below the IP layer, but even there the effects can be visible. We just pretend really hard that we're properly insulated by all those layers. Better to call X over Y = X1 and X over Z = X2 and avoid the confusion issue. From nobody Wed Apr 9 13: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 4D6551A01BA for ; Wed, 9 Apr 2014 13:24:01 -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 6CflkxOCBOZK for ; Wed, 9 Apr 2014 13:23:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0710C1A0234 for ; Wed, 9 Apr 2014 13:23:58 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.913.9; Wed, 9 Apr 2014 20:23:57 +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.0913.002; Wed, 9 Apr 2014 20:23:56 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MIAAB3aAgAADWwCAAADc8IAACOqAgAAAgsCAAAqZAIAAAW9g Date: Wed, 9 Apr 2014 20:23:56 +0000 Message-ID: <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(189002)(377454003)(24454002)(76576001)(77982001)(92566001)(85852003)(80976001)(19580395003)(19580405001)(83322001)(46102001)(74662001)(31966008)(80022001)(74502001)(86362001)(83072002)(81542001)(79102001)(33646001)(76482001)(20776003)(99396002)(87936001)(74316001)(4396001)(81342001)(2656002)(50986999)(76176999)(54356999)(77096999)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:BBEDC1D5.9FC9436A.FDD111B7.2F1D8AD.20355; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OCNE-0FFd22VC7PUiQXpj6zktDE Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 20:24:01 -0000 QXQgdGhlIHRpbWUgd2hlbiB0aGUgcHJvdG9jb2wgbmVnb3RpYXRpb24gaXMgYmVpbmcgcGVyZm9y bWVkIHZpYSBBTFBOLCB0aGUgY2hvaWNlcyBiZXR3ZWVuIGNvcHBlciBhbmQgcmFkaW8sIEV0aGVy bmV0IGFuZCB0b2tlbiByaW5nLCBUQ1AgYW5kIFVEUCwgVExTIGFuZCBEVExTIGhhdmUgYWxyZWFk eSBiZWVuIG1hZGUuIEF0IHRoZSB0aW1lIEFMUE4gbmVnb3RpYXRpb24gaXMgaW4gcHJvZ3Jlc3Ms IGl0IGlzIHRvbyBsYXRlIHRvIG5lZ290aWF0ZSBsb3dlci1sZXZlbCBwcm90b2NvbHMuIEl0IG1h a2VzIHNlbnNlLCBob3dldmVyLCB0byBuZWdvdGlhdGUgaGlnaGVyLWxldmVsIHByb3RvY29scyB0 byBydW4gd2l0aGluIHRoZSAoRClUTFMgY2hhbm5lbC4NCg0KVGhpcyBpcyB3aHkgSSBmZWVsIHRo YXQgIkhUVFAvMiBvdmVyIFRMUyIgbWFrZXMgbGl0dGxlIHNlbnNlIHNwZWNpZmljYWxseSBpbiB0 aGUgY29udGV4dCBvZiBBTFBOLCBhbmQgIkhUVFAvMiBvdmVyIFRDUCIgbWFrZXMgZXZlbiBsZXNz IHNlbnNlIGluIHRoaXMgY29udGV4dC4gQm90aCBvZiB0aGVzZSBwcm90b2NvbCBzdGFjayBpZGVu dGlmaWVycyBtYXkgYmUgdXNlZnVsIG91dHNpZGUgdGhlIGNvbnRleHQgb2YgQUxQTiwgYXMgeW91 IGNvcnJlY3RseSBleHBsYWluLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBBcHJpbCA5LCAyMDE0IDE6MDQgUE0NClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBQ YXVsIEt5eml2YXQ7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFF1ZXN0aW9ucyBh Ym91dCBBTFBODQoNCk9uIDkgQXByaWwgMjAxNCAxMjo0MCwgQW5kcmVpIFBvcG92IDxBbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IHRoaW5ncyBsaWtlICJIVFRQLzIgb3ZlciBU TFMiIGFuZCAiSFRUUC8yIG92ZXIgVENQIiBhcmVuJ3QgSURzIG9mIA0KPiBpbmRpdmlkdWFsIHBy b3RvY29scyBiZWNhdXNlIHRoZXkgZGVzY3JpYmUgZW50aXJlIHN0YWNrcyBvZiBwcm90b2NvbHMN Cg0KQSBwcm90b2NvbCB0aGF0IGlzIGxheWVyZWQgb24gYW5vdGhlciBwcm90b2NvbCBpbmNsdWRl cyBhbGwgdGhlIHByb3BlcnRpZXMgb2YgdGhhdCBwcm90b2NvbCBpbiB0aGUgc2FtZSB3YXkgdGhh dCBJIGdhaW4gYWxsIHRoZSBhZHZhbnRhZ2VzIChhbmQgZGlzYWR2YW50YWdlcykgb2YgYSBsaWJy YXJ5IHdoZW4gSSBsaW5rIHRvIGl0LiAgQnV0IHRoYXQgcHJvdG9jb2wgcHJlc2VudHMgYSBuZXcg QVBJIHRoYXQgY29tcGxldGVseSBzdWJzdW1lcyB0aGUgaW5jbHVkZWQgcHJvdG9jb2wuICBUbyB0 aGUgdXNlcnMgb2YgdGhhdCBwcm90b2NvbCwgdGhleSBzZWUgSFRUUC8yIChvdmVyIFRDUCwgb3Zl ciBJUCwgb3ZlciAxR2IgRXRoZXJuZXQsIG92ZXIgY29wcGVyKSBhbmQgdGhhdCBpcyBzaW1pbGFy LCBidXQgbmVjZXNzYXJpbHkgZGlmZmVyZW50IHRvIEhUVFAvMiAob3ZlciBUTFMsIG92ZXIgVENQ LCBldGMuLi4pLg0KVGhlcmVmb3JlIHRoZXkgY2FuIC0gYW5kIHNob3VsZCAtIGJlIGlkZW50aWZp ZWQgZGlmZmVyZW50bHkuDQoNCkl0IG1pZ2h0IGJlIHRoYXQgd2UgdXNlIGEgc2luZ2xlIGlkZW50 aWZpZXIgdG8gcmVmZXIgdG8gdGhpbmdzIHRoYXQgYXJlLCBpbiBhbGwgdGhlIGFzcGVjdHMgd2Ug Y2FyZSBhYm91dCwgaWRlbnRpY2FsLiAgVGhhdCdzIGNhbGxlZCBnZW5lcmFsaXphdGlvbiwgYW5k IGl0IG1pZ2h0IG5vdCBhbHdheXMgYmUgYXBwcm9wcmlhdGUuDQoNClRoZSBpZGVhIHRoYXQgWCBv dmVyIFkgYW5kIFggb3ZlciBaIG1pZ2h0IGJlIG5pY2UgaW4gdGhlb3J5LCBidXQgaXQncyByYXJl IHRoYXQgdGhpcyBhYnN0cmFjdGlvbiBpc24ndCBsZWFreSBhdCBzb21lIGxldmVsLiAgVGhlcmUg YXJlIGNhc2VzIHRoYXQgd2UgbWlnaHQgbm90IGNhcmUgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vlbiwg cGFydGljdWxhcmx5IGJlbG93IHRoZSBJUCBsYXllciwgYnV0IGV2ZW4gdGhlcmUgdGhlIGVmZmVj dHMgY2FuIGJlIHZpc2libGUuICBXZSBqdXN0IHByZXRlbmQgcmVhbGx5IGhhcmQgdGhhdCB3ZSdy ZSBwcm9wZXJseSBpbnN1bGF0ZWQgYnkgYWxsIHRob3NlIGxheWVycy4gIEJldHRlciB0byBjYWxs IFggb3ZlciBZID0gWDEgYW5kIFggb3ZlciBaID0gWDIgYW5kIGF2b2lkIHRoZSBjb25mdXNpb24g aXNzdWUuDQo= From nobody Wed Apr 9 13:49: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 F08C91A025E for ; Wed, 9 Apr 2014 13:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.132 X-Spam-Level: *** X-Spam-Status: No, score=3.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh7hedM-Whlo for ; Wed, 9 Apr 2014 13:49:52 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.56.148.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3021A0089 for ; Wed, 9 Apr 2014 13:49:52 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 8805DFC85A64C; Wed, 9 Apr 2014 15:49:51 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 6232AFC85A5F4 for ; Wed, 9 Apr 2014 15:49:51 -0500 (CDT) Received: from [96.231.225.192] (port=56890 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WXzRO-0008DT-Qj for tls@ietf.org; Wed, 09 Apr 2014 15:49:50 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 9 Apr 2014 16:49:47 -0400 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WXzRO-0008DT-Qj X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:56890 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2jsI4hopHfWLERUqsXGe4Z7yLrE Subject: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 20:49:53 -0000 All, Thanks for your comments on the TLS 1.3 process. While the IETF certainly has used competitions in the past, they are generally used to select one document from multiple starting points and then the documents undergo substantial revisions. Even then, there is a fairly mixed track record as WGs often find it very hard to come to a final selection and instead get bogged down in the selection process. In this case, however, our charter provides a clear starting point, namely RFC 5246, and a mandate to minimize the changes to that document. This does not mean that ideas for significant changes are are not welcome, but they should be phrased as revisions to RFC 5246 rather than as a wholesale replacement. The chairs do not believe there is a convincing reason or support to deviate from the plan described in our previous message [1]. Complaints about this process should be addressed to our Area Director, Stephen Farrell. As mentioned in the chairs previous message, we are first addressing the handshake flows, and specifically the cryptographic skeleton for the handshake. We will be holding an interim meeting devoted directly to this topic; expect a message proposing dates for that shortly. Sean Turner for the chairs [1] http://www.ietf.org/mail-archive/web/tls/current/msg11657.html From nobody Wed Apr 9 13:53: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 94B2D1A023F for ; Wed, 9 Apr 2014 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar9WMpTNpw4W for ; Wed, 9 Apr 2014 13:53:51 -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 966321A025E for ; Wed, 9 Apr 2014 13:53:51 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so2951918wes.7 for ; Wed, 09 Apr 2014 13:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ccMv9zp4LceqHacANnjkfguqAmKeaMUSDDKjoAGnTMs=; b=vzjLM9Wajw9uMVgjwIdEcvVDWva+f3gB1DGz1yr/vvAzwUkT3c51BWgHpcZ/CdjSNw STb8KT9Z56G4LCYOfOH1voEic0biegFgqJ3s7Idh58wo7UJJPu1dynyMbmAa8M4ASfbV k65S5vpfmK0c5z5RXF4/+YgXMmZEGjpDDWOeAL8Dza90i7QqQnMUFauNW8kB00NVFKlt 6iuZi8os1uGvy1e4MQ0YqtOMW0f8UFJPSs7w/KUrvWXvTKjcQKvf2n4GV9B6/2A+GVUS U+KLnHcJHEjlPGFpAlEXBx9vF8V3hEMzNpK+HPsAzm09aze2owmhTflGuzPbETPc3+D/ ktNA== MIME-Version: 1.0 X-Received: by 10.180.92.196 with SMTP id co4mr11853233wib.50.1397076830592; Wed, 09 Apr 2014 13:53:50 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 13:53:50 -0700 (PDT) In-Reply-To: <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> Date: Wed, 9 Apr 2014 13:53:50 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OQpj5RjgpUwDrTassHmU52mjU0Q Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 09 Apr 2014 20:53:54 -0000 On 9 April 2014 13:23, Andrei Popov wrote: > This is why I feel that "HTTP/2 over TLS" makes little sense specifically= in the context of ALPN, and "HTTP/2 over TCP" makes even less sense in thi= s context. Both of these protocol stack identifiers may be useful outside t= he context of ALPN, as you correctly explain. Agreed. I think that we only disagree on the scope of the registry. I'll note that we've consensus in httpbis to use the greater scope, and will (reluctantly) establish a separate registry if we need to. We'll probably put in a non-overlapping + inclusion requirement for the ALPN registry to avoid issues. It would be easier for us to just use ALPN's registry. From nobody Wed Apr 9 14:25: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 E60741A025E for ; Wed, 9 Apr 2014 14:25:15 -0700 (PDT) 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 XjpMOwJv62Sf for ; Wed, 9 Apr 2014 14:25:12 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1406E1A0234 for ; Wed, 9 Apr 2014 14:25:11 -0700 (PDT) Received: from localhost (91-64-37-173-dynip.superkabel.de [::ffff:91.64.37.173]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 09 Apr 2014 23:25:10 +0200 id 0000000000020015.000000005345BAB6.000066F6 Date: Wed, 9 Apr 2014 23:25:05 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140409232505.0d6e02b8@hboeck.de> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26358-1397078710-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ld01efp2HiRvimdYzaiLS-O9S0w Subject: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 21:25:16 -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-26358-1397078710-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, It's kinda surprising that nobody yet started a thread on the biggest issue in TLS these days on the TLS WG list. So I make a start. First thought might be "no protocol issue, software bug, not an issue for the TLS standardization process". But I think there is an issue at hand here: We have a severe bug in a rarely used TLS extension. And: This is the second time in just a few days a TLS extension gives headache. We just had the Dual EC paper exposing possible security issues with the Extended Random extension (which luckily never came to life). I see a number of issues here: * Heartbeat extension is enabled in cases where it most likely will never be needed or used (HTTPS), but it still causes problems. That shouldn't be. * Extensions make the protocol more complex. Complexity adds attack surface. Someone recently said "TLS 1.3 sounds like TLS 1.2 minus some features". Probably that's a good way to go forward. IMHO the lesson learned should be: TLS extensions shouldn't be added carelessly, need good justification and shouldn't be overly complex. Same goes for extra ciphers and other things that blow up the protocol variations. * Heartbeat adds some completely unneccessary complexity by having a payload with an arbitrary length. There's no point in that. Fefe wrote something about it (german only): http://blog.fefe.de/?ts=3Dadba343f (I don't like his name blaming but he has a point on heartbeat and payload) Lesson to learn: If it is decided that a new extension is needed it should be as simple as possible. Thoughts? --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-26358-1397078710-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) iQIcBAEBCgAGBQJTRbqxAAoJEKWIAHK7tR5CkI8QALhD50edBjnufz83ZoXS+a+I 1flDPKHspuPT+uEJUluX0MzWOabIOGtDowvVGoIt6gRn4T3+diYjHeuNPweeJ4KR 90p4TrjzwmWpDBqpzLu/MIetsJ8E3RVPir8imhc6XL/n80+BxYbi1FggIA/z7g7V l+EeAtMlkrrNHrUOl2M6xP2pP4T/982wvpDcBU348+CpJpfT1GJ85qVob8tJKkWt GgHbW5cLg+cRQIvAa9c+qMO1U/SqSaW15dDucx7qx0oxeA7+oGPSvrpvm5UxCo0r vRZ5jve8tR4eec1n9uu6sLE/mKGSMk2cnzxeFz8QC1nWWClnVDp5oNfBfW+OUXWB U0O3W8fdkiOD0AxKjb3eclSIetwkprPIR4oXqnBoqnN98Nl3c4kzTfg0i1tn7x5C uQhjVjQ8IjPLzDB6aufLYowMps0BcTnPTUS2NTCYeFrGlSxyKF5BZvXXk5FzS1b7 QdwhfoLaZNdSR3nijqvnYvMwcEXfjKrTC+EsA/y53eQGNB277cZkxoIk22D/NESl SGpn5vyI99jw1OegelXO8zHiRJ+EW1a3EGhAM2gtc9mhmWSRglog2Zs6h/HPWyZz glauyl+hni2i0lT1PxW2ftRo61co3uEMfWn8gFsczdAL/qyufnWuvTO5/yD1yMyY XyRTdDxrk2Tj8wUTYSa+ =t2Xj -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-26358-1397078710-0001-2-- From nobody Wed Apr 9 14:28: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 7BB0A1A02B3 for ; Wed, 9 Apr 2014 14:28:22 -0700 (PDT) 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 sAnTlvpnyvxO for ; Wed, 9 Apr 2014 14:28:21 -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 9F3D01A02B0 for ; Wed, 9 Apr 2014 14:28:21 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so3974994wib.10 for ; Wed, 09 Apr 2014 14:28:20 -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=gEv1vGfO5DGmpFGBaOmYyUNztogoM4dSx5hb1Zxr7hE=; b=xGmbIEx8bD1D/Cy8m9DRPvyKSKQt8aSKHo4eWmfy2qpnfbCRlwUnF4RUA+EmjI5KjL ouQYn4CtqW4+L/6lMOVx3lFCn2fr4R07FKiJnLcDnwvE/Jlg7MRoBORO+ETGaaKt8IwU cxK1tBq/Apb53SRk69YdcmiBHQXezgnnAAY0bD2Iyoa/FKSNCY0+R08u2qlCSdHA67ZW LdFxgmVhXba+sH90EPVLLh99vZmGGREVeJa/fOUTldxKyMHdyo8s5TZlvxh95HKs9oyJ vv1rx+LWTz+f9xQltvWAyC4c+Vw0pObfevc83kQKAS8w0oUiuMM17GUXgrExrQGve0Yq FPbQ== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr39439150wiw.50.1397078900624; Wed, 09 Apr 2014 14:28:20 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 9 Apr 2014 14:28:20 -0700 (PDT) In-Reply-To: <20140409232505.0d6e02b8@hboeck.de> References: <20140409232505.0d6e02b8@hboeck.de> Date: Wed, 9 Apr 2014 14:28:20 -0700 Message-ID: From: Martin Thomson 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/m2pehfz5lyBLOfDe_oUcEeb6HD8 Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 21:28:22 -0000 On 9 April 2014 14:25, Hanno B=C3=B6ck wrote: > If it is decided that a new extension is needed it > should be as simple as possible. That's a motherhood statement. Yes, RFC 6520 could have been simpler, but it does provide a valuable function. The payload included. From nobody Wed Apr 9 15:23: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 8E44B1A03B3 for ; Wed, 9 Apr 2014 15:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.856 X-Spam-Level: **** X-Spam-Status: No, score=4.856 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_38=0.6, 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 vMMZWWnN_IKd for ; Wed, 9 Apr 2014 15:23:36 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 294E71A0300 for ; Wed, 9 Apr 2014 15:23:36 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B4CE236006D for ; Wed, 9 Apr 2014 15:23:35 -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=y2ULtkxc5WD/R0jQtYaDljnymUo=; b=Me12MTSCUks khyxZAlG907Pre+T0oBmQ5ldoeo9MiuoGdPjfN7w3NzM2BwPzjDiQqa7/Io4Z6vg Y3g+pjbbmkazFHs0JnOVEgboixo9NzeI9MUwQLf11tgZa9v2DKeguti8KwIrfGd6 ReGs8TknW1ngUW9HjJrh1fpOuQF1imYI= 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-a86.g.dreamhost.com (Postfix) with ESMTPSA id 684FF36006B for ; Wed, 9 Apr 2014 15:23:35 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p61so3149416wes.27 for ; Wed, 09 Apr 2014 15:23:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.20.65 with SMTP id l1mr11727418wje.39.1397082214132; Wed, 09 Apr 2014 15:23:34 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 9 Apr 2014 15:23:34 -0700 (PDT) In-Reply-To: <20140409232505.0d6e02b8@hboeck.de> References: <20140409232505.0d6e02b8@hboeck.de> Date: Wed, 9 Apr 2014 17:23:34 -0500 Message-ID: From: Nico Williams 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/15EVa9XH02YF_2W0c_pGME663Wc Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 22:23:37 -0000 On Wed, Apr 9, 2014 at 4:25 PM, Hanno B=C3=B6ck wrote: > It's kinda surprising that nobody yet started a thread on the biggest > issue in TLS these days on the TLS WG list. So I make a start. Standard IDL + standard encoding + tooling =3D=3D this type of problem mostly goes away and it's easier to test and fuzz test unit components. TLS has an ad-hoc IDL and encoding, and it IIUC doesn't adhere to its own conventions tightly enough that we could now standardize a compatible IDL+encoding and develop tooling for it. To all who have ever poo-poo'ed ASN.1 and friends I now say: you've definitevly lost the argument. If you don't like one IDL, use another, or develop a new a new one. > I see a number of issues here: I don't agree with all that you say, but even if I did, all of these issues pale by comparison to the IDL/encoding issue. > * Extensions make the protocol more complex. Complexity adds attack > surface. [...] Maybe, but we need extensibility, sometimes to get us out of a hole. No extensibility =3D=3D insecure fallbacks in the future. There are no right answers in some cases. > * Heartbeat adds some completely unneccessary complexity by having a > payload with an arbitrary length. There's no point in that. Fefe > wrote something about it (german only): I don't think it's unnecessary: at least for DTLS it is probably necessary for PMTUD. If we have no use for it in TCP it might be worth turning it off there, but that's fighting the last war by moving complexity elsewhere -- the more DTLS and TLS diverge the less common code can be shared. Nico -- From nobody Wed Apr 9 15: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 0994D1A03AF for ; Wed, 9 Apr 2014 15:27:08 -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 XWgVrW6Z5b_4 for ; Wed, 9 Apr 2014 15:27:06 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 322011A03AD for ; Wed, 9 Apr 2014 15:27:06 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so3554144qcv.15 for ; Wed, 09 Apr 2014 15:27: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:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=F/4S8JLGS3KlsncZQTtEei7TQx7un+BkuBwIWtKc1o0=; b=cWdUH8Odk12WK0pq5qyduIMfxLyZgpxTrqPDOv4V4Ie5a/cwrjExFWxmJHnSvj4Ywg D+IC7vbQgHTlvcjK5tuzxh0yHiF+a/ABrj+VFhSzxh2nUHgpDWv/rIrQPIGYQe6Kp8kA chMsKvhZGtrBi2rXiG/B2i/XC6ksXJNkm6fcZTbXdkVlKoepJLVIQ8ULS8tgIawTlksG AusdbUR+AlOxrnVznmhi4fvzMTTTiJwhMA9DI7fMuSrpfkFEhJS0nLGlefJZAdWexEeu Tfiv3f6p3JDM8bijQwQKSxDTP+ZKDuFIgLj5sL8Z9KMN4MoFCHvsH2qXeZNA8EoWpD7B eu6g== X-Gm-Message-State: ALoCoQnw6++nF5eMcJsbGg3RXXVE7n7Z0q4mlG6FodSlHaAqtZGE+eqy5jycLfcgk8mvzkTYCn6w X-Received: by 10.140.38.37 with SMTP id s34mr15641690qgs.88.1397082425290; Wed, 09 Apr 2014 15:27:05 -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 s13sm4085491qag.19.2014.04.09.15.27.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 15:27:04 -0700 (PDT) Message-ID: <5345C942.703@nthpermutation.com> Date: Wed, 09 Apr 2014 18:27:14 -0400 From: Michael StJohns 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" Content-Type: multipart/alternative; boundary="------------050204020101090003040606" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/--blRRy-Du4mIqSuihocii7JGow Subject: [TLS] draft-stjohns-tls-tls13-crypto-infra-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: Wed, 09 Apr 2014 22:27:08 -0000 This is a multi-part message in MIME format. --------------050204020101090003040606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : TLS Crypto Constructs for Version 1.3 > Author : Michael C StJohns > Filename : draft-stjohns-tls-tls13-crypto-infra-00.txt > Pages : 14 > Date : 2014-04-09 > > Abstract: > This document describes a set of replacements for the TLS > cryptographic constructs for use with TLS1.3 and later. The > constructs used in versions of TLS 1.2 and prior have some issues > with respect to secure implementation using generic security > hardware. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-stjohns-tls-tls13-crypto-infra/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------050204020101090003040606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI.

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : TLS Crypto Constructs for Version 1.3
        Author          : Michael C StJohns
        Filename        : draft-stjohns-tls-tls13-crypto-infra-00.txt
        Pages           : 14
        Date            : 2014-04-09

Abstract:
   This document describes a set of replacements for the TLS
   cryptographic constructs for use with TLS1.3 and later.  The
   constructs used in versions of TLS 1.2 and prior have some issues
   with respect to secure implementation using generic security
   hardware.


The IETF datatracker status page for this draft is:

There's also a htmlized version available at:


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:

_______________________________________________
I-D-Announce mailing list
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------050204020101090003040606-- From nobody Wed Apr 9 15:43: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 BBA301A03FF for ; Wed, 9 Apr 2014 15:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCMXO7Ldbmpt for ; Wed, 9 Apr 2014 15:43: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 1EC7C1A03EA for ; Wed, 9 Apr 2014 15:43:02 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F27C94744F; Wed, 9 Apr 2014 22:43:00 +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 DFE964744E; Wed, 9 Apr 2014 22:43:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D47FB202C; Wed, 9 Apr 2014 22:43:00 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 9 Apr 2014 18:42:59 -0400 From: "Salz, Rich" To: Nico Williams , =?utf-8?B?SGFubm8gQsO2Y2s=?= Date: Wed, 9 Apr 2014 18:42:59 -0400 Thread-Topic: [TLS] Heartbleed / protocol complexity Thread-Index: Ac9UQl05C2EraORjRV67yAu8NiPCuwAAn71A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190A0@USMBX1.msg.corp.akamai.com> References: <20140409232505.0d6e02b8@hboeck.de> 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/pTN8r3gMMfXbqD_1wgVVU_y4nYQ Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 22:43:08 -0000 PiBUTFMgaGFzIGFuIGFkLWhvYyBJREwgYW5kIGVuY29kaW5nLCBhbmQgaXQgSUlVQyBkb2Vzbid0 IGFkaGVyZSB0byBpdHMgb3duIGNvbnZlbnRpb25zIHRpZ2h0bHkgZW5vdWdoIHRoYXQgd2UgY291 bGQgbm93IHN0YW5kYXJkaXplIGEgY29tcGF0aWJsZSBJREwrZW5jb2RpbmcgYW5kIGRldmVsb3Ag dG9vbGluZyBmb3IgaXQuDQoNCkkgd3JvdGUgYSBwYXJzZXIgZm9yICJUTFMgSURMIiBhbmQgcG9z dGVkIGl0IHRvIHRoZSBsaXN0LiAgVGhlcmUgYXJlIGEgaGFuZGZ1bCBvZiBjb3JyZWN0aW9ucyB0 aGF0IG5lZWQgdG8gYmUgbWFkZSBpbiBvcmRlciBmb3IgdGhlIGRlZmluaXRpb25zIHRvIG1hdGNo IHRoZSBkZWZpbmVkIHN5bnRheC4gIFRoZSBiaWdnZXN0IG9uZSBiZWluZyAiQVNOLjFDZXJ0IiBs b29rcyBsaWtlIGEgZmllbGQgbmFtZSwgbm90IGEgdHlwZS4gIFRoZSBwb3N0cyBhcmUgaW4gdGhl IGFyY2hpdmVzLCBpZiBhbnlvbmUgY2FyZXMuICBJJ2xsIG1haWwgdGhlIGNvZGUgdG8gYW55b25l IHdobyBjYXJlcy4NCg0KCS9yJA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXIN CkFrYW1haSBUZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoNCg== From nobody Wed Apr 9 15:43: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 69FA71A02D8 for ; Wed, 9 Apr 2014 15:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.398 X-Spam-Level: *** X-Spam-Status: No, score=3.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.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 GfBzerJ68UBy for ; Wed, 9 Apr 2014 15:43:11 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4E1A03F9 for ; Wed, 9 Apr 2014 15:43:04 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1C75633D076; Wed, 9 Apr 2014 22:43:04 +0000 (UTC) Sender: geoffk@localhost.localdomain To: =?utf-8?b?SGFubm8gQsO2Y2s=?= References: <20140409232505.0d6e02b8@hboeck.de> From: Geoffrey Keating Date: 09 Apr 2014 15:43:03 -0700 In-Reply-To: <20140409232505.0d6e02b8@hboeck.de> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SLuqgmzr88DORIJ1LsaWfM9ZAOk Cc: tls@ietf.org Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 22:43:15 -0000 Hanno B=C3=B6ck writes: > Hi, >=20 > It's kinda surprising that nobody yet started a thread on the biggest > issue in TLS these days on the TLS WG list. So I make a start. >=20 > First thought might be "no protocol issue, software bug, not an issue > for the TLS standardization process". But I think there is an issue at > hand here: We have a severe bug in a rarely used TLS extension. >=20 > And: This is the second time in just a few days a TLS extension gives > headache. We just had the Dual EC paper exposing possible security > issues with the Extended Random extension (which luckily never came to > life). I can add a few more examples: compression and client-initiated renegotiation are two things that were optional to implement, and that some implementations didn't implement and were saved security vulnerabilities by not doing so. I seem to remember that there have also been bugs with NULL or 'export' cipher suites being unexpectedly enabled. I think perhaps the lesson to learn from this is that implementations should probably not aim to be 'complete' or 'full-featured' TLS implementations, but rather only implement what is needed for their target audience; and if they do implement features that only some users will need, disable them by default. From nobody Wed Apr 9 16:06: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 AC20B1A049E for ; Wed, 9 Apr 2014 16:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 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_38=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 zS5MWWvbuddR for ; Wed, 9 Apr 2014 16:06:40 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 339411A04A3 for ; Wed, 9 Apr 2014 16:06:40 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id AAEF82005D10D for ; Wed, 9 Apr 2014 16:06:39 -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=/tKF3dObfGJh1Kf2lJVPvP/ydrw=; b=uzuJy6in2Xx UG6y8uE2AVFeX6QUac2avJBD6R8ninPie74j4wZ7SaWZjABjIhnnYqp4mkeLOl+/ wUzJrLqxIxPQZHtAULAmBQfWL2iGGWXFJ1kiGA1dzdfVfcFgI8c1VQ5NrB+7yExe NPjxKkvK/O4AaEsYHyT84K/14D14O8BQ= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 560562005D10B for ; Wed, 9 Apr 2014 16:06:39 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so3139600wgg.1 for ; Wed, 09 Apr 2014 16:06:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr12125062wib.5.1397084798209; Wed, 09 Apr 2014 16:06:38 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 9 Apr 2014 16:06:38 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190A0@USMBX1.msg.corp.akamai.com> References: <20140409232505.0d6e02b8@hboeck.de> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190A0@USMBX1.msg.corp.akamai.com> Date: Wed, 9 Apr 2014 18:06:38 -0500 Message-ID: From: Nico Williams To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yO3dHgZq2ZflbrZbAfoZ5uH2Zyo Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 23:06:42 -0000 On Wed, Apr 9, 2014 at 5:42 PM, Salz, Rich wrote: >> TLS has an ad-hoc IDL and encoding, and it IIUC doesn't adhere to its ow= n conventions tightly enough that we could now standardize a compatible IDL= +encoding and develop tooling for it. > > I wrote a parser for "TLS IDL" and posted it to the list. There are a ha= ndful of corrections that need to be made in order for the definitions to m= atch the defined syntax. The biggest one being "ASN.1Cert" looks like a fi= eld name, not a type. The posts are in the archives, if anyone cares. I'l= l mail the code to anyone who cares. That's great news. Can you say anything about my "IIUC" above? Nico -- From nobody Wed Apr 9 16:13:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AC1A03E7 for ; Wed, 9 Apr 2014 16:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 11jkfUGlHb5I for ; Wed, 9 Apr 2014 16:13:18 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 481FC1A02D9 for ; Wed, 9 Apr 2014 16:13:18 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id DB4722005D908 for ; Wed, 9 Apr 2014 16:13: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=P2iSNNa/K3YmiinOP50v DPJeMXg=; b=skPJLrRavLCiQcpJMTffNFaH8Mz0MOUhKCqvXxs0yeYClbSr2K9E q285I1UvDYUu8NFK0HBSAx4RW3gxjMigJolvVKvbgWKZN8mkmR9hw0WcrR0ZYSKA m0JYluDlzikqY6Rycva+5vIEgzFljglYx+WkEyPfOq/g2RBEX+75IE4= 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-a110.g.dreamhost.com (Postfix) with ESMTPSA id 900B02005D907 for ; Wed, 9 Apr 2014 16:13:17 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so3154965wgg.2 for ; Wed, 09 Apr 2014 16:13:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.63.46 with SMTP id d14mr11984644wjs.24.1397085196465; Wed, 09 Apr 2014 16:13:16 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Wed, 9 Apr 2014 16:13:16 -0700 (PDT) In-Reply-To: References: <20140409232505.0d6e02b8@hboeck.de> Date: Wed, 9 Apr 2014 18:13:16 -0500 Message-ID: From: Nico Williams To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/npB872B1cI1RwPVGF9O7R-aVwss Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Wed, 09 Apr 2014 23:13:21 -0000 On Wed, Apr 9, 2014 at 5:43 PM, Geoffrey Keating wrote: > I can add a few more examples: compression and client-initiated > renegotiation are two things that were optional to implement, and > that some implementations didn't implement and were saved security > vulnerabilities by not doing so. I agree as to compression: we know well now that compression decisions must not be done at any layer other than that which knows if it's safe to do it, and that layer is never TLS. (This doesn't mean that the app couldn't request that some TLS records be compressed while others not, but that would be needless complexity.) I don't agree as to client-initiated renegotiation. The problem there is that the semantics of renegotiation were not well specified early on, so the APIs that got built too easily ended up failing to be capable of doing the necessary channel binding, so the channel binding didn't get built. (Causality actually went the other way here, I know, but in so far as running code was the source of specification...) > I think perhaps the lesson to learn from this is that implementations > should probably not aim to be 'complete' or 'full-featured' TLS > implementations, but rather only implement what is needed for their > target audience; and if they do implement features that only some users > will need, disable them by default. If you said that apps should get to specify which TLS features they need I'd agree. Non-implementation with no choice in the matter simply leads to non-deployment of important features. There's no need to throw out the baby with the bathwater. Nico -- From nobody Wed Apr 9 18:42: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 D52951A0573 for ; Wed, 9 Apr 2014 18:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxY01v9oBBAo for ; Wed, 9 Apr 2014 18:42:56 -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 570D61A0479 for ; Wed, 9 Apr 2014 18:42:56 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E6B648134; Thu, 10 Apr 2014 01:42:55 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 82AC6480FB; Thu, 10 Apr 2014 01:42:55 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 68EEE1E03D; Thu, 10 Apr 2014 01:42:55 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 9 Apr 2014 21:42:54 -0400 From: "Salz, Rich" To: Nico Williams Date: Wed, 9 Apr 2014 21:42:54 -0400 Thread-Topic: [TLS] Heartbleed / protocol complexity Thread-Index: Ac9USHGIo4RKFVMxTFanSL59E1kVsQAFXlUA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190C1@USMBX1.msg.corp.akamai.com> References: <20140409232505.0d6e02b8@hboeck.de> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190A0@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/fXLbbp1F2IP7LtLCggajq_bM1YE Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Thu, 10 Apr 2014 01:42:57 -0000 Pj4gVExTIGhhcyBhbiBhZC1ob2MgSURMIGFuZCBlbmNvZGluZywgYW5kIGl0IElJVUMgZG9lc24n dCBhZGhlcmUgdG8gaXRzIG93biBjb252ZW50aW9ucyB0aWdodGx5IGVub3VnaCB0aGF0IHdlIGNv dWxkIG5vdyBzdGFuZGFyZGl6ZSBhIGNvbXBhdGlibGUgSURMK2VuY29kaW5nIGFuZCBkZXZlbG9w IHRvb2xpbmcgZm9yIGl0Lg0KDQpJJ20gbm90IHF1aXRlIHN1cmUgd2hhdCB5b3UgbWVhbi4gIEFy ZSB5b3Ugc2F5aW5nIHRoYXQgeW91IHRoaW5rIHRoZSBJREwgZG9lc24ndCBtYXRjaCB3aGF0IGlz IGFjdHVhbGx5IHB1dCBvdXQgb24gdGhlIHdpcmU/ICBPciB0aGUgSURMLT53aXJlIG1hcHBpbmcg aXMgYnJva2VuL3dyb25nIGluIHBsYWNlcywgb3Igd2hhdD8NCg0KSSBoYXZlbid0IGxvb2tlZCBh dCBnZW5lcmF0aW5nICJzdHVicyIgZnJvbSB0aGUgSURMLCBzbyBJIGd1ZXNzIEkgcmVhbGx5IGNh bid0IGNvbW1lbnQuDQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0K QWthbWFpIFRlY2hub2xvZ3kNCkNhbWJyaWRnZSwgTUENCg0K From nobody Wed Apr 9 18:44: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 C99061A064A for ; Wed, 9 Apr 2014 18:44:39 -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_38=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 xWJpg4D4LfNx for ; Wed, 9 Apr 2014 18:44:39 -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 E96201A0479 for ; Wed, 9 Apr 2014 18:44:38 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so2955089ykb.2 for ; Wed, 09 Apr 2014 18:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x8yT9CumusPXe/gQHKVJWgCscN1OalbcGrOpNhmtz+A=; b=tEWUjt9HtysZOxlatIxXcIWhkMnR+WDMO+itdpLGRfADiiXyfh4ovB4yj/zO0mcOwu SfTUSLJpLS0IhcDVot9ucMVnZvdd1dibNWW0bMjqAdiJA+wvoUjwj4zF1lmVuo7VP6aE A4sagubGfe2H9SDrvn+Z7rhsyJuysRv/d2ynBcujYddOMwdQ7HXBiJoB4mKNOBtvzpQo h/niABvif+Q+lKkHPSIHvfIfpxodbrM02YeqnbUuYqd48oWhjZh+3FBT/NTLKrNY3TfL IJ6ToCFW1xkNJ0MDa0YmdwOsapNvsxHfLEbC8KghtEHPqemKHaXHe+XTLBxIyezUKqD8 4Z9g== MIME-Version: 1.0 X-Received: by 10.236.94.197 with SMTP id n45mr18919903yhf.46.1397094278262; Wed, 09 Apr 2014 18:44:38 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 9 Apr 2014 18:44:38 -0700 (PDT) In-Reply-To: References: <20140409232505.0d6e02b8@hboeck.de> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC190A0@USMBX1.msg.corp.akamai.com> Date: Wed, 9 Apr 2014 18:44:38 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/U_k4TXI826BvuyChvPSfKef4uJ0 Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Thu, 10 Apr 2014 01:44:40 -0000 On Wed, Apr 9, 2014 at 4:06 PM, Nico Williams wrote= : > On Wed, Apr 9, 2014 at 5:42 PM, Salz, Rich wrote: >>> TLS has an ad-hoc IDL and encoding, and it IIUC doesn't adhere to its o= wn conventions tightly enough that we could now standardize a compatible ID= L+encoding and develop tooling for it. >> >> I wrote a parser for "TLS IDL" and posted it to the list. There are a h= andful of corrections that need to be made in order for the definitions to = match the defined syntax. The biggest one being "ASN.1Cert" looks like a f= ield name, not a type. The posts are in the archives, if anyone cares. I'= ll mail the code to anyone who cares. > > That's great news. Can you say anything about my "IIUC" above? Parsing an IDL isn't the problem. The problem is developing a validated parser generator for the language which the IDL expresses. The further problem is that the semantics of the Hello messages are extremely ugly. Peter Gutmann compared it to ordering from a Chinese menu at one point when discussing ECC ciphersuites, and I don't think that's the only extension with that property. Even if you succeed in parsing, the extensibility of TLS is (largely) ridiculous. Security protocols and their implementations are part of the TCB. They need to be simple. Sincerely, Watson Ladd --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Apr 9 19:26: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 2985D1A03AF for ; Wed, 9 Apr 2014 19:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.297 X-Spam-Level: ** X-Spam-Status: No, score=2.297 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fls0LRWjuR6 for ; Wed, 9 Apr 2014 19:26:02 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 822161A03B8 for ; Wed, 9 Apr 2014 19:26:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,830,1389704400"; d="scan'208";a="3268849" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 10 Apr 2014 12:19:19 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7403"; a="214260598" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbni.tcif.telstra.com.au with ESMTP; 10 Apr 2014 12:25:44 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 10 Apr 2014 12:25:43 +1000 From: "Manger, James" To: Nico Williams Date: Thu, 10 Apr 2014 12:25:42 +1000 Thread-Topic: [TLS] Heartbleed / protocol complexity Thread-Index: Ac9UQl/PfL3OoE2wRGm5pklbpR6BswAHOZsQ Message-ID: <255B9BB34FB7D647A506DC292726F6E11544D90367@WSMSG3153V.srv.dir.telstra.com> References: <20140409232505.0d6e02b8@hboeck.de> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sCA1PM0R-f8THGDTflZq6A1NB30 Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Thu, 10 Apr 2014 02:26:04 -0000 PiBTdGFuZGFyZCBJREwgKyBzdGFuZGFyZCBlbmNvZGluZyArIHRvb2xpbmcgPT0gdGhpcyB0eXBl IG9mIHByb2JsZW0NCj4gbW9zdGx5IGdvZXMgYXdheSBhbmQgaXQncyBlYXNpZXIgdG8gdGVzdCBh bmQgZnV6eiB0ZXN0IHVuaXQNCj4gY29tcG9uZW50cy4NCj4NCj4gVExTIGhhcyBhbiBhZC1ob2Mg SURMIGFuZCBlbmNvZGluZywgYW5kIGl0IElJVUMgZG9lc24ndCBhZGhlcmUgdG8gaXRzDQo+IG93 biBjb252ZW50aW9ucyB0aWdodGx5IGVub3VnaCB0aGF0IHdlIGNvdWxkIG5vdyBzdGFuZGFyZGl6 ZSBhDQo+IGNvbXBhdGlibGUgSURMK2VuY29kaW5nIGFuZCBkZXZlbG9wIHRvb2xpbmcgZm9yIGl0 Lg0KPg0KPiBUbyBhbGwgd2hvIGhhdmUgZXZlciBwb28tcG9vJ2VkIEFTTi4xIGFuZCBmcmllbmRz IEkgbm93IHNheTogeW91J3ZlDQo+IGRlZmluaXRldmx5IGxvc3QgdGhlIGFyZ3VtZW50LiAgSWYg eW91IGRvbid0IGxpa2Ugb25lIElETCwgdXNlDQo+IGFub3RoZXIsIG9yIGRldmVsb3AgYSBuZXcg YSBuZXcgb25lLg0KDQpJIGFncmVlIE5pY28uDQoNClRoZSBoZWFydGJlYXQgbWVzc2FnZSBpbnZv bHZlZCBpbiB0aGlzIGJ1ZyBpcyBzcGVjaWZpZWQgaW4gUkZDNjUyMCAiVExTIGFuZCBEVExTIEhl YXJ0YmVhdCBleHRlbnNpb24iIGFzOg0KDQogICBzdHJ1Y3Qgew0KICAgICAgSGVhcnRiZWF0TWVz c2FnZVR5cGUgdHlwZTsNCiAgICAgIHVpbnQxNiBwYXlsb2FkX2xlbmd0aDsNCiAgICAgIG9wYXF1 ZSBwYXlsb2FkW0hlYXJ0YmVhdE1lc3NhZ2UucGF5bG9hZF9sZW5ndGhdOw0KICAgICAgb3BhcXVl IHBhZGRpbmdbcGFkZGluZ19sZW5ndGhdOw0KICAgfSBIZWFydGJlYXRNZXNzYWdlOw0KDQpJIHRo aW5rIHRoZSBleGFjdCBzYW1lIGJ5dGVzIG9uIHRoZSB3aXJlIHdvdWxkIGJlIGFjaGlldmVkIHdp dGggdGhlIGZvbGxvd2luZyBhbHRlcm5hdGl2ZS4NCg0KICAgc3RydWN0IHsNCiAgICAgIEhlYXJ0 YmVhdE1lc3NhZ2VUeXBlIHR5cGU7DQogICAgICBvcGFxdWUgcGF5bG9hZDwwLi4yXjE2LTE+Ow0K ICAgICAgb3BhcXVlIHBhZGRpbmdbcGFkZGluZ19sZW5ndGhdOw0KICAgfSBIZWFydGJlYXRNZXNz YWdlOw0KDQpFeHBsaWNpdGx5IGluZGljYXRpbmcgYSB2YXJpYWJsZS1sZW5ndGggZmllbGQgd2l0 aCA8MC4uMl4xNi0xPiBtZWFucyB0aGUgYSB2YWx1ZSBzdGFydHMgd2l0aCBhIGxlbmd0aC4NCkkg d29uZGVyIGlzIHRoaXMgY2hhbmdlIHdvdWxkIGhhdmUgbWFkZSBhIGRpZmZlcmVuY2U/IERvIG1v c3QgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdmFyaWFibGUtbGVuZ3RoIGZpZWxkcyBhdXRvbWF0 aWNhbGx5IHdpdGggc29tZSBsb3dlci1sYXllciBib3VuZHMgY2hlY2tzPyBPciBkbyBtb3N0IGlt cGxlbWVudGF0aW9ucyBsZWF2ZSB0aGlzIHRvIGhlYXJ0YmVhdC1zcGVjaWZpYyBjb2RlPw0KDQot LQ0KSmFtZXMgTWFuZ2VyDQo= From nobody Thu Apr 10 00:17: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 0B35C1A015D for ; Thu, 10 Apr 2014 00:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.073 X-Spam-Level: X-Spam-Status: No, score=-12.073 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 MS4dmdO9gOy7 for ; Thu, 10 Apr 2014 00:17:31 -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 F2B341A00B7 for ; Thu, 10 Apr 2014 00:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=732; q=dns/txt; s=iport; t=1397114250; x=1398323850; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=rf8jANr0KolnZF4XFNfUKYtVo8r5KLOy/33HMuUyNq8=; b=LwBK0KE87ISo1+GRKS3zm41N72BITOL0dje9SJUA25VafRwcqtV8ZhK8 pL0EwXbk6Q7dPmmk+7na6PkW737tMnxNrLBAXRB4s7ABfgDTa3qDEbzbq MDB6XUo1ZWW2DbakjhZ/ewSy4glMZWdCkR9VocJp4M/GDHgfz4GqxeECJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFADdFRlOtJA2N/2dsb2JhbABZgwaBEsVFFnSCLDpRAT5CJwQTh3yaCLI2F44KEQGDe4EUBJRxg22SQoMwgXI5 X-IronPort-AV: E=Sophos;i="4.97,832,1389744000"; d="scan'208";a="316615495" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 10 Apr 2014 07:17:29 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s3A7HTrX015239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 10 Apr 2014 07:17:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.184]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 10 Apr 2014 02:17:29 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS Interim Meeting Thread-Index: AQHPVIzurvBSmcHGDkm8p006GN6CeA== Date: Thu, 10 Apr 2014 07:17:28 +0000 Message-ID: <71FF0D29-AD00-4438-BB30-11F4FFDFB42C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.188] Content-Type: text/plain; charset="us-ascii" Content-ID: <79DE113B8DA40D46A7657121FBF0AC79@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9IXPmhyClXdtkKTr5cReAdCkK4g Subject: [TLS] TLS Interim Meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 07:17:33 -0000 Folks, The chairs want to schedule a TLS WG interim to see if we can close on some= of the handshake flow issues. We hope to get key contributors to this disc= ussion on the dates below. Cisco has agreed to let us use their office in Denver, which is centrally l= ocated and an airline hub. We would like to shoot for 1 1/2 or 2 days. In o= rder to avoid requiring people to travel on the weekend, we were thinking o= f May 13-14 or May 14-15. We will also try to have Webex available for remo= te attendance.=20 If you have an opinion about these dates, please let us know by email by Mo= nday April 14 to tls-chairs@tools.ietf.org. We intend to finalize the date = immediately thereafter. Thanks, [Chairs]= From nobody Thu Apr 10 00:57: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 3A0361A00B6 for ; Thu, 10 Apr 2014 00:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 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.272, 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 vBG035N7-pvb for ; Thu, 10 Apr 2014 00:57:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7156D1A00A3 for ; Thu, 10 Apr 2014 00:57:37 -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 s3A7vWiI005706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Apr 2014 03:57:32 -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 s3A7vUkN003511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 03:57:31 -0400 Message-ID: <1397116649.2419.4.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Hanno =?ISO-8859-1?Q?B=F6ck?= Date: Thu, 10 Apr 2014 09:57:29 +0200 In-Reply-To: <20140409232505.0d6e02b8@hboeck.de> References: <20140409232505.0d6e02b8@hboeck.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jORhdBbrVYaje2W1eD_hl1pp6DE Cc: tls@ietf.org Subject: Re: [TLS] Heartbleed / protocol 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: Thu, 10 Apr 2014 07:57:39 -0000 On Wed, 2014-04-09 at 23:25 +0200, Hanno Böck wrote: > Hi, > > It's kinda surprising that nobody yet started a thread on the biggest > issue in TLS these days on the TLS WG list. So I make a start. [...] > I see a number of issues here: > * Heartbeat extension is enabled in cases where it most likely will > never be needed or used (HTTPS), but it still causes problems. That > shouldn't be. Implementations are free to enable any extensions by default or not. I wouldn't expect the heartbeat extension to be enabled in most implementations. > * Heartbeat adds some completely unneccessary complexity by having a > payload with an arbitrary length. There's no point in that. Fefe > wrote something about it (german only): There is. The heartbeat extension can be used under DTLS to perform path MTU discovery. > http://blog.fefe.de/?ts=adba343f > (I don't like his name blaming but he has a point on heartbeat and > payload) > Lesson to learn: If it is decided that a new extension is needed it > should be as simple as possible. Indeed, and in that case the heartbeat extension is as simple as possible. regards, Nikos From nobody Thu Apr 10 01:14: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 0ECC91A0167 for ; Thu, 10 Apr 2014 01:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 vTjJbv7I1DMS for ; Thu, 10 Apr 2014 01:14:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 164931A0144 for ; Thu, 10 Apr 2014 01:14:11 -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 s3A8E367009904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Apr 2014 04:14: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 s3A8E1jd010609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 04:14:02 -0400 Message-ID: <1397117640.2419.15.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner Date: Thu, 10 Apr 2014 10:14:00 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/coF5SxkIJoIMOgocaJqV868GKKY Cc: tls@ietf.org Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2014 08:14:21 -0000 On Wed, 2014-04-09 at 16:49 -0400, Sean Turner wrote: > All, > > Thanks for your comments on the TLS 1.3 process. > > While the IETF certainly has used competitions in the past, they are > generally used to select one document from multiple starting points > and then the documents undergo substantial revisions. Even then, there > is a fairly mixed track record as WGs often find it very hard to come > to a final selection and instead get bogged down in the selection > process. Hello, That was not an issue with the selection of SSL 3.0, the document that was the basis of this working group. > In this case, however, our charter provides a clear starting point, > namely RFC 5246, and a mandate to minimize the changes to that > document. I am sorry, but I disagree. The charter proposed in [0], does not even mention RFC5246, and its points cannot possibly minimize the changes to RFC5246. It proposes the creation of a new protocol. For example: o Develop a mode that encrypts as much of the handshake as is possible to reduce the amount of observable data to both passive and active attackers. o Develop modes to reduce handshake latency, which primarily support HTTP-based applications, aiming for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes. The aim is also to maintain current security features. If these two are addressed in TLS 1.3, it will be a new protocol whether or not it was based on RFC5246. Even worse it will be a new cryptographic protocol designed in a working group that explicitly says it is not a working group of cryptographers. [0]. http://datatracker.ietf.org/doc/charter-ietf-tls/ regards, Nikos From nobody Thu Apr 10 01:22: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 1A70E1A0158 for ; Thu, 10 Apr 2014 01:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 fDDFuWzz-Z5p for ; Thu, 10 Apr 2014 01:22:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1E1A0153 for ; Thu, 10 Apr 2014 01:22:52 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3A8MmRU016780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Apr 2014 04:22:48 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3A8MkS9005256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 04:22:47 -0400 Message-ID: <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Thu, 10 Apr 2014 10:22:45 +0200 In-Reply-To: References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6HkWzGi7X-xgHbdZsDqzdgn4YTc Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 10 Apr 2014 08:22:53 -0000 On Wed, 2014-04-09 at 08:00 -0700, Watson Ladd wrote: > In fact, because you are the GnuTLS developer, I know exactly what > your bignum library, gmp does. And it isn't pretty: operations can > take different paths depending on argument size, which includes > lopping off zero limbs. Modulo is computed by division, which involves > an instruction that is notoriously variable-time on many > architectures. And how does this affect an ephemeral key exchange? I'll reply for you. It has no effect, because it is an ephemeral key exchange. Being constant time, _matters_ when you do operations on a long-term key, not when you do one operation on a one-time-key. So in the cases where it matters nettle (the crypto library used by gnutls), is constant time, and outperforms all other implementations so far. > Your bignum implementation is also slow. See the point above. I'd be interested to know how you figured that gmp is slow. btw. I never mentioned implementing curve25519 using gmp or otherwise, because I am not going to implement the low level part of it. That's why I asked input from other who plan to implement it. > If you do decide to persist in this folly, reversing the bytes won't > stop you, sadly. But I wish it could. Please keep your poison for yourself. regards, Nikos From nobody Thu Apr 10 07:07: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 A73E91A0280 for ; Thu, 10 Apr 2014 07:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 VL_gJTxhNson for ; Thu, 10 Apr 2014 07:07:45 -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 68BEC1A0277 for ; Thu, 10 Apr 2014 07:07:45 -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 s3AE7cTZ004775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 07:07:39 -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: Date: Thu, 10 Apr 2014 07:07:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8FCBF9A6-5C65-4456-AFB2-CBF300F3A354@vpnc.org> References: To: "" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QCi1-REaZIkD1lnsgWTOBLKQcO8 Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2014 14:07:49 -0000 On Apr 9, 2014, at 1:49 PM, Sean Turner wrote: > Thanks for your comments on the TLS 1.3 process. >=20 > While the IETF certainly has used competitions in the past, they are > generally used to select one document from multiple starting points > and then the documents undergo substantial revisions. Even then, there > is a fairly mixed track record as WGs often find it very hard to come > to a final selection and instead get bogged down in the selection > process. This conflates two different things that people asked for: having people = create full proposals and picking among them, and designing TLS from = security and transport principles unfettered by the current handshake = and message format. I have had plenty of experience with the first in = the IETF, and I agree that it rarely goes well. However, there is good = reason to look at the second. > In this case, however, our charter provides a clear starting point, > namely RFC 5246, and a mandate to minimize the changes to that > document. =20 No, it doesn't say either of those. The actual quote, which the WG = worked hard on, is "With these objectives in mind, the TLS WG will also = place a priority in minimizing gratuitous changes to TLS." > This does not mean that ideas for significant changes are > are not welcome, but they should be phrased as revisions to RFC 5246 > rather than as a wholesale replacement. The chairs do not believe > there is a convincing reason or support to deviate from the plan > described in our previous message [1]. Complaints about this > process should be addressed to our Area Director, Stephen Farrell. Instead of formulating it as a "complaint", it would be more helpful to = formulate it as a question. Stephen: do you support the chairs' = interpretation that the charter prevents the WG from designing TLS from = security and transport principles unfettered by the current handshake = and message format? --Paul Hoffman= From nobody Thu Apr 10 08:49:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360C81A0281 for ; Thu, 10 Apr 2014 08:49:39 -0700 (PDT) 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_05=-0.5, 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 SpyZpsKkqa_0 for ; Thu, 10 Apr 2014 08:49:37 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A05F81A027C for ; Thu, 10 Apr 2014 08:49:37 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id b6so4028761yha.33 for ; Thu, 10 Apr 2014 08:49:36 -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=esTabkn39C1/8ZYOXALhUHlXYl5Lvh1igPgjlACQHdk=; b=tjisr0FLIbJuHMeooNdNDjFBFMNzaSnf5Zjb9VJ8NbXByNdmHvEPbZ/73ExyUUpp0n aUjLeBAPtNLclEwpjnFBlGMfSH43M/KE2ysJtqHHfED+VC4nnOjI9N4oYz62qyM8RCuJ mYHkoIdV1SWRFxvuS0I9v82H34Cb4KciYIPS8tbGenH8X6QwxBkaUUHtGrj6yTf0Q4j3 MS6aak1QuInibbrkG2ky5TM06sNKZ/KQJ103gGPDTlvQxjnxGCcWgRbZebPxMeizVQRu N8zMdgOtiY/ByrHQkVvHYgOZvImF0x5+8y1agdSbV3UYS1ty8R2JJQWR9Em7/700LPLr IaPQ== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr24330221yhh.66.1397144976598; Thu, 10 Apr 2014 08:49:36 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 10 Apr 2014 08:49:36 -0700 (PDT) In-Reply-To: <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 10 Apr 2014 08:49:36 -0700 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kZ4OKcYzKAh82q6yKmSZJKg5BCI Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 10 Apr 2014 15:49:39 -0000 On Thu, Apr 10, 2014 at 1:22 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-04-09 at 08:00 -0700, Watson Ladd wrote: > >> In fact, because you are the GnuTLS developer, I know exactly what >> your bignum library, gmp does. And it isn't pretty: operations can >> take different paths depending on argument size, which includes >> lopping off zero limbs. Modulo is computed by division, which involves >> an instruction that is notoriously variable-time on many >> architectures. > > And how does this affect an ephemeral key exchange? I'll reply for you. > It has no effect, because it is an ephemeral key exchange. Not so: if I have a side channel that leaks to a local attacker, ephemeral keys are just as vulnerable as long term keys. Furthermore, Curve25519 can be used with long-term DH keys also. > > Being constant time, _matters_ when you do operations on a long-term > key, not when you do one operation on a one-time-key. So in the cases > where it matters nettle (the crypto library used by gnutls), is constant > time, and outperforms all other implementations so far. Of Curve25519? Do you have publicly verifiable benchmark data for this? For P256 I'd be a little surprised: AGL and Shay Gureon have put a lot of work into optimized assembler implementations. > >> Your bignum implementation is also slow. > > See the point above. I'd be interested to know how you figured that gmp > is slow. GMP works for \mathbb{Z} very well. But it can't ever skip a reduction or a carry because you might ask it a question that requires it to have an answer fully reduced in the next step. If I know that I'm working modulo Z/pZ for some p, then I can pick representatives in any ring with a morphism to Z/pZ. This extra freedom can only help, never hurt. > > btw. I never mentioned implementing curve25519 using gmp or otherwise, > because I am not going to implement the low level part of it. That's why > I asked input from other who plan to implement it. > >> If you do decide to persist in this folly, reversing the bytes won't >> stop you, sadly. But I wish it could. > > Please keep your poison for yourself. "You" refers to everyone who wants to do this themselves. I wouldn't implement it myself either. The point is that all curves need to be treated by largely separate code for the field arithmetic for the optimum in performance. A byte swap is really not going to keep anyone from implementing Curve25519: I see no reason to fight this holy war. Sincerely, Watson Ladd > > regards, > Nikos > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Apr 10 10:31: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 3205E1A01FF for ; Thu, 10 Apr 2014 10:31:13 -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 Lgf3WRST8Z4p for ; Thu, 10 Apr 2014 10:31:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id 5248C1A01F4 for ; Thu, 10 Apr 2014 10:31:11 -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.913.9; Thu, 10 Apr 2014 17:31:09 +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.0913.002; Thu, 10 Apr 2014 17:31:08 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Questions about ALPN Thread-Index: AQHPVAwD6prj8AzZTkKDdBgq+zM49ZsJcpOAgAAG2gCAAAXYgIAACgUwgAAKrgCAAAH9MIAAB3aAgAADWwCAAADc8IAACOqAgAAAgsCAAAqZAIAAAW9ggAAMbwCAAVTBMA== Date: Thu, 10 Apr 2014 17:31:08 +0000 Message-ID: <6c33eca449c34ca29f205e3c60856e7b@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51444003)(24454002)(189002)(199002)(13464003)(377454003)(85852003)(86362001)(46102001)(99396002)(87936001)(19580405001)(83072002)(77982001)(4396001)(76482001)(2656002)(76176999)(50986999)(54356999)(74316001)(77096999)(83322001)(92566001)(79102001)(33646001)(20776003)(81342001)(81542001)(80976001)(31966008)(74502001)(19580395003)(76576001)(74662001)(80022001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:F7DDF1E5.23D1D3E9.BDE2A7BC.4CC69989.2023D; 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/yTgGq5qDd4dg4ud2CDANxwe7DS4 Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 10 Apr 2014 17:31:13 -0000 V2VsbCwgSSBmZWVsIHN0cm9uZ2x5IGVub3VnaCBhYm91dCB0aGlzIHRvIHRyeSBhbmQgZXhwbGFp biBteSBwb3NpdGlvbiBvbiB0aGUgbWFpbGluZyBsaXN0LiBIb3dldmVyLCBJdCBpcyBtdWNoIG1v cmUgaW1wb3J0YW50IHRvIG1lIHRoYXQgQUxQTiBiZSB1c2VmdWwgZm9yIEhUVFAvMiwgc28gaWYg dGhlICJleHBlcnQgcmV2aWV3IiBwcm9jZXNzIGFwcHJvdmVzIGFkZGluZyB5b3VyIHByb3RvY29s IHN0YWNrIElEcyB0byB0aGUgQUxQTiByZWdpc3RyeSwgSSB3aWxsIG5vdCBvYmplY3QgOikNCg0K Q2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1h cnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgQXByaWwgOSwgMjAxNCAxOjU0IFBNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogUGF1 bCBLeXppdmF0OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBRdWVzdGlvbnMgYWJv dXQgQUxQTg0KDQpPbiA5IEFwcmlsIDIwMTQgMTM6MjMsIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiBUaGlzIGlzIHdoeSBJIGZlZWwgdGhhdCAiSFRU UC8yIG92ZXIgVExTIiBtYWtlcyBsaXR0bGUgc2Vuc2Ugc3BlY2lmaWNhbGx5IGluIHRoZSBjb250 ZXh0IG9mIEFMUE4sIGFuZCAiSFRUUC8yIG92ZXIgVENQIiBtYWtlcyBldmVuIGxlc3Mgc2Vuc2Ug aW4gdGhpcyBjb250ZXh0LiBCb3RoIG9mIHRoZXNlIHByb3RvY29sIHN0YWNrIGlkZW50aWZpZXJz IG1heSBiZSB1c2VmdWwgb3V0c2lkZSB0aGUgY29udGV4dCBvZiBBTFBOLCBhcyB5b3UgY29ycmVj dGx5IGV4cGxhaW4uDQoNCkFncmVlZC4NCg0KSSB0aGluayB0aGF0IHdlIG9ubHkgZGlzYWdyZWUg b24gdGhlIHNjb3BlIG9mIHRoZSByZWdpc3RyeS4gIEknbGwgbm90ZSB0aGF0IHdlJ3ZlIGNvbnNl bnN1cyBpbiBodHRwYmlzIHRvIHVzZSB0aGUgZ3JlYXRlciBzY29wZSwgYW5kIHdpbGwNCihyZWx1 Y3RhbnRseSkgZXN0YWJsaXNoIGEgc2VwYXJhdGUgcmVnaXN0cnkgaWYgd2UgbmVlZCB0by4gIFdl J2xsIHByb2JhYmx5IHB1dCBpbiBhIG5vbi1vdmVybGFwcGluZyArIGluY2x1c2lvbiByZXF1aXJl bWVudCBmb3IgdGhlIEFMUE4gcmVnaXN0cnkgdG8gYXZvaWQgaXNzdWVzLiAgSXQgd291bGQgYmUg ZWFzaWVyIGZvciB1cyB0byBqdXN0IHVzZSBBTFBOJ3MgcmVnaXN0cnkuDQo= From nobody Thu Apr 10 13:28: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 0B21D1A03BA for ; Thu, 10 Apr 2014 13:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sstrkGfL1SlW for ; Thu, 10 Apr 2014 13:28:25 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB31A0073 for ; Thu, 10 Apr 2014 13:28:25 -0700 (PDT) Message-ID: <5346FEDE.9000909@akr.io> Date: Thu, 10 Apr 2014 21:28:14 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MJfxaiQmHQY0YPj9BWhSBySbWSc Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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: Thu, 10 Apr 2014 20:28:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/04/2014 09:22, Nikos Mavrogiannopoulos wrote: > And how does this affect an ephemeral key exchange? Assuming all side-channel attacks require repetition seems like the kind of rather dangerous thinking that has bought TLS very unpleasant surprises in the past. We've had quite enough of those already, I think. Curve25519 was designed _specifically_ so that it can use a lovely, extremely fast, constant-time Montgomery ladder: if you're not using that, frankly, you're doing it wrong. (Section 5 of the draft already addresses that, on my reading.) > That's why I asked input from other who plan to implement it. OK. Try _not_ to make your own implementation, especially not using a generic bignum library: you'll both have side-channel problems, and your performance will suck compared to the existing implementations. Several liberally-licensed, extremely good, highly-optimised, correct implementations of Curve25519 already exist: libsodium, for example. They're probably better in every way than one you (or I) could write. Practical implementation on most platforms in software therefore pretty much consists of taking a good implementation; carefully building scaffolding around it to plug it in; very thoroughly testing that; and that's it. This draft is, very simply, the standards part of that 'scaffolding'. Given big-endian is the 'wrong way round' from what comes out of and goes into literally every one of these implementations, it seems a bit silly to ask basically everyone to byte-swap for no reason when we could just... not. That's why I say use the existing little-endian format. It's not a holy war, it just feels utterly pragmatic in this case, just because it's simpler that way. Given bugs like Heartbleed, goto fail, the recent GnuTLS one (that doesn't have a cute name as far as I know?), and doubtless, many more to come - the simpler we can make that scaffolding, the less opportunity there is overall to screw it up. That's my take on it, anyway. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTRv7eAAoJEOyEjtkWi2t6Ef0P/jA3q3ahnLwY92wSByDmYVtD xZSXJFXFaJ/mF3h9ix94b55T5+Oyzr2pcOdbItW5AriG8PP3Rs702N7PXaIZWS8l SAEHMBB2bNWFlbwttpVLfrGqWdYIcjXhD/IDsiU+hRXs5K7Gb1DHM8Y8RLylNDTz xGpHGs1lJAc8ubLIKU3axXMavTbJWfHo8icou4EWiIqoFz1uR1rxUwhcSPg2CT7N IJNDD/Ap+4Mkcuo/L3r8jjzD9EN5PkuQUGGLgmT3WyZNMx/XMLbkrn/1eKOafjMc QpFbLA7dq0dGAtpW47U1kNcivO/eAX/Xq6LftTcQ15dZZgcEORIG60BxS5rsaudZ 0+frOMuTd0Dxv7g/1Zr4+ADK4C8vibSZUSMv19A1uA5chKzEqsjssndiNpfqy/WZ yGn/edoemDwE+jdVhHEQh4qZxycXJdqfAyg1M8FhUxahzFxEFnv/RlW54kgqULaQ He0OTB+lwMWbHQDXp9Aj2PcDdyFyA5QHWwjF8+zpDKhIB87aV30LEw1P3upwvtYG CZJ9XLqJz39GwRGGN+liugakBpWAyNFoOGnb5WvpUEdq1INEdUFHul2eQV0nF374 KXaHadVV32I1tQ7ECVVrv69/1xqWBAm0eC+LGgf9Cz+wT7chvAWf85/5u7QkvBJo KRCoFogKpVV9DXmCcUp+ =++Qz -----END PGP SIGNATURE----- From nobody Thu Apr 10 14:53: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 458141A01BA for ; Thu, 10 Apr 2014 14:53:04 -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 3sYijwY-caiV for ; Thu, 10 Apr 2014 14:53:00 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DDD9F1A01AF for ; Thu, 10 Apr 2014 14:52:59 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E9AEB50A85; Thu, 10 Apr 2014 17:52:55 -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: <71FF0D29-AD00-4438-BB30-11F4FFDFB42C@cisco.com> Date: Fri, 11 Apr 2014 07:52:50 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <14EAA221-7B54-4F58-8F36-33F8EC9E4F34@mnot.net> References: <71FF0D29-AD00-4438-BB30-11F4FFDFB42C@cisco.com> To: "Joseph Salowey (jsalowey)" , Eric Rescorla X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AAGDIeRteU8wqpj3WhaYJXHVj-Y Cc: "" Subject: Re: [TLS] TLS Interim Meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 21:53:04 -0000 On 10 Apr 2014, at 5:17 pm, Joseph Salowey (jsalowey) = wrote: > Denver, which is centrally located Are we the US-IETF now? Seriously, I know a lot of participants are from the US, but it doesn't = do any good to actively bait the people who have to travel further. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Thu Apr 10 16:55: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 425961A0390 for ; Thu, 10 Apr 2014 16:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.02 X-Spam-Level: ** X-Spam-Status: No, score=2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 mL_gvxAKLrfZ for ; Thu, 10 Apr 2014 16:55:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0063F1A035B for ; Thu, 10 Apr 2014 16:55:01 -0700 (PDT) Received: from [192.168.37.142] ([64.134.222.118]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Me86g-1WLow03LsE-00PshE; Fri, 11 Apr 2014 01:54:59 +0200 Message-ID: <5346E261.6070602@gmx.net> Date: Thu, 10 Apr 2014 11:26:41 -0700 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson , =?UTF-8?B?SGFubm8gQsO2Y2s=?= References: <20140409232505.0d6e02b8@hboeck.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r6dIb7hs47pDq0XpiNx9QvSA9bQWHJLuw" X-Provags-ID: V03:K0:V+C+YSixHbaTBy/H/I7zTS/bz796YbocIaF/pO2lp/1dNsvDWiP ZnA/5x4AFt1K+xUQCHAfu9Zgsl/nodY0ecmDhnZRGEA5kK0WoRHID0Uy/ZWgV/kEgxlyNDV sPrdTPo1pLcSaIHnAhws1avmso6c3NX09YQOi9Z3fVs3BtLzm9ZJqv7raVgkyO6ORLLa1ye 3J/iip9OZQ8S6P3x8PdnQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CAZqhnC_jN1G_ncKPyyH4Ahoq8I Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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: Thu, 10 Apr 2014 23:55:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r6dIb7hs47pDq0XpiNx9QvSA9bQWHJLuw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hanno, I agree with Martin regarding your the statement about simplicity. We always try to make extensions as simple as possible. Questions that come to my mind are: Have you provided comments at the time when RFC 6520 was written? Have you helped to improve the OpenSSL implementation of RFC 652= 0? There is an underlying problem that needs to be addressed, namely that we produce specifications but once we are done with the specifications we (as an organization) don't seem to care about what happens afterwards. Someone there is the impression that the developer community implements our protocols quickly and in the way we want. Assuming the existence of code that is available to the public does not necessarily mean that it is bug-free. We have many examples of this behaviour throughout the IETF (i.e., there is nothing unique to TLS). In the past I had argued that we need to take the transition from the specification (paper) to the actual implementation a bit more serious but, unfortunately, I found very little support for it. Just to give you a pointer to my most recent write-up on this topic have a look at my STRINT paper: https://www.w3.org/2014/strint/papers/62.pdf Ciao Hannes On 04/09/2014 04:28 PM, Martin Thomson wrote: > On 9 April 2014 14:25, Hanno B=C3=B6ck wrote: >> If it is decided that a new extension is needed it >> should be as simple as possible. >=20 > That's a motherhood statement. Yes, RFC 6520 could have been simpler, > but it does provide a valuable function. The payload included. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --r6dIb7hs47pDq0XpiNx9QvSA9bQWHJLuw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTRuJhAAoJEGhJURNOOiAtU5EH/jvJSlolOA3maHCI+wNOoDqG juSOlQoTF8mS+Tw6esjeT6qbNkrOHJwQrzhxW9jNozP42XKbRMAeSK5/7en0r3n/ TzGBla8eY+F497tjDXep0iWyJ1zVhZdhs8MCNd0e9TClRMU5S4DmXLAaUwPmqaXJ oB03z+M2PoicwBoyyEMb4uWqEdHn0ptaDqVAEfyzLPnqhz8wtqG3s+LoOohPrYhG 0+Hk+86TOMpFQKzWqdpVEuUiEil41AEDbn6v7AbuUj1Ht+HLBpfd9ZkMWw5glm00 BiK8JG71/vD4sVVkqhxNfsySYVkiU7efubpvMhqEpj+JeMRIe39zymKOu7ldhPs= =2d2e -----END PGP SIGNATURE----- --r6dIb7hs47pDq0XpiNx9QvSA9bQWHJLuw-- From nobody Thu Apr 10 17:20: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 B9BCC1A039B for ; Thu, 10 Apr 2014 17:20:41 -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 zXVOrcyWwgQh for ; Thu, 10 Apr 2014 17:20:37 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A61A0397 for ; Thu, 10 Apr 2014 17:20:37 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Apr 2014 20:20:31 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 20:20:30 -0400 From: Dan Brown To: Hannes Tschofenig , Martin Thomson , =?iso-8859-1?Q?Hanno_B=F6ck?= Thread-Topic: [TLS] Heartbleed / protocol complexity Thread-Index: AQHPVDo3MCEdaygBCECVzacoYA9MQpsKD9sAgAFflICAAB/Nzw== Date: Fri, 11 Apr 2014 00:20:30 +0000 Message-ID: <20140411002030.6672532.52002.12768@certicom.com> References: <20140409232505.0d6e02b8@hboeck.de> , <5346E261.6070602@gmx.net> In-Reply-To: <5346E261.6070602@gmx.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/jUmYJ9JUlj0GB09hd8W6KmRUyHI Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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, 11 Apr 2014 00:20:41 -0000 Could some test vectors have helped prevent this bug? Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Hannes Tschofenig Sent: Thursday, April 10, 2014 7:55 PM To: Martin Thomson; Hanno B=F6ck Cc: tls@ietf.org Subject: Re: [TLS] Heartbleed / protocol complexity Hi Hanno, I agree with Martin regarding your the statement about simplicity. We always try to make extensions as simple as possible. Questions that come to my mind are: Have you provided comments at the time when RFC 6520 was written? Have you helped to improve the OpenSSL implementation of RFC 6520? There is an underlying problem that needs to be addressed, namely that we produce specifications but once we are done with the specifications we (as an organization) don't seem to care about what happens afterwards. Someone there is the impression that the developer community implements our protocols quickly and in the way we want. Assuming the existence of code that is available to the public does not necessarily mean that it is bug-free. We have many examples of this behaviour throughout the IETF (i.e., there is nothing unique to TLS). In the past I had argued that we need to take the transition from the specification (paper) to the actual implementation a bit more serious but, unfortunately, I found very little support for it. Just to give you a pointer to my most recent write-up on this topic have a look at my STRINT paper: https://www.w3.org/2014/strint/papers/62.pdf Ciao Hannes On 04/09/2014 04:28 PM, Martin Thomson wrote: > On 9 April 2014 14:25, Hanno B=F6ck wrote: >> If it is decided that a new extension is needed it >> should be as simple as possible. > > That's a motherhood statement. Yes, RFC 6520 could have been simpler, > but it does provide a valuable function. The payload included. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Apr 10 19:25:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5BF1A000A for ; Thu, 10 Apr 2014 19:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 1Ma9KCCZVR9J for ; Thu, 10 Apr 2014 19:24:50 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC51A0391 for ; Thu, 10 Apr 2014 19:24:46 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id 29so4755750yhl.34 for ; Thu, 10 Apr 2014 19:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8MXHXBZ+QnBe+MpzAPoysgntiAe4e4BGFm9mU/YUk/Q=; b=mdGfasR1/fzC3+ciFcIjMwmF4p1ifN0sePeaKJn9rA6cOneVhgg4+bIfiuofV/tIZ/ 7jLdRaWlr+imrSMrOOc+4zFHslsJSkMNdPbJYKLi+h5hszFlyF/V6fjGUB4ouRqEdFvj DnI9pZ37/44LirSSZ/BzmuWRgHGUkh4iRv0pXi21aEakR/mAXfp43BHVteaUjpF1adj7 4FOhzWz8wamrJfp76rH94IuJJwBNCDX/Y2rlwMchLMwSeA8rNIjMRT2lGwIjaKeJmIWD 6gbPcffiQjuvXy8R9DWnJNjQE/n+v5Lce2yQ3KCrKf/cU+UhpZk2RzfjcITIwNzj2a6b Tcbg== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr8662483yhp.102.1397183085385; Thu, 10 Apr 2014 19:24:45 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 10 Apr 2014 19:24:45 -0700 (PDT) In-Reply-To: <20140411002030.6672532.52002.12768@certicom.com> References: <20140409232505.0d6e02b8@hboeck.de> <5346E261.6070602@gmx.net> <20140411002030.6672532.52002.12768@certicom.com> Date: Thu, 10 Apr 2014 19:24:45 -0700 Message-ID: From: Watson Ladd To: Dan Brown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v49UvEX2LACfIfsTIWGWmrQTTeI Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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, 11 Apr 2014 02:24:57 -0000 On Thu, Apr 10, 2014 at 5:20 PM, Dan Brown wrote: > Could some test vectors have helped prevent this bug? Systematically ensuring that all invalid length combinations would have triggered an error would have worked. That's more than some test vectors. Furthermore, it's not clear how you supply test vectors to a protocol implementation: it can be done, and should be, but it is quite a bit of work. What could have mitigated this bug would be not disabling OS protection measures in malloc. Had OpenSSL not used their own malloc, then on OpenBSD the malloc flags "FGJZ" would have significantly reduced the impact of the attack, and quite possibly crashed the process if exploitation was tried. (OpenSSL has bugs that are only found when you disable their own malloc wrapper, which is why they didn't do it). Various proposals for taint analysis in C have floated around for a number of years. However, qmail demonstrates that one can write secure C code without this assistance. Even a typedef int untrust len, followed by a compiler that warns of aliasing and a perl script that brings special attention onto casts from this type (okay, not so easy to write: you need to track declarations) would have been useful. Furthermore, there was no need to implement heartbeats over TLS for web servers. The TLS wire format is a pain to parse, and you need to handle it even after ending the handshake. However, the fundamental problem isn't anything more than the developers of OpenSSL being lackadaisical about security. Entire multiuser operating system kernels (xv6 to be precise) can be fitted into one fifth the code size of OpenSSL. PolarSSL is one tenth the size, and does the same job. miTLS does a much better job, is in a high level language, costs 10x as much in computation time, and is guaranteed to be correct. (It doesn't do X509 verification however, and I don't believe side channels are reasoned about: both are fixable without much more code). Sincerely, Watson Ladd > > Sent from my BlackBerry 10 smartphone on the Rogers network. > Original Message > From: Hannes Tschofenig > Sent: Thursday, April 10, 2014 7:55 PM > To: Martin Thomson; Hanno B=C3=B6ck > Cc: tls@ietf.org > Subject: Re: [TLS] Heartbleed / protocol complexity > > > Hi Hanno, > > I agree with Martin regarding your the statement about simplicity. We > always try to make extensions as simple as possible. Questions that come > to my mind are: Have you provided comments at the time when RFC 6520 was > written? Have you helped to improve the OpenSSL implementation of RFC 652= 0? > > There is an underlying problem that needs to be addressed, namely that > we produce specifications but once we are done with the specifications > we (as an organization) don't seem to care about what happens > afterwards. Someone there is the impression that the developer community > implements our protocols quickly and in the way we want. Assuming the > existence of code that is available to the public does not necessarily > mean that it is bug-free. > > We have many examples of this behaviour throughout the IETF (i.e., there > is nothing unique to TLS). > > In the past I had argued that we need to take the transition from the > specification (paper) to the actual implementation a bit more serious > but, unfortunately, I found very little support for it. Just to give you > a pointer to my most recent write-up on this topic have a look at my > STRINT paper: https://www.w3.org/2014/strint/papers/62.pdf > > Ciao > Hannes > > On 04/09/2014 04:28 PM, Martin Thomson wrote: >> On 9 April 2014 14:25, Hanno B=C3=B6ck wrote: >>> If it is decided that a new extension is needed it >>> should be as simple as possible. >> >> That's a motherhood statement. Yes, RFC 6520 could have been simpler, >> but it does provide a valuable function. The payload included. >> >> _______________________________________________ >> 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 Apr 11 00:33: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 5F71E1A0107 for ; Fri, 11 Apr 2014 00:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.275 X-Spam-Level: X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 i-pEREv5xTGf for ; Fri, 11 Apr 2014 00:33:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 070051A0106 for ; Fri, 11 Apr 2014 00:33:48 -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 s3B7Xjgd014693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 03:33:45 -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 s3B7XhsI023164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 11 Apr 2014 03:33:44 -0400 Message-ID: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Alyssa Rowan Date: Fri, 11 Apr 2014 09:33:42 +0200 In-Reply-To: <5346FEDE.9000909@akr.io> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> <5346FEDE.9000909@akr.io> 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/0Bhruq-WNKyjaL-LH5KFcVYreC0 Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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, 11 Apr 2014 07:33:50 -0000 On Thu, 2014-04-10 at 21:28 +0100, Alyssa Rowan wrote: > > And how does this affect an ephemeral key exchange? > Assuming all side-channel attacks require repetition seems like the > kind of rather dangerous thinking that has bought TLS very unpleasant > surprises in the past. We've had quite enough of those already, I think. Could you elaborate on how to achieve repetition on a protocol that runs only once with the same key? I find your argumentation hard to follow. > Curve25519 was designed _specifically_ so that it can use a lovely, > extremely fast, constant-time Montgomery ladder: if you're not using > that, frankly, you're doing it wrong. (Section 5 of the draft already > addresses that, on my reading.) I never questioned that, it will be very appropriate when one can use it with static keys (i.e., ECDH - which are not in this draft). My comment is for the existing draft that uses the curve for an ephemeral key exchange, and were directed to the overplay of the relevance of constant time (as you do here) without understanding whether it is relevant for the threats on the protocol under discussion. So to recap, being constant time is a good thing, but not very relevant for ECDHE. regards, Nikos From nobody Fri Apr 11 00:53: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 BCCD11A041E for ; Fri, 11 Apr 2014 00:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 n6rCWLZc_Rkb for ; Fri, 11 Apr 2014 00:53:45 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id D8E111A041D for ; Fri, 11 Apr 2014 00:53:44 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com> References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> <5346FEDE.9000909@akr.io> <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Fri, 11 Apr 2014 08:53:37 +0100 CC: tls@ietf.org Message-ID: <72d7c28c-0022-497a-b5ca-3d36a6727e39@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jbSi8y_dtz1aJKODWJtAXREiK2Y Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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, 11 Apr 2014 07:53:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11 April 2014 08:33:42 BST, Nikos Mavrogiannopoulos wrote: >> Assuming all side-channel attacks require repetition seems like the >> kind of rather dangerous thinking that has bought TLS very unpleasant >> surprises in the past. We've had quite enough of those already, I think. >Could you elaborate on how to achieve repetition on a protocol that runs >only once with the same key? I find your argumentation hard to follow. Perhaps you misunderstand. Naïvely assuming that every dangerous side-channel attack absolutely needs amplification via repetition is, I feel, optimistic (or, depending on your point of view, pessimistic). (And if I ever develop such a one-shot attack, I shall name it something like #yolo, because cute attack names are in vogue.) That's the kind of thinking that got us 20:20 hindsight gems like '[this timing attack] is not believed to be large enough to be exploitable'. Please let's be more careful. Using good Curve25519 implementations gives us the opportunity to eliminate potential side-channels. Don't waste that opportunity. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTR5+BGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t69IgQALHjPUyvVhmPWiFH1V3MA1j0RZQBNT+zpguRmby9fp/Vi2VHdQDK R49WKn5Lrtiqm20qELgsGS7lAFS0a0H3twTmZ/p6Cw9BBlOlcpaWU9bxBYvbQgGD Ch0W4z+Nqz13LeeYy5909/JcQYEQp8YBzqtU/x4pMnlxPxQwicuKQr0KTrrEHRy5 XAW3zbo9XLz8zn2FMNCioHwMuK0zq3LZz4b5zRitotrtKR3KePgWddenr1NY9ooH A4Fm1D7VEmB9ABcYMefKAPQeMBnVFx906EHYeyGFZ1QqlefmyDDGla/7FBIcbUoA oiRCcfnj7ZbbkgPun2lPoY2xKhtAvHkkxTeNcZC+5aqEnEZakG6tCWtzZfRuu+oa utYtTBR6kghlO73EhhSBpnadFCM4+H0h+1n9Wbr6LT5T8ZXYZ3TSglCcUzlsb0s9 7CYSI+BsMz5V4gov/5ulriBq5TKumKcEAXrbumnYjamphqBrscw9F4lRhIaUOFRT yUA2t4+lNJUrdm28iCzkcZ7b1vF49KlBmFSRmvRYgPQki2PO3u0FDDb714sc5xr/ g3Nat95ZCMjxXGKWREcXg2r0qQcjdAS6xuDaWGblfx+8CThapBknk5PUjm5tgqCg +AGDLdJ26xfUyFMURgUjM7i3xRP1uT2VjuUmUHuEfD2rX4oXMKjzfoTV =JeFt -----END PGP SIGNATURE----- From nobody Fri Apr 11 01:05: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 2FED81A044A for ; Fri, 11 Apr 2014 01:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 c-POKSWWjxlM for ; Fri, 11 Apr 2014 01:05:11 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 040241A0445 for ; Fri, 11 Apr 2014 01:05:11 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 35F93161AF; Fri, 11 Apr 2014 10:05:06 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 3A80A29043; Fri, 11 Apr 2014 10:05:05 +0200 (CEST) Message-ID: <5347A22B.9000903@polarssl.org> Date: Fri, 11 Apr 2014 10:04:59 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , Alyssa Rowan References: <87ob3456s1.fsf@latte.josefsson.org> <20140402164340.GA14790@roeckx.be> <20140407115102.3011d2e5@latte.josefsson.org> <5344BD77.2020106@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18CAE@USMBX1.msg.corp.akamai.com> <1397044231.4019.4.camel@dhcp-2-127.brq.redhat.com> <4abda243-3fc2-4087-92f8-3db02769384f@email.android.com> <1397048457.4019.22.camel@dhcp-2-127.brq.redhat.com> <1397118165.2419.23.camel@dhcp-2-127.brq.redhat.com> <5346FEDE.9000909@akr.io> <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1397201622.2324.13.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EQucI8BjmVo1_RkSeilZXVDhg4A Cc: tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in 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, 11 Apr 2014 08:05:13 -0000 On 11/04/2014 09:33, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-04-10 at 21:28 +0100, Alyssa Rowan wrote: > >>> And how does this affect an ephemeral key exchange? >> Assuming all side-channel attacks require repetition seems like the >> kind of rather dangerous thinking that has bought TLS very unpleasant >> surprises in the past. We've had quite enough of those already, I think. > > Could you elaborate on how to achieve repetition on a protocol that runs > only once with the same key? I find your argumentation hard to follow. > I think Alyssa's point was not that you can achieve repetetion, but that progress in the attacks may some day lead to powerful attacks that don't need repetition at all. How much information the attacker can get in one pass depends on many factors, such as the attacker's abilities (noised timing only and real-time power trace are very different settings) and the implementation techniques. With a naive double-and-add algorithm (on a short Weierstrass curve, no using unified formulas) and an attacker able to get a precise enough power trace, I don't believe the attacker needs repetition to get the full ephemeral key. Of course this is a fairly extreme example, but I think it shows side-channels are not entirely irrelevant for ephemeral keys, at least in some contexts. That said, I agree that side-channels are probably much less of a threat for ephemeral keys than for long-term keys in most settings. Manuel. From nobody Fri Apr 11 03:37: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 B32291A03B6 for ; Fri, 11 Apr 2014 03:37:43 -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 j1mg9drd1tLz for ; Fri, 11 Apr 2014 03:37:41 -0700 (PDT) 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 B1E471A01E6 for ; Fri, 11 Apr 2014 03:37:26 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so4511015veb.2 for ; Fri, 11 Apr 2014 03:37:25 -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=42ejT+ybFBwOZG/brPGF3I1v8PncsItA/BovHRJEivI=; b=SIWqSjtnJE6FUsSgmHm5ELu3gNpAcVoZt7R7HNu6y1S/CO7W7F2E5/vXpK2fmEe+7+ aLjjVIPDXzpPpppxRyPs/4wk7+8h7J5UZGnYYvwjOqw3FO8fsHnjhNM+G1HUBRbJyaRz vSsLBG/HBwT1DrfTggSRKphP3VgIvkYXGrP2cun91WyT01t0HndBladiqQFnAoQB2hbN I5UvBz37o7f6VN4vF7GVQ+38MCSRh1VLBBHDYZT4ugDW81S+XTZzvsssTeq07Qa+0AMw ZAtD6Nhk61gDz5MRXLmQD4Va3PnZP5DuJ7Lf9kcyqGtQ38zE5+6XJO7wJoXVVRyO3rON oynQ== MIME-Version: 1.0 X-Received: by 10.220.59.65 with SMTP id k1mr6349753vch.22.1397212645318; Fri, 11 Apr 2014 03:37:25 -0700 (PDT) Received: by 10.220.78.74 with HTTP; Fri, 11 Apr 2014 03:37:25 -0700 (PDT) In-Reply-To: <6c33eca449c34ca29f205e3c60856e7b@BL2PR03MB419.namprd03.prod.outlook.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <6c33eca449c34ca29f205e3c60856e7b@BL2PR03MB419.namprd03.prod.outlook.com> Date: Fri, 11 Apr 2014 14:37:25 +0400 Message-ID: From: Mohamad Badra To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11c295026667c504f6c1ebdd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MFvlVVNZ8zmhEdkg6cQ9ns13Avg Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2014 10:37:43 -0000 --001a11c295026667c504f6c1ebdd Content-Type: text/plain; charset=UTF-8 Hi, I believe the registration process should not be tied to ANPL. The simplest thing is to define a portfolio (in a separated document or in a section in your document) to define the name of the new protocols. BTW, in 2007, I have submitted a document on MTLS protocol to multiplex several application sessions over a single TLS session. I think you didn't read the draft, but your document is a use-case of it (see draft-badra-hajjeh-mtls-02). The TLS WG co-chairs (during 2007-2008) were aware of the document and of the patent as well. Best regards, Badra On Thu, Apr 10, 2014 at 9:31 PM, Andrei Popov wrote: > Well, I feel strongly enough about this to try and explain my position on > the mailing list. However, It is much more important to me that ALPN be > useful for HTTP/2, so if the "expert review" process approves adding your > protocol stack IDs to the ALPN registry, I will not object :) > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, April 9, 2014 1:54 PM > To: Andrei Popov > Cc: Paul Kyzivat; tls@ietf.org > Subject: Re: [TLS] Questions about ALPN > > On 9 April 2014 13:23, Andrei Popov wrote: > > This is why I feel that "HTTP/2 over TLS" makes little sense > specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less > sense in this context. Both of these protocol stack identifiers may be > useful outside the context of ALPN, as you correctly explain. > > Agreed. > > I think that we only disagree on the scope of the registry. I'll note > that we've consensus in httpbis to use the greater scope, and will > (reluctantly) establish a separate registry if we need to. We'll probably > put in a non-overlapping + inclusion requirement for the ALPN registry to > avoid issues. It would be easier for us to just use ALPN's registry. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c295026667c504f6c1ebdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I believe the registration process should not be tied to ANPL. The simplest= thing is to define a portfolio (in a separated document or in a section in= your document) to define the name of the new protocols.

BTW, in 2007, I have submitted a document on MTLS protocol to = multiplex several application sessions over a single TLS session. I think y= ou didn't read the draft, but your document is a use-case of it (see=C2= =A0draft-badra-hajjeh-mtls-02). The TLS WG co-chairs (during 2007-2008) wer= e aware of the document and of the patent as well.

Best regards,
Badra


On Thu, Apr 10, 2014 at 9:31 PM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:
Well, I feel strongly enough about this to t= ry and explain my position on the mailing list. However, It is much more im= portant to me that ALPN be useful for HTTP/2, so if the "expert review= " process approves adding your protocol stack IDs to the ALPN registry= , I will not object :)

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Wednesday, April 9, 2014 1:54 PM
To: Andrei Popov
Cc: Paul Kyzivat; tls@ietf.org
Subject: Re: [TLS] Questions about ALPN

On 9 April 2014 13:23, Andrei= Popov <Andrei.Popov@micro= soft.com> wrote:
> This is why I feel that "HTTP/2 over TLS" makes little sense= specifically in the context of ALPN, and "HTTP/2 over TCP" makes= even less sense in this context. Both of these protocol stack identifiers = may be useful outside the context of ALPN, as you correctly explain.

Agreed.

I think that we only disagree on the scope of the registry. =C2=A0I'll = note that we've consensus in httpbis to use the greater scope, and will=
(reluctantly) establish a separate registry if we need to. =C2=A0We'll = probably put in a non-overlapping + inclusion requirement for the ALPN regi= stry to avoid issues. =C2=A0It would be easier for us to just use ALPN'= s registry.
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c295026667c504f6c1ebdd-- From nobody Fri Apr 11 07:26:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6491A06B2 for ; Fri, 11 Apr 2014 07:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpMgzODizoLZ for ; Fri, 11 Apr 2014 07:26:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 93D821A06B4 for ; Fri, 11 Apr 2014 07:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 622BBBEBE; Fri, 11 Apr 2014 15:26:18 +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 wf81i+QhhCH5; Fri, 11 Apr 2014 15:26:18 +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 17EA2BEBC; Fri, 11 Apr 2014 15:26:18 +0100 (IST) Message-ID: <5347FB8A.1050407@cs.tcd.ie> Date: Fri, 11 Apr 2014 15:26:18 +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: Paul Hoffman , "" References: <8FCBF9A6-5C65-4456-AFB2-CBF300F3A354@vpnc.org> In-Reply-To: <8FCBF9A6-5C65-4456-AFB2-CBF300F3A354@vpnc.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/_mv-ejBQPMw0avH_pHxz24ZSWOY Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2014 14:26:23 -0000 Hi Paul, On 04/10/2014 03:07 PM, Paul Hoffman wrote: > On Apr 9, 2014, at 1:49 PM, Sean Turner wrote: > >> Thanks for your comments on the TLS 1.3 process. >> >> While the IETF certainly has used competitions in the past, they >> are generally used to select one document from multiple starting >> points and then the documents undergo substantial revisions. Even >> then, there is a fairly mixed track record as WGs often find it >> very hard to come to a final selection and instead get bogged down >> in the selection process. > > This conflates two different things that people asked for: having > people create full proposals and picking among them, and designing > TLS from security and transport principles unfettered by the current > handshake and message format. I have had plenty of experience with > the first in the IETF, and I agree that it rarely goes well. I fully agree with you and the chairs on that. > However, > there is good reason to look at the second. > >> In this case, however, our charter provides a clear starting >> point, namely RFC 5246, and a mandate to minimize the changes to >> that document. > > No, it doesn't say either of those. The actual quote, which the WG > worked hard on, is "With these objectives in mind, the TLS WG will > also place a priority in minimizing gratuitous changes to TLS." > >> This does not mean that ideas for significant changes are are not >> welcome, but they should be phrased as revisions to RFC 5246 rather >> than as a wholesale replacement. The chairs do not believe there is >> a convincing reason or support to deviate from the plan described >> in our previous message [1]. Complaints about this process should >> be addressed to our Area Director, Stephen Farrell. > > Instead of formulating it as a "complaint", it would be more helpful > to formulate it as a question. Stephen: do you support the chairs' > interpretation that the charter prevents the WG from designing TLS > from security and transport principles unfettered by the current > handshake and message format? Nicely constructed question:-) Short answer: Yes I support the chairs, but I don't think the question you asked is that useful, nor can it be at this level of abstraction, until the WG have reached consensus on more of the features of TLS1.3. Put another way, I think what the chairs have said is fine, but does not "prevent the WG from designing TLS from security and transport principles" that deviate from "the current handshake and message format." (I did s/unfettered by/that deviate from/ there as I don't think unfettered is a useful term here - who'd want to be fettered?;-) Of course the WG might come to consensus that large (non-gratuitous) changes are needed and I don't think the chairs are saying such would not be allowed. However, I also assume that implementers are interested in less, rather than more, change, so starting from 5246 seems entirely reasonable to me. I do not think the chairs are saying that TLS1.3 has to look almost the same as 5246 though - the delta will depend on how discussions go about which features to add/keep/change/drop. And I also don't believe that the chairs have ruled out deciding at some point that the delta has gotten so big that re-organising the text entirely, or re-starting from a blank sheet might be right. (Though I'd be surprised if that last made sense to be honest.) I do think that there is a benefit for implementers if the TLS1.3 RFC ends up having a simpler delta from 5246 but at the same time we are discussing some possibly significant changes. Its up to the WG to figure those out and the chairs to manage that process and judge the consensus. I think what the chairs are saying (and they'll correct me if I'm wrong) is that for each proposed change they'd like that change discussed as a delta from 5246, and they have set out a rough ordering of when to discuss which TLS1.3 features and on that basis starting editing from 5246 text at some point seems just sensible to me. And to give a concrete but deliberately not realistic example, (to try avoid ratholing on it) I do think it'd be ok for someone to propose replacing the TLS specific encoding of structured data with XML if they cast that proposal in terms of a delta from 5246, and if the WG had consensus on that then that'd be in line with what the chairs have proposed. But I guess that there'd be a pretty high bar to get over there in terms of convincing implementers that such a change would be a good plan even if you replaced XML with something that someone might suggest. Hope that helps, S. > > --Paul Hoffman > From nobody Fri Apr 11 07:50: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 929A81A0466 for ; Fri, 11 Apr 2014 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.021, 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 UEOF8_PZNcRn for ; Fri, 11 Apr 2014 07:49:58 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 68D001A06F3 for ; Fri, 11 Apr 2014 07:49:56 -0700 (PDT) Received: from localhost (91-66-81-95-dynip.superkabel.de [::ffff:91.66.81.95]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 11 Apr 2014 16:47:52 +0200 id 0000000000020045.0000000053480098.000030EB Date: Fri, 11 Apr 2014 16:47:46 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= Cc: "tls@ietf.org" Message-ID: <20140411164746.5503c4f8@hboeck.de> In-Reply-To: References: <20140409232505.0d6e02b8@hboeck.de> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-12523-1397227672-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LXsO8UiAyOG66HYwC690Betn9hU Subject: Re: [TLS] Heartbleed / protocol 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, 11 Apr 2014 14:49:59 -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-12523-1397227672-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 9 Apr 2014 14:28:20 -0700 Martin Thomson wrote: > On 9 April 2014 14:25, Hanno B=C3=B6ck wrote: > > If it is decided that a new extension is needed it > > should be as simple as possible. >=20 > That's a motherhood statement. Yes, RFC 6520 could have been simpler, > but it does provide a valuable function. The payload included. While we're at it: Can anyone name me what real-world applications use TLS Heartbeat with TCP? Or any use at all? I'm really asking out of curiosity. Because I read so much about the whole thing and nowhere was anything mentioned at all. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-12523-1397227672-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) iQIcBAEBCgAGBQJTSACSAAoJEKWIAHK7tR5CdlkQAKm78Mk+qQLez+01gBf5ejSX PEnWiyEYpRYfYmpOTHnD9Rj519A+A9y2SNRx0H7ers+lmsTWxnnkTkP5Lb9Zrj6B q0eVQdU0CR5XuA1VaKwR+AE08cba3Ika5vbjpkZAdUBObG4m6O63GzJHBduAj0Ut HoIZ019g97kOimC3Riu2BDobSfrXQJNcu1zYpPafMfsR2hEjJu0R2NifJZrPcRXx 0WWeEU67w/p9P6LojdFuCrJFu0bObZHIzTXhDEsthokbNDF2ZjZ/xR6YZWV/Z6ne e7JCsDdbms6AfQOVGVqj8TASzk9L0jOJimbEnza/mm+EdL2PSgh8dpYoc4PbgmyK 7T14SrrVsgb4ltpJmQq6MUCjXjgMFIlu3jeA5n1bbpQtGh3N1aJatiEJ+Vhgylsx zhTCW8J5IREAdikrUbfs3WabV4Jxaxh+rgF/xDJqW0vcnj7QTqv/jNyQ9iUpjRjj ZtellD/zSeFM5JopZGXrsAecF2qKAEDA2FkVZdZurgLLxztdMhmLDMuM/yISyBxg +56rbsY7dYkMnkKdCbtD4xxVkspAHcT0QXFmnzYO+9cqFVOPnwmgXjhDHeqFD7xr 3G8TCIEyjeeaZIwZ2AfXIroeMlwye80PKfqjPKy9HAHWJvzmGyJFQ6H/XZMulZt2 YZvGRflgyytnlUnMGmUT =aZUU -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-12523-1397227672-0001-2-- From nobody Fri Apr 11 08:49: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 353531A06D0 for ; Fri, 11 Apr 2014 08:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 6tt38av6nIA6 for ; Fri, 11 Apr 2014 08:49:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA11A0145 for ; Fri, 11 Apr 2014 08:49:56 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3BFnqfY006520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Apr 2014 17:49:52 +0200 (MEST) In-Reply-To: <20140411164746.5503c4f8@hboeck.de> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Fri, 11 Apr 2014 17:49:52 +0200 (CEST) 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: <20140411154952.070971ACBC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rk2e_qyMQf8HS_RfS_BPyYQxvZo Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol complexity 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, 11 Apr 2014 15:49:58 -0000 Hanno B=F6ck wrote: >=20 > While we're at it: > Can anyone name me what real-world applications use TLS Heartbeat with > TCP? Or any use at all? Stuff like QUANTUMINSERT and FOXACID possibly. -Martin From nobody Fri Apr 11 08: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 EA5431A06EC for ; Fri, 11 Apr 2014 08:55:30 -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 cUMB2z4ZrAHF for ; Fri, 11 Apr 2014 08:55:30 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADC1A06A0 for ; Fri, 11 Apr 2014 08:55:29 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 79so5028021ykr.23 for ; Fri, 11 Apr 2014 08:55:28 -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=zTP4NcZYtbgNwdEeobtgrEEDzpvEpq+qcpYVd3bLqlw=; b=ZxWO+XkQ6JSoXj1uh53/dDWCe2Y3rJk4kqGIWc/BBt2mxSmLPhbnqjYZZ+49N2UNpt 2Yq1DY7ceUiORQSAk14ZtvjARq91hlsPQkDFRRTLal+77CelYMKa5Rb9L2vQG07Wrk54 oLxTsSWYLZgEWzemuJMmLgjPWFvkMsVRGhPakFSMCKXYZFtR8W0OR6PspRKPKCRb4Oni CW2I3cYG3LEIduUhYMBFqn6VxhebYBYbe+b3BCMBMfutLzDRtPGe7jNriwJl/7b7Aejw uIPlzWgNnHLdetGjgx5tvsfyEE0nx1YgDbHO8J57G+iJPWpscf717uEBGg/1b4HUhEm3 r0zA== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr33222446yhj.63.1397231728496; Fri, 11 Apr 2014 08:55:28 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 11 Apr 2014 08:55:28 -0700 (PDT) Date: Fri, 11 Apr 2014 08:55:28 -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/g2sNKr673HmgkYkodGErw-gN6Us Subject: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 15:55:31 -0000 Dear all, Professor Gutman has generously cleaned up the mess left by this WG. The draft looks good to me. Before you all go pontificate about TLS 1.3, I strongly suggest fixing TLS 1.2, and I think this draft solves one of the three problems out there. (We still need a 1/n-1 draft for TLS 1.0, and a RC4 die-die-die draft. But UTA seems to be doing that, except no one actually wants to kill RC4) Sincerely, Watson Ladd From nobody Fri Apr 11 09:01: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 3FF5E1A0701 for ; Fri, 11 Apr 2014 09:01:26 -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 fJo_RgMK2Aos for ; Fri, 11 Apr 2014 09:01:24 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1A81A06FC for ; Fri, 11 Apr 2014 09:01:23 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id z6so5479334yhz.7 for ; Fri, 11 Apr 2014 09:01:22 -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=oymUCVY0GERK3x2YVa0gzcclHulwQavKai3Gp0l0WK0=; b=URU+zbqZXGampfoj0b1cJl9vnoY2DzoiNd8FNwvERlmYlIyJPgU1fHhwhQNKnsS7yB 1PtODsf0NzzzhYnE2RCldsdSUhweDCl2dM7IlQieQWDW0AsuFQji47Sd9gbuNm/cZavS u4XQ8WVeSS3dBcQxCt1lwHmqWBanW+1fCz5GOXgT+C6ss2O7giNlQmxHJHfVtwB0Wf6/ 2iUg2KOhDbCxWE19ew4DW6gP+H4qyDY3VUp/N8GxvyOnAQkFXY8Yd/OYvKyTSs/i0dhL XN5EvuIn1zjomGYNU5f8xYCnO/DtnnVXyVMg2zV/PnLOtAEA59jNl/0Uqi+OlJfF+Br/ IPoQ== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr33270450yhj.63.1397232081940; Fri, 11 Apr 2014 09:01:21 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 11 Apr 2014 09:01:21 -0700 (PDT) Date: Fri, 11 Apr 2014 09:01:21 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" , Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_xpqUfld-M6ie7DEUAA4uI6XXxE Subject: [TLS] The beauty of asking implementors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 11 Apr 2014 16:01:26 -0000 Dear all, Rich Salz, after listing three options from conservative to radical, "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)." AGL:"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." Peter Gutman: "Absolutely! I don't want to have to add yet another parallel implementation of a protocol that's just different enough that it's yet another set of code and functionality to test, alongside SSLv3, TLS 1.0, and TLS 1.2. All of the previous updates have been compatible enough that you don't want to do a new implementation, but incompatible enough that it's a different protocol. Make 1.3 purely fixes for 1.2 and then start again with 2.0 so we can ditch all the old baggage, complexity, and attack surface." So that's the biggest site using TLS, the Chromium TLS person, and Professor Gutman all stating their lack of interest in TLS 1.3 as currently imagined. Currently the chairs are working backwards: fixing the handshake (which has one secure mode) and not the record layer (which has AES-GCM) first. (Of course, the TLS 1.2 document describes neither: you need to look at the Suite B for ECDHE_ECDSA, and somewhere else for ECDHE_RSA, and AES-GCM) I don't see how this is at all the right set of priorities. Fixing known bugs should come before new features in any security project. The implementers seem to agree with this perspective. I'm not seeing a compelling argument from the chairs, explaining why they think TLS 1.3 should take priority over fixing TLS, just "trust us". Sincerely, Watson Ladd From nobody Fri Apr 11 09:17: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 E23571A06EC for ; Fri, 11 Apr 2014 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 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, 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 oFXTdjznHOcU for ; Fri, 11 Apr 2014 09:17:39 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C332A1A02C5 for ; Fri, 11 Apr 2014 09:17:33 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 75B5554058 for ; Fri, 11 Apr 2014 09:17:32 -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=49Z4BMDBm8vV8jzAyA8JRZI5O+w=; b=J3tH/gQqJim r7q7BTroUmPYDKPH4cb4PqdRdib/n6ZvPveSuuTZ24UiP5OYtksXPMld4FEm3g/l uxNxt1OVLIWWlylVEVHfc1z0vTMSt+yvUSS0xjvhgxOORdYnXlqdFLcMQs0gdPml Omb51mZCRZiBWynLQd815n+BILzNfFe0= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 2A0C654075 for ; Fri, 11 Apr 2014 09:17:32 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm4so1292067wib.8 for ; Fri, 11 Apr 2014 09:17:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr3063483wic.5.1397233050805; Fri, 11 Apr 2014 09:17:30 -0700 (PDT) Received: by 10.217.129.197 with HTTP; Fri, 11 Apr 2014 09:17:30 -0700 (PDT) In-Reply-To: <20140411164746.5503c4f8@hboeck.de> References: <20140409232505.0d6e02b8@hboeck.de> <20140411164746.5503c4f8@hboeck.de> Date: Fri, 11 Apr 2014 11:17:30 -0500 Message-ID: From: Nico Williams 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/kzuRVHaF_00BGo-egspScStutJU Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbleed / protocol 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, 11 Apr 2014 16:17:44 -0000 On Fri, Apr 11, 2014 at 9:47 AM, Hanno B=C3=B6ck wrote: > While we're at it: > Can anyone name me what real-world applications use TLS Heartbeat with > TCP? Or any use at all? I can't think of existing applications that need it in TLS-over-TCP today. For DTLS (over UDP, natch) this extension is needed for PMTUD. Nico -- From nobody Fri Apr 11 10:01: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 001101A0286 for ; Fri, 11 Apr 2014 10:01:22 -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 3Zb8GhEudbqb for ; Fri, 11 Apr 2014 10:01:21 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE281A0709 for ; Fri, 11 Apr 2014 10:01:21 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so5553841wes.23 for ; Fri, 11 Apr 2014 10:01:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ACFOB1fmI/5q3Q0Wqrc3jNAWZ7sivV6wLnpoqnanT9Y=; b=lsC51u6LooMNsNy7vbh3fuFpRDYnfNuNwxTBrnSUULRVDrDr8gVytTCH+995v7t2gT zw02zXCdIrCDkzSgzKR35+7EoMsZKae7AENVdoD74omXt9vUFJOrFZISv/ggM52+184p J30pThcSIqQUvwgcIammqDvRzGicPlHHKC01AXyTbj8AXJr3jd/NWac9TtzDFf6l+Wad gsDjZ16gEHami6o2F0Ou8yyyhN6YX/gcyhJJVq3RDR718+CexQo/+uK82eIHxS6k5S7i LuvTUJxaVKP0cyzHjEwAEw+gAr5m3huMRwGYRa1/C1Sirf9FN5DvqIhBNAoMb0oPiGzc Rwqg== X-Gm-Message-State: ALoCoQmalLmtzhLWb2dPGyDDSClZWJNhMHDD8Q+N25mYcLL1k28SiXVJzrzXwy2FbzSJ0hXL556I X-Received: by 10.180.211.70 with SMTP id na6mr4363308wic.1.1397235679253; Fri, 11 Apr 2014 10:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 11 Apr 2014 10:00:39 -0700 (PDT) X-Originating-IP: [74.95.2.168] From: Eric Rescorla Date: Fri, 11 Apr 2014 10:00:39 -0700 Message-ID: To: draft-ietf-tls-encrypt-then-mac@tools.ietf.org, "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c261dc547d7b04f6c74890 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AxwjfCyLmA01iTs-4DYtV10iAII Subject: [TLS] Comments on draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:01:23 -0000 --001a11c261dc547d7b04f6c74890 Content-Type: text/plain; charset=ISO-8859-1 I have just reviewed Peter's revised draft-ietf-tls-encrypt-then-mac document. Generally, I think this is ready to go. I found the following issues which I think should be resolved prior to publication: 1. The code point is listed as 21 in two locations, but that has been provisionally assigned to the padding extension. I suggest that you change this to the next open number, which is 22. The WG could probably ask for a provisional assignment, but given that this is the only major extension document in process and it will be going to the IESG soon, I don't think that that's necessary. 2. IMO you should point to draft-moeller in the Security Considerations. 3. Section 3.1 mentions an interop server. I wonder if this should be removed prior to publication unless it is intended to stay up forever. 4. It would probably be useful to include syntax for DTLS in Section 3. 5. Is Section 3.1 intended to say that you MUST NOT negotiate backwards? That seems OK, but you should probably say this explicitly. 6. Section 5 should have a placeholder for IANA's extension definition. Something like: "IANA [should allocate/has allocated] extension number 22 (0x16) for this extensions." (This is how we conventionally signal which code point we want). 7. In Section 3, it might be useful to call back to the TLS specification which describes how the connection must fail. E.g., "For TLS, a fatal bad_record_mac MUST be generated (see RFC 5246 Section 7.2.2). For DTLS, the record MUST be discarded and a fatal bad_record_mac MAY be generated, as described in RFC 6347 Section 4.1.2.1) -Ekr --001a11c261dc547d7b04f6c74890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have just reviewed Peter's revised draft-ietf-tls-en= crypt-then-mac document.

Generally, I think this is read= y to go.

I found the following issues which I thin= k should be resolved prior to publication:

1. The code point is listed as 21 in two locations, but= that has been
=A0provisionally assigned to the padding extension= . I suggest that you
=A0change this to the next open number, whic= h is 22. The WG could
=A0probably ask for a provisional assignment, but given that this is
=A0the only major extension document in process and it will be goi= ng
=A0to the IESG soon, I don't think that that's necessa= ry.


2. IMO you should point to draft-moeller= in the Security Considerations.


3.= Section 3.1 mentions an interop server. I wonder if this should be
removed prior to publication unless it is intended to stay up forever.=


4. It would probably be useful to = include syntax for DTLS in Section 3.


5. Is Section 3.1 intended to say that you MUST NOT negotiate backward= s?
That seems OK, but you should probably say this explicitly.


6. Section 5 should have a placeholde= r for IANA's extension definition.
Something like:

"IANA [should allocate/h= as allocated] extension number 22 (0x16) for this
extensions.&quo= t;

(This is how we conventionally signal which cod= e point we want).


7. In Section 3, it might be useful to c= all back to the TLS specification which
describes how the connect= ion must fail. E.g.,

"For TLS, a fatal bad_re= cord_mac MUST be generated (see RFC 5246
Section 7.2.2). For DTLS, the record MUST be discarded and a fatal
bad_record_mac MAY be generated, as described in RFC 6347 Section 4.= 1.2.1)

-Ekr



=A0 =A0
--001a11c261dc547d7b04f6c74890-- From nobody Fri Apr 11 10:24: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 895641A070D for ; Fri, 11 Apr 2014 10:24:07 -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 oBrDiyTTY3Db for ; Fri, 11 Apr 2014 10:24:05 -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 BE98F1A070A for ; Fri, 11 Apr 2014 10:24:05 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 11 Apr 2014 17:24:03 +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.0913.002; Fri, 11 Apr 2014 17:24:03 +0000 From: Andrei Popov To: Watson Ladd , "tls@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-encrypt-then-mac Thread-Index: AQHPVZ56UyGLyyEP206Tqre9fJuddpsMp1mA Date: Fri, 11 Apr 2014 17:24:02 +0000 Message-ID: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(189002)(199002)(92566001)(76576001)(80976001)(81542001)(77982001)(85852003)(99286001)(19580395003)(83322001)(19580405001)(46102001)(74662001)(31966008)(79102001)(80022001)(86362001)(74502001)(83072002)(76482001)(20776003)(15202345003)(86612001)(15975445006)(33646001)(54356999)(76176999)(50986999)(74316001)(4396001)(99396002)(81342001)(77096999)(2656002)(87936001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:7468712C.9C35AF29.BEEAB298.642CD948.20205; 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/l8qRx8HzJK348vWiEDWLQHR5a2w Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:24:07 -0000 > (We still need a 1/n-1 draft for TLS 1.0, and a RC4 die-die-die draft. Here's an RC4 die-die-die draft: http://tools.ietf.org/id/draft-popov-tls-p= rohibiting-rc4-01.txt > But UTA seems to be doing that, except no one actually wants to kill RC4) I think a lot of people want to kill RC4. The problem is, some say: "becaus= e publishing an RC4 die-die-die RFC will not kill RC4 overnight, why bother= with the RFC". IMHO, the RFC is still needed, both as a signal to the indu= stry, and as a matter of routine maintenance of the protocol. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd Sent: Friday, April 11, 2014 8:55 AM To: tls@ietf.org Subject: [TLS] draft-ietf-tls-encrypt-then-mac Dear all, Professor Gutman has generously cleaned up the mess left by this WG. The draft looks good to me. Before you all go pontificate about TLS 1.3, I = strongly suggest fixing TLS 1.2, and I think this draft solves one of the t= hree problems out there. (We still need a 1/n-1 draft for TLS 1.0, and a RC4 die-die-die draft. But UTA seems to be doing that, except no one actually wants to kill RC4) Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 11 10:26: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 75E0C1A070A for ; Fri, 11 Apr 2014 10:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeYdMRCwleyV for ; Fri, 11 Apr 2014 10:26:24 -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 7944A1A0709 for ; Fri, 11 Apr 2014 10:26:24 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 06599474D1; Fri, 11 Apr 2014 17:26:23 +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 EB03C474D0; Fri, 11 Apr 2014 17:26:22 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E68952030; Fri, 11 Apr 2014 17:26:22 +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, 11 Apr 2014 13:26:22 -0400 From: "Salz, Rich" To: Andrei Popov , "tls@ietf.org" Date: Fri, 11 Apr 2014 13:26:22 -0400 Thread-Topic: [TLS] draft-ietf-tls-encrypt-then-mac Thread-Index: AQHPVZ56UyGLyyEP206Tqre9fJuddpsMp1mAgAADQmA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GdKMc0jPEI8hMjsODwROu1wRLYU Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:26:25 -0000 > IMHO, the RFC is still needed, both as a signal to the industry, and as a= matter of routine maintenance of the protocol. Yes. And also so ISP's have someplace they can point their customers to. = (Arg, "at which they can point their customers"? Yuk) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Fri Apr 11 10:29: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 994F31A070D for ; Fri, 11 Apr 2014 10:29:56 -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 3xqGPw0IJcAp for ; Fri, 11 Apr 2014 10:29:55 -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 E0C8B1A040F for ; Fri, 11 Apr 2014 10:29:54 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so5642621wes.20 for ; Fri, 11 Apr 2014 10:29: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=jq+JWEIaYIRnPXNIWFlDupE//J9TEBdEYNQuw6ZQTh8=; b=AsI+abgO2rncn0mZUt4k7kc6iaVfGb0K20u5ckzHxmnuAaoNsKfP0QyHT0gxN6gTUG /ijynIAq/7Mv11VdGNTJmW3LSz7KJi27sK0i9/hwftuw/q6lhkUMbjB3jZTVqWnfCaWN t8pyoJVDtUHoIWvv+oV87L50hnJ9W2LNF0MtWvc90zzvMkk/AdtWs/b/akNQADtoIY5Z eBpW9Cd0ylLc8SOnuF+uTRxiSYCWRwYJQed1JzDYwE+rtdkBkYAqBH8RxURvjBFSVsC5 JcOCA6tkpFus1RPxWonzn0aUMKVTyvcj1jdtPz4jJ3b1/pXn/KetNu+YQO6oZFLzUnvN y20g== X-Gm-Message-State: ALoCoQmWBEHnUeRP+Y7RZgaGE+69nXnmEIYAVqNEtqBx7Sf2XwgQ1X6osAEdl79eGhjjg03HChqa X-Received: by 10.180.90.140 with SMTP id bw12mr4524337wib.18.1397237393143; Fri, 11 Apr 2014 10:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 11 Apr 2014 10:29:13 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Fri, 11 Apr 2014 10:29:13 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f46d043c811a7c4f9904f6c7ae96 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5Fx9OsTbrTHU4y3TpnGGXng4WYg Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 17:29:56 -0000 --f46d043c811a7c4f9904f6c7ae96 Content-Type: text/plain; charset=ISO-8859-1 Speaking as an individual, I agree with this as well. Speaking as chair, we've opted to let UTA handle this, but if they don't think it's in their scope, Andrei please bring it back to TLS and we will reconsider it here. -Ekr On Fri, Apr 11, 2014 at 10:26 AM, Salz, Rich wrote: > > IMHO, the RFC is still needed, both as a signal to the industry, and as > a matter of routine maintenance of the protocol. > > Yes. And also so ISP's have someplace they can point their customers to. > (Arg, "at which they can point their customers"? Yuk) > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c811a7c4f9904f6c7ae96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Speaking as an individual, I agree with this as well.=

Speaking as chair, we've opted to let UTA= handle this, but if they don't
think it's in their scope= , Andrei please bring it back to TLS and we will
reconsider it here.

-Ekr

<= /div>


On Fri, Apr 11, 2014 at 10:26 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
> IMHO, the RFC is still = needed, both as a signal to the industry, and as a matter of routine mainte= nance of the protocol.

Yes. =A0And also so ISP's have someplace they can point their cus= tomers to. =A0(Arg, "at which they can point their customers"? = =A0Yuk)

=A0 =A0 =A0 =A0 /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

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

--f46d043c811a7c4f9904f6c7ae96-- From nobody Fri Apr 11 11:04: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 246531A021E for ; Fri, 11 Apr 2014 11:04:33 -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, HTML_MESSAGE=0.001, 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 dUDy9MtEn5YQ for ; Fri, 11 Apr 2014 11:04:29 -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 CC4FF1A035D for ; Fri, 11 Apr 2014 11:04:28 -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.918.8; Fri, 11 Apr 2014 18:04:22 +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.0913.002; Fri, 11 Apr 2014 18:04:22 +0000 From: Andrei Popov To: Eric Rescorla , "Salz, Rich" Thread-Topic: [TLS] draft-ietf-tls-encrypt-then-mac Thread-Index: AQHPVZ56UyGLyyEP206Tqre9fJuddpsMp1mAgAADQmCAAAFEgIAACBKw Date: Fri, 11 Apr 2014 18:04:21 +0000 Message-ID: <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(164054003)(24454002)(377454003)(99286001)(74316001)(99396002)(76176999)(85852003)(54356999)(50986999)(77096999)(80022001)(16236675002)(33646001)(81342001)(4396001)(81542001)(20776003)(19609705001)(15975445006)(86612001)(74662001)(92566001)(74502001)(19300405004)(77982001)(46102001)(86362001)(15202345003)(83322001)(80976001)(79102001)(19580395003)(19580405001)(31966008)(76482001)(76576001)(83072002)(87936001)(2656002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:727DF1E4.96F146C9.FEE2512F.5847D849.2024F; 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_9f41a80fdbe243f2915b79d700b7915eBL2PR03MB419namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xN3wqDhUQ73qDiytMNg3CLWfhJk Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:04:33 -0000 --_000_9f41a80fdbe243f2915b79d700b7915eBL2PR03MB419namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe UTA has added some text describing RC4 vulnerabilities to one of = their BCP I-Ds. Which is a good thing, but I think the TLS WG should still = consider fully deprecating RC4. Since the previous RC4 deprecation draft expired, I re-submitted it: http:/= /tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 Thanks, Andrei From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Friday, April 11, 2014 10:29 AM To: Salz, Rich Cc: Andrei Popov; tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac Speaking as an individual, I agree with this as well. Speaking as chair, we've opted to let UTA handle this, but if they don't think it's in their scope, Andrei please bring it back to TLS and we will reconsider it here. -Ekr On Fri, Apr 11, 2014 at 10:26 AM, Salz, Rich > wrote: > IMHO, the RFC is still needed, both as a signal to the industry, and as a= matter of routine maintenance of the protocol. Yes. And also so ISP's have someplace they can point their customers to. = (Arg, "at which they can point their customers"? Yuk) /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_9f41a80fdbe243f2915b79d700b7915eBL2PR03MB419namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe UTA has added s= ome text describing RC4 vulnerabilities to one of their BCP I-Ds. Which is = a good thing, but I think the TLS WG should still consider fully deprecating RC4.

 <= /p>

Since the previous RC4 de= precation draft expired, I re-submitted it: h= ttp://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

 <= /p>

Thanks,=

 <= /p>

Andrei<= /p>

 <= /p>

From: Eric R= escorla [mailto:ekr@rtfm.com]
Sent: Friday, April 11, 2014 10:29 AM
To: Salz, Rich
Cc: Andrei Popov; tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac=

 

Speaking as an individual, I agree with this as well= .

 

Speaking as chair, we've opted to let UTA handle thi= s, but if they don't

think it's in their scope, Andrei please bring it ba= ck to TLS and we will

reconsider it here.

 

-Ekr

 

 

On Fri, Apr 11, 2014 at 10:26 AM, Salz, Rich <rsalz@akamai.com>= wrote:

> IMHO, the RFC is= still needed, both as a signal to the industry, and as a matter of routine= maintenance of the protocol.

Yes.  And also so ISP's have someplace they can= point their customers to.  (Arg, "at which they can point their = customers"?  Yuk)

        /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA


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

 

--_000_9f41a80fdbe243f2915b79d700b7915eBL2PR03MB419namprd03pro_-- From nobody Fri Apr 11 11:12: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 D6A511A074C for ; Fri, 11 Apr 2014 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8mIfP1_UWlMy for ; Fri, 11 Apr 2014 11:12:25 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 04F361A020E for ; Fri, 11 Apr 2014 11:12:24 -0700 (PDT) Message-ID: <53483080.1090207@akr.io> Date: Fri, 11 Apr 2014 19:12:16 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pVEOVvMzoJUGdI0UZ0laUhWDrjo Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:12:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/04/2014 19:04, Andrei Popov wrote: > I believe UTA has added some text describing RC4 vulnerabilities to > one of their BCP I-Ds. Which is a good thing, but I think the TLS > WG should still consider fully deprecating RC4. > > Since the previous RC4 deprecation draft expired, I re-submitted > it: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 I think the WG should adopt this draft. RC4 is critically weak, or worse. +1 - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTSDCAAAoJEOyEjtkWi2t6vbAP/0nIvmz254n2Wt+h2olRuZZA XuNC1m6KcTF+ve40ZKrVJqi6a65Bv2oCBCuWmyknjJ8j+wTAcksfKJX9bKcmDJ8v qctWecfEslF7BfnbNB2XDLkV3ZT0TK/YYZfU2olS98wW/IG4xVpfBDgaALQy1Bx+ hVEyhXLPOYnCiENOcCJKiVQTRJ0p05hUkm0xi+6oIEG3OBQVL/ue3PTtZb1SPQaJ QU5781oizQenzZskfp0WvsCKDNrGA5So1l0fReofzrEtyV8QgodcTG6fKr2jU24u Qby3X+pWMAuskapU6GGQoNLDETbfUxqemQl6eBfPD6jyvI1t8E6V41qrmAU5CZb2 GOkgClOBo2wkA0KX+IzZP7DIA6lV7I7Q8npwUs7nOzLszg5aixb2MyAcaUY5L8/n G1REvrdbKKZz+brtILwMPjbIKa7xLCpcwK0TDiXM22HgHph3x++lwZ58+jX7DpbU XXPNJwo8dVHzCUovMCqPvi7+9YajQUi+yVQhRtIr4CAolyqpDv2QAYDcKlWXA2V5 eNIwXyGPk3iQoecQwvRm/5pJGe1ZqxCi8QUL/Mm1aXuZZhao6s18wJKDnGT1eSe5 grV20FQl9Mz1W79PnKBAA6S9c1V4BVw4Z9yCTo4KY2WqmpvxkmzKOjmT231XnjN6 NiBKbEIo6MNRTG8VrLND =rJhQ -----END PGP SIGNATURE----- From nobody Fri Apr 11 11:30: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 DF3231A02C3 for ; Fri, 11 Apr 2014 11:30: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 ZiYY-HRWYbee for ; Fri, 11 Apr 2014 11:30:20 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id B3DCB1A0219 for ; Fri, 11 Apr 2014 11:30:19 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id t10so4484028eei.0 for ; Fri, 11 Apr 2014 11:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ofnLlY1NqlL0wIk/5ZhysgGdRgNdq8IGuFMZai6m6I=; b=e4a+agkou0KLgOELMNE3DtU26JRkbxqwJjujp+JF2ysVdwmbaJNBLIcQIagFz3qNIh Ee8GZ7YqE00W+kXRKppAFkhc/Rj1OAm37l2gMhQygsFEt4l1eSXVEx5Lgn/cSoKBj5zH 2S5cRayFUDwOSntKGPhpEyzsGayDufIjSZ9iyZnC6dtrsI2UY/NT3uxY4IHPH+VnPKcC V2bE/oOs2n10uJarjJmXD79w+m9rg2a9CVYKPUpGy6LXyN3Jao8+j0XZiGERSvEBUF9X LLududLf322vV4k/cX/tONLmdbBkbzLDn5aOHcAhF/wXC0kppWpqEXPsZ7MRteh0WnK1 gNww== X-Received: by 10.15.91.77 with SMTP id r53mr5150354eez.70.1397241017749; Fri, 11 Apr 2014 11:30:17 -0700 (PDT) Received: from [192.168.243.52] ([192.116.177.210]) by mx.google.com with ESMTPSA id y51sm19482003eeu.0.2014.04.11.11.30.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 11:30:15 -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: <53483080.1090207@akr.io> Date: Fri, 11 Apr 2014 21:30:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3FDBCD10-DC22-4DB2-9BAB-C0F72277CF08@gmail.com> References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> <53483080.1090207@akr.io> To: Alyssa Rowan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/01D79n4RiM8kRaT2Bp3NDn5XPQU Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:30:23 -0000 On Apr 11, 2014, at 9:12 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 11/04/2014 19:04, Andrei Popov wrote: >=20 >> I believe UTA has added some text describing RC4 vulnerabilities to >> one of their BCP I-Ds. Which is a good thing, but I think the TLS >> WG should still consider fully deprecating RC4. >>=20 >> Since the previous RC4 deprecation draft expired, I re-submitted >> it: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 >=20 > I think the WG should adopt this draft. RC4 is critically weak, or > worse. +1 >=20 -1=20 RC4 is also used in other protocols such as SSH (See RFC 4345), and the = (in)security considerations apply there as well. So I think this = document should proceed as AD-sponsored individual or a CFRG document, = and not specifically a TLS document. It is strange that the IETF would publish a die-die-die document only = three years after RFC 6229, but that=92s life, I guess. Yoav From nobody Fri Apr 11 11: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 4DEEF1A036B for ; Fri, 11 Apr 2014 11:36:05 -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 sya6r-XJ9cyF for ; Fri, 11 Apr 2014 11:36:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9118C1A034A for ; Fri, 11 Apr 2014 11:36:00 -0700 (PDT) Received: from mail141-co9-R.bigfish.com (10.236.132.237) by CO9EHSOBE008.bigfish.com (10.236.130.71) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Apr 2014 18:35:32 +0000 Received: from mail141-co9 (localhost [127.0.0.1]) by mail141-co9-R.bigfish.com (Postfix) with ESMTP id 0912D1201CA; Fri, 11 Apr 2014 18:35:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: PS-32(zzbb2dI98dI154cP9371I1432Izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: pass (mail141-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=AMSPRD0310HT003.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(54524002)(24454002)(189002)(199002)(377454003)(479174003)(83072002)(15202345003)(99396002)(20776003)(15975445006)(83506001)(79102001)(76176999)(54356999)(50986999)(77096999)(80022001)(2656002)(19580405001)(85852003)(66066001)(83322001)(87936001)(92566001)(80976001)(77982001)(31966008)(19580395003)(4396001)(74482001)(46102001)(74502001)(76482001)(92726001)(86362001)(74662001)(81342001)(36756003)(81542001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:7E7AF1EE.8D3244E5.7EE3512C.446AE948.20262; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail141-co9 (localhost.localdomain [127.0.0.1]) by mail141-co9 (MessageSwitch) id 1397241330729060_25625; Fri, 11 Apr 2014 18:35:30 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.226]) by mail141-co9.bigfish.com (Postfix) with ESMTP id A3CD54A0047; Fri, 11 Apr 2014 18:35:30 +0000 (UTC) Received: from AMSPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.5) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Apr 2014 18:35:30 +0000 Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT003.eurprd03.prod.outlook.com (10.255.40.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 11 Apr 2014 18:35:54 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.918.8; Fri, 11 Apr 2014 18:35:54 +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.0918.000; Fri, 11 Apr 2014 18:35:53 +0000 From: "Paterson, Kenny" To: Yoav Nir , Alyssa Rowan Thread-Topic: [TLS] draft-ietf-tls-encrypt-then-mac Thread-Index: AQHPVZ6AY9C8WLyMEkaEXA//mHyG4JsMqmwAgAAApwCAAADMgIAACdGAgAACNgCAAAT+AIAAElkA Date: Fri, 11 Apr 2014 18:35:53 +0000 Message-ID: References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> <53483080.1090207@akr.io> <3FDBCD10-DC22-4DB2-9BAB-C0F72277CF08@gmail.com> In-Reply-To: <3FDBCD10-DC22-4DB2-9BAB-C0F72277CF08@gmail.com> 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: [134.219.227.30] x-forefront-prvs: 0178184651 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <956BE4EFD38CD5409ED2650CA2B756AA@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/eVO6njPoZa8HbdYK-OOxIMgZc2w Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:36:05 -0000 On 11/04/2014 19:30, "Yoav Nir" wrote: > >On Apr 11, 2014, at 9:12 PM, Alyssa Rowan wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> On 11/04/2014 19:04, Andrei Popov wrote: >>=20 >>> I believe UTA has added some text describing RC4 vulnerabilities to >>> one of their BCP I-Ds. Which is a good thing, but I think the TLS >>> WG should still consider fully deprecating RC4. >>>=20 >>> Since the previous RC4 deprecation draft expired, I re-submitted >>> it: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 >>=20 >> I think the WG should adopt this draft. RC4 is critically weak, or >> worse. +1 >>=20 > > >-1=20 > >RC4 is also used in other protocols such as SSH (See RFC 4345), and the >(in)security considerations apply there as well. So I think this document >should proceed as AD-sponsored individual or a CFRG document, and not >specifically a TLS document. I tend to disagree. RC4 is *widely* used in TLS, and the specific attacks referred to in Andrei's draft are for TLS. It's the TLS WG's responsibility to clean up its own problems. >It is strange that the IETF would publish a die-die-die document only >three years after RFC 6229, but that=B9s life, I guess. That's irrelevant. The state of cryptanalytic knowledge changes, and IETF has to respond to that. Cheers, Kenny From nobody Fri Apr 11 11:51: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 A4FB01A075C for ; Fri, 11 Apr 2014 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sby79CPxZ07Y for ; Fri, 11 Apr 2014 11:51:05 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 18D8C1A0737 for ; Fri, 11 Apr 2014 11:51:04 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so5861831wes.11 for ; Fri, 11 Apr 2014 11:51:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=aocPAPKqua+5OKfBtcDruvUgNXKXQchocgr4ZSpC9lQ=; b=hLmvun32BM9iFPSM3Qr77XYWezA9hQCY4V6IYCJp5+wpR+3OHbQ+OMSxafdb8N2Zso QO9hOa4nNPF2BW1L9bpqYS4UX2qC0s/dIKWt5PFR/FhHYpHvmHXmqnN/mGBGskZYNkRY 0NMi4hpnp5F2J1dP/eFjubpP33Jzfk5qawEXNIasfb2MOdjjD7XtUk7xQnEgFNz64iiC PbRrN2Eaadn37CFCWrt1zr7SvXGfQmhb53JKevprizgKOz+7xhzyX91itLFw08vygxqG NqjeAixn2voSs1159JSyZC7auoIr8iAq4k36oXyfLAAoj5vqg2MMUc1IJBgBHrymQZh9 HuNA== X-Gm-Message-State: ALoCoQlmpIrU+GgGs7UVLET9udifwXQW8u2VgmLX7vKAuZM8mOd7Sf+rZArkjrfzwjNfYxj0UxY9 X-Received: by 10.180.211.70 with SMTP id na6mr4692446wic.1.1397242263102; Fri, 11 Apr 2014 11:51:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 11 Apr 2014 11:50:22 -0700 (PDT) X-Originating-IP: [63.245.221.34] From: Eric Rescorla Date: Fri, 11 Apr 2014 11:50:22 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c261dcc1ff0504f6c8d01e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UNPQnH0jfy4fwc8OrTknwzyL1Y4 Subject: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 18:51:06 -0000 --001a11c261dcc1ff0504f6c8d01e Content-Type: text/plain; charset=ISO-8859-1 Folks, Andrei Popov has refreshed his draft on deprecating RC4: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 There was significant WG support for this draft previously and then the discussion migrated to UTA where it does not seem to be terminating. The chairs would like to hear from WG members whether they support adoption of this draft in TLS. While this is not a formal call for adoption, if we get strong support we will immediately move for adoption, so now is a good time to raise any objections you have. -Ekr --001a11c261dcc1ff0504f6c8d01e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

Andrei Popov has refreshed his d= raft on deprecating RC4:


There was significant WG support for this draft p= reviously and
then the discussion migrated to UTA where it does n= ot seem
to be terminating.

The chairs wo= uld like to hear from WG members whether they
support adoption of this draft in TLS. While this is not a formal
call for adoption, if we get strong support we will immediately
=
move for adoption, so now is a good time to raise any
object= ions you have.

-Ekr

--001a11c261dcc1ff0504f6c8d01e-- From nobody Fri Apr 11 12:17: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 5E9C61A034A for ; Fri, 11 Apr 2014 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB4LqEsCvH4n for ; Fri, 11 Apr 2014 12:17:10 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 78D681A0395 for ; Fri, 11 Apr 2014 12:17:09 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so1535935wib.5 for ; Fri, 11 Apr 2014 12: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=rqrTtoVsQhaBoe33k7tKmITIB74Z+epFS/F+uB9FSps=; b=N2QZNwv/xeXzCASvTBygXAbhIj6NigTMIdvz5QjM7XG2s+N+taBzeKPdgQWzDC5O5I cbsG0oz4Zw4ILRFDEk4h++UgG3/5DDR/JYY712rebRJIBEL2FQWgQZQsLEZL44t3e77Q WK5PGK1OeVNj6v5n3swimSeuqjsvFqaqML58GpbtQCxHLq+c6hwWvoubGXxH+atnsVgW X+/89ZEwi93Q6ZgCPUCeajPsoDQu4aTgqP40KeA1Jp1HX437kl0OHuCH69lG506Br1vy Usiq7VVUCaAbpPkvk1BXiA78YrgaCMMWE8xXOl3h6zcehmvxvXMGfK2UkS+zuDmkrsXt 0McQ== MIME-Version: 1.0 X-Received: by 10.180.89.211 with SMTP id bq19mr4752903wib.58.1397243827389; Fri, 11 Apr 2014 12:17:07 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 11 Apr 2014 12:17:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 12:17:07 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H6XFnShHxvH4dXth5U1iNaYXu0E Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:17:15 -0000 On 11 April 2014 11:50, Eric Rescorla wrote: > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. Let's publish this. It's good to say that RC4 is bad and shouldn't be used when it is so clearly bad. Yoav seemed to be in favour of making a broader statement that covers other uses of RC4. I don't see any harm in making the narrower statement, particularly since it sets a precedent others can rely on. If someone wanted to write a "don't use RC4 anywhere, ever" draft, that might be a harder thing to do, but I'd support that as long as it didn't cause this to become mired in red tape. From nobody Fri Apr 11 12: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 C87D71A03A0 for ; Fri, 11 Apr 2014 12:19:22 -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 pE662w2FGdGh for ; Fri, 11 Apr 2014 12:19:20 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 85A731A0737 for ; Fri, 11 Apr 2014 12:19:13 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 315251C211F; Fri, 11 Apr 2014 21:19:11 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 128861FE01D3; Fri, 11 Apr 2014 21:19:10 +0200 (CEST) Date: Fri, 11 Apr 2014 21:19:10 +0200 From: Kurt Roeckx To: Eric Rescorla Message-ID: <20140411191910.GA12668@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3G6G9veV11ZkM4ecNTlcRbO7ouI Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:19:22 -0000 On Fri, Apr 11, 2014 at 11:50:22AM -0700, Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. I'm not sure I've seen all the discussion about this topic, so I want to at least give my remarks. I think the goal is that RC4 should not be negiotiated anymore, unless there is no other option. I think Microsoft started to stop sending RC4 in it's initial handshake, but on failure does send it, which seems to be going for that goal. There are sites out there where RC4 is the only option of the ciphers offered by current browsers. But there are also servers that pick RC4 if you offer any RC4 cipher even when it's the last one in your list. And I think we want to really prevent servers from picking RC4 when there are other ciphers available that both are willing to use. So I would really like to see the other browsers adopt what Microsoft is already doing, and server to not pick RC4. The lists of cipers in appendix A is also very short, there are more ciphers with RC4 that can be used in TLS. Kurt From nobody Fri Apr 11 12:31: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 EEA2E1A03BC for ; Fri, 11 Apr 2014 12:31:55 -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_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q_a_6gyIQNJ for ; Fri, 11 Apr 2014 12:31:53 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C0B0C1A02D4 for ; Fri, 11 Apr 2014 12:31:52 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 50C2AF986 for ; Fri, 11 Apr 2014 15:31:50 -0400 (EDT) Message-ID: <53484319.5090504@fifthhorseman.net> Date: Fri, 11 Apr 2014 15:31:37 -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="bt3XdFXuNsat2tgph0XS6tjjVXdpKCUSv" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_z1aCvSCuW_pMT3xsGhsA3ZM7Dg Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:31:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bt3XdFXuNsat2tgph0XS6tjjVXdpKCUSv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/11/2014 02:50 PM, Eric Rescorla wrote: > Andrei Popov has refreshed his draft on deprecating RC4: >=20 > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 I would be happy to see RC4 go away, and if this helps push the 'net across that boundary, I would be happy to see it. I have two concerns with the current draft, though: 0) XP, WinServer2003, and even weaker ciphers ---------------------------------------------- Windows XP and Windows Server 2003 offer a very limited selection of ciphersuites: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=3Dvs= =2E85%29.aspx The only two ciphers that are close to plausible here RC4 and 3DES-CBC. The other ones are even weaker. If we say that such a system shouldn't offer RC4, should they continue offering the even weaker ciphers as well, like TLS_RSA_WITH_DES_CBC_SHA or, uh, TLS_RSA_WITH_NULL_SHA ? Do we have comparable text that deprecates these other ciphers? Windows XP was EOL'ed earlier this week, but everyone knows that it is still in disturbingly widespread use. Windows Server 2003 is supposed to be in extended support until the middle of 2015. Is there any prospect of an SChannel update for these systems that would make these clients behave better on the modern network? 1) opportunistic TLS in fallback-to-clear contexts --------------------------------------------------- as broken as RC4 is, it's better than cleartext. There are contexts in which TLS is used only when it can be negotiated, and otherwise the same communication is retried in the clear. One such example is SMTP mail delivery. It would be a net loss in security if this draft caused a mailserver to fail to negotiate TLS, and then it came back and reconnected to deliver the same message in the clear. Some text that thoughtfully acknowledges this context and indicates what servers and clients should do knowing that old peers exist would probably be useful. More generally, and i know i've banged on this drum before, i wish we had a better idea about how to proactively deprecate weak crypto in general. It seems like we always do it in an ad-hoc fashion, and we roll out new crypto without a thought about how we're going to deal with its inevitable demise (except maybe by yanking it in some ad-hoc way in the future). I've got no good recommendations for how to do this, but i would love to hear some. --dkg --bt3XdFXuNsat2tgph0XS6tjjVXdpKCUSv 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/ iQJ8BAEBCgBmBQJTSEMZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcFygP/1r7bNSyxNJHseD/2Q6lGNU1 8gmnsUFVA2QLvyINGpZAdb19QKyDf7suLJMa1O44VHtSYQcTqETWy7ecJwH7EEwM n/BaYZAuyHUDJvhhslXj2qFjkDHRIdEGjPYh7iZ3PbIVrPDnH9ioVwYRgKnOyOgM 9FC9wMDyycWZ147Y261UgaxymfXixWaT3fXs1IsfmnJpXGSQwY3ReWcHsb+IIpgg LWe/kXJ1ez+NOGQIfeBWBV8sARZn7ulvDzXOjHHWYJPfJn5CgHnv7TTjugmq0A4C gGQJeopB/i+npSWj4RYmV8s2k5cS0wxBl+/3cPppvJyR7z7BAc5C/9eu0tJ+qsm/ I+urxD7NTZHCoOCltiNDkXlQ4WDeNWTFQgGKFOhH/K/qt3W+Zru0aWwALktRPAcl JXEZEYg5fXApjBrXOkZLo8pjUVmByEw87yJ/Qxa9ECsGLx4xwMrmXsMgdMKkF/0g SgBtPyoyncQoGiuJEDprMlCcXE3KToaQAohzKnANYp6LofpJ6J4U0zSQ31FazuWo U0ZbRBLqjLPcXxXhjiW3pAvOn1VL2BQhRjy3cXiPKi2SOty6dx1tr+IBsLoPZT+N mVHDoztWzLhjicgDdTRfMiWSiGdUJx42mVXdiDjI/ypPa8XgstapB6vgPDDDghNS 1+KZ4ndK9TrAVggFEyRA =dtad -----END PGP SIGNATURE----- --bt3XdFXuNsat2tgph0XS6tjjVXdpKCUSv-- From nobody Fri Apr 11 13:00: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 888E01A072E for ; Fri, 11 Apr 2014 13:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peC5ZwVH-zMz for ; Fri, 11 Apr 2014 13:00:06 -0700 (PDT) Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA41A03FC for ; Fri, 11 Apr 2014 13:00:05 -0700 (PDT) Received: from spectre ([173.8.184.78]) by p3plsmtpa06-04.prod.phx3.secureserver.net with id ok031n00R1huGat01k03MT; Fri, 11 Apr 2014 13:00:04 -0700 From: "Peter Yee" To: References: In-Reply-To: Date: Fri, 11 Apr 2014 13:00:10 -0700 Message-ID: <02f201cf55c0$a58fcbe0$f0af63a0$@akayla.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F3_01CF5585.F931B730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI/IamTI5US4GWYrLOkYV/jd895i5otNdXQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aV_YnYwEl1hXTms7D8NIcpHNkwc Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:00:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F3_01CF5585.F931B730 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm in favor of deprecating RC4 in TLS. The only plausible arguments I've heard of are for support of legacy systems. Given how long it takes new changes in TLS to be adopted anyhow, we should be deprecating RC4 now and trying to give legacy systems an impetus to move on to better algorithms. Given no other guidance there's a lot of inertia that will keep many sites offering RC4, at least until something catastrophic happens. -Peter From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, April 11, 2014 11:50 AM To: tls@ietf.org Subject: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) Folks, Andrei Popov has refreshed his draft on deprecating RC4: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 There was significant WG support for this draft previously and then the discussion migrated to UTA where it does not seem to be terminating. The chairs would like to hear from WG members whether they support adoption of this draft in TLS. While this is not a formal call for adoption, if we get strong support we will immediately move for adoption, so now is a good time to raise any objections you have. -Ekr ------=_NextPart_000_02F3_01CF5585.F931B730 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I’m in favor of deprecating RC4 in TLS.  The only = plausible arguments I’ve heard of are for support of legacy = systems.  Given how long it takes new changes in TLS to be adopted = anyhow, we should be deprecating RC4 now and trying to give legacy = systems an impetus to move on to better algorithms.  Given no other = guidance there’s a lot of inertia that will keep many sites = offering RC4, at least until something catastrophic = happens.

 

           &nbs= p;    -Peter

 

From:= = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Friday, April 11, 2014 11:50 AM
To: = tls@ietf.org
Subject: [TLS] Deprecating RC4 (was: = draft-ietf-tls-encrypt-then-mac)

 

Folks,

 

Andrei Popov has refreshed his draft on deprecating = RC4:

 

 

There was significant WG support for this draft = previously and

then the = discussion migrated to UTA where it does not = seem

to be = terminating.

 

The chairs would like to hear from WG members whether = they

support adoption of = this draft in TLS. While this is not a = formal

call for adoption, = if we get strong support we will immediately

move for adoption, so now is a good time to raise = any

objections you = have.

 

-Ekr

 

------=_NextPart_000_02F3_01CF5585.F931B730-- From nobody Fri Apr 11 13:16: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 481191A03A0 for ; Fri, 11 Apr 2014 13:16:40 -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 ePSH-kmyMStN for ; Fri, 11 Apr 2014 13:16:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id B31B81A01E3 for ; Fri, 11 Apr 2014 13:16:37 -0700 (PDT) Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB425.namprd03.prod.outlook.com (10.141.141.139) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 11 Apr 2014 20:16:28 +0000 Received: from BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) by BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) with mapi id 15.00.0913.002; Fri, 11 Apr 2014 20:16:28 +0000 From: Andrei Popov To: Kurt Roeckx , Eric Rescorla Thread-Topic: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) Thread-Index: AQHPVbcDIvidGK5PZU2sRNpttUhzH5sMymYAgAALYwA= Date: Fri, 11 Apr 2014 20:16:27 +0000 Message-ID: <7fc6ac9042d34f328bd5a0778a299374@BY2PR03MB427.namprd03.prod.outlook.com> References: <20140411191910.GA12668@roeckx.be> In-Reply-To: <20140411191910.GA12668@roeckx.be> 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: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(377454003)(13464003)(24454002)(51704005)(46102001)(4396001)(76576001)(20776003)(80976001)(86612001)(50986999)(77096999)(54356999)(85852003)(19580405001)(31966008)(76176999)(74316001)(83322001)(99396002)(33646001)(19580395003)(79102001)(81342001)(80022001)(99286001)(87936001)(74502001)(15975445006)(74662001)(77982001)(81542001)(76482001)(15202345003)(92566001)(86362001)(83072002)(2656002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB425; H:BY2PR03MB427.namprd03.prod.outlook.com; FPR:DC4FF53C.A7F6D7E6.3CE27DA3.4A0C3FC9.203AD; 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/6QIXI4qfZl4kFRSZpHRy5OubAhk Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:16:40 -0000 Correct, IE no longer sends RC4 in the first connection attempt, in an effo= rt to negotiate something other than RC4 with those servers that prefer RC4= , but also have other cipher suites in common with IE. After implementing t= his, we saw a significant decrease in the percentage of RC4 connections neg= otiated by IE. Another thing we did lately (and this applies broader than IE changes) is w= e prioritized RC4 cipher suites at the bottom of the list (http://support.m= icrosoft.com/kb/2929781/en-us ). The TLS servers that take client prioritie= s into account (there is a surprisingly high percentage of those) are now l= ess likely to pick RC4, when talking to schannel-based clients. The above measures are just the beginning of the RC4 deprecation process; o= ver time we would like to completely remove RC4 support from schannel. > The lists of ciphers in appendix A is also very short, there are more cip= hers with RC4 that can be used in TLS. Yes, I'll update the list in the next revision of the I-D. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Kurt Roeckx Sent: Friday, April 11, 2014 12:19 PM To: Eric Rescorla Cc: tls@ietf.org Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) On Fri, Apr 11, 2014 at 11:50:22AM -0700, Eric Rescorla wrote: > Folks, >=20 > Andrei Popov has refreshed his draft on deprecating RC4: >=20 > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 >=20 > There was significant WG support for this draft previously and then=20 > the discussion migrated to UTA where it does not seem to be=20 > terminating. I'm not sure I've seen all the discussion about this topic, so I want to at= least give my remarks. I think the goal is that RC4 should not be negiotiated anymore, unless ther= e is no other option. I think Microsoft started to stop sending RC4 in it'= s initial handshake, but on failure does send it, which seems to be going f= or that goal. There are sites out there where RC4 is the only option of the ciphers offer= ed by current browsers. But there are also servers that pick RC4 if you of= fer any RC4 cipher even when it's the last one in your list. And I think w= e want to really prevent servers from picking RC4 when there are other ciph= ers available that both are willing to use. So I would really like to see the other browsers adopt what Microsoft is al= ready doing, and server to not pick RC4. The lists of cipers in appendix A is also very short, there are more cipher= s with RC4 that can be used in TLS. Kurt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 11 13:24: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 155631A03B7 for ; Fri, 11 Apr 2014 13:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAEixPy5-X4E for ; Fri, 11 Apr 2014 13:24:16 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.160.2]) by ietfa.amsl.com (Postfix) with ESMTP id A044D1A03FC for ; Fri, 11 Apr 2014 13:24:16 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id DA0ACDCE20B85; Fri, 11 Apr 2014 15:24:14 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 91CDBDCE20AD2 for ; Fri, 11 Apr 2014 15:24:14 -0500 (CDT) Received: from [96.231.225.192] (port=52174 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WYhzh-0003b6-Nt for tls@ietf.org; Fri, 11 Apr 2014 15:24:13 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5172D2F8-E742-43E4-A2F8-ECC5AA342CB6@ieca.com> Date: Fri, 11 Apr 2014 16:24:11 -0400 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WYhzh-0003b6-Nt X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:52174 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dac9gjQ1tVpt8GeAFuwE5uqklxo Subject: [TLS] EC 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, 11 Apr 2014 20:24:18 -0000 The CFRG is currently scheduling an interim to discuss recommendations = for new elliptic curves for the IETF as a whole [1]. That meeting is = expected to happen in the April 28 through May 2 timeframe. The chairs = feel that it is premature to adopt any specific drafts for TLS prior to = hearing back from the CFRG, but we would expect to move forward on = drafts as soon as we have their recommendation. Sean Turner for the chairs [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg04435.html= From nobody Fri Apr 11 13:35: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 7C9B21A03B7 for ; Fri, 11 Apr 2014 13:34:58 -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 hY1y7C2y1EwV for ; Fri, 11 Apr 2014 13:34:54 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id EC86D1A02D4 for ; Fri, 11 Apr 2014 13:34:53 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id ih12so5770647qab.37 for ; Fri, 11 Apr 2014 13:34: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:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=IM5A3PC3zWm5V+THx5BBNakEq/zXAc53UOGL3nS//aY=; b=AE5ynRDOGOdnmNU5vorxpWKjFZ4NOq258zZWO8m7Ag03AZEVpwuPZXhxLoDqB8dN5v xtquBFZRMhUsfvZ4qKU07dyO5qS+bg3+UgkDjyEg45oFcUzyo9ufdiMO92cUrNdAJjGm lmFLtuJi4HEO//359rsBDm3EougISaP5FK7mZPZAZPeCs7k7tvAK1G5N6iNac9WC+jEX uCXJlm2o+3y1Xga7F9nSoix7pLaQkVRv8RvpU6lC11JIkxi9ocgOgmvboWj0UlCTQcZZ DlDoYF1MfZzAh+ky5r0W+Q+8+lorPhFOjfafExNJiZou9mUqies3LmoKXGbN2HVGYF2e iIPQ== X-Gm-Message-State: ALoCoQl2gOKif8q/zFoC9VaJjxoSWh9zLwzSPrbZH6FkW5CxllZ7TzH28Z5++h0s4/eoo6GIVmME X-Received: by 10.224.165.139 with SMTP id i11mr1755525qay.94.1397248492320; Fri, 11 Apr 2014 13:34:52 -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 11sm7212256qgv.20.2014.04.11.13.34.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Apr 2014 13:34:51 -0700 (PDT) Received: from ip-120-50.wireless.oberlin.edu (ip-120-50.wireless.oberlin.edu [132.162.120.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 9436DAC28F0 for ; Fri, 11 Apr 2014 16:34:50 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Stephen Checkoway In-Reply-To: Date: Fri, 11 Apr 2014 16:34:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: <71E1C74D-C053-4AB7-8ECC-BC9CB7089A0B@pahtak.org> References: To: "tls@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LZ-I7xokuPyKOlC_Dc8pj-dooeM Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:34:58 -0000 On Apr 11, 2014, at 2:50 PM, Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. I support adoption. -- Stephen Checkoway From nobody Fri Apr 11 13:39:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E5D1A072E for ; Fri, 11 Apr 2014 13:39:02 -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 90vT4O59EgZ8 for ; Fri, 11 Apr 2014 13:39:00 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id E32D51A03D0 for ; Fri, 11 Apr 2014 13:38:59 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so4527147eek.36 for ; Fri, 11 Apr 2014 13:38:58 -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=YG3oFK2EqaAkHOLKhjUrcLUxfRkp/R54JFL6aUje0Uo=; b=Xdm1OxZerw9xuUK1yqrV7j1mjU91Sbtg9mYSXVDU3W3wMekVWMM67L9viwhQbBk47Q JMSuhughM3FeYx9pk7AsPfQ2j8GjDuJR5rBXsxgpp1DQpBvzLoOcakcIaRCpnDL0NdCR 98VDArUhZlyEGXtYwAGfiuI/cwnQU5fi/DiD7fuKWFOWmGldCUTWm/HVnryEQDVCWnpa 0ypsfoyDVVm4uymJvKf3FUx0EqhT1lf49Fw7XKE7L/JCmNR1S0ucBxaqHFTEYfwZGxV0 7oX3AHbVWcr870E8JpzKO2Cf0G+HUL/zNQXoht2Z/DZ/84/KTlRgCJmUyqcqXCqTLqv6 zBxg== X-Received: by 10.14.88.199 with SMTP id a47mr28604575eef.6.1397248738090; Fri, 11 Apr 2014 13:38:58 -0700 (PDT) Received: from [192.168.243.52] ([192.116.177.210]) by mx.google.com with ESMTPSA id u1sm20165624eex.31.2014.04.11.13.38.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 13:38:57 -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: <53484319.5090504@fifthhorseman.net> Date: Fri, 11 Apr 2014 23:38:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53484319.5090504@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/65b6qrmTKtZnVQRJk85ateTIzxE Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:39:02 -0000 Hi, dkg It=92s not clear to me whether the draft is targeted at developers or = deployers. If the former, it comes too late to apply to XP and Win2003. = If the latter, you can still configure your server to only offer 3DES. = While not the best cipher out there, if someone is stuck and cannot = upgrade to Win2008, it is (as you say) the only plausible thing. For people stuck on XP, there=92s still Chrome, Firefox, and Opera. If = they insist on using software that is all 10 years old, a new RFC can=92t = apply to them. If you use IE you can=92t turn off ciphersuites. Or maybe = there=92s some secret registry hack, but if you=92re technical enough to = hack the registry, you=92re technical enough to install a more modern = browser or OS. Those other weak ciphers should be gone as well. There is no good reason = today to have =93export=94 ciphersuites. NULL can stay, but nobody in = their right minds uses that in a server that is supposed to offer = confidentiality. Those ciphersuites are like AH in IPsec, a rarity that = is useful in a few edge cases. As for opportunistic encryption, while it=92s true that RC4 is better = than nothing, anything that can do RC4 can do better things. Even if = those "better things" are 3DES-CBC in TLS 1.0. Yoav On Apr 11, 2014, at 10:31 PM, Daniel Kahn Gillmor = wrote: > On 04/11/2014 02:50 PM, Eric Rescorla wrote: >=20 >> Andrei Popov has refreshed his draft on deprecating RC4: >>=20 >> http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 >=20 > I would be happy to see RC4 go away, and if this helps push the 'net > across that boundary, I would be happy to see it. >=20 > I have two concerns with the current draft, though: >=20 >=20 > 0) XP, WinServer2003, and even weaker ciphers > ---------------------------------------------- >=20 > Windows XP and Windows Server 2003 offer a very limited selection of > ciphersuites: >=20 > = http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=3Dvs.= 85%29.aspx >=20 > The only two ciphers that are close to plausible here RC4 and = 3DES-CBC. > The other ones are even weaker. >=20 > If we say that such a system shouldn't offer RC4, should they continue > offering the even weaker ciphers as well, like = TLS_RSA_WITH_DES_CBC_SHA > or, uh, TLS_RSA_WITH_NULL_SHA ? Do we have comparable text that > deprecates these other ciphers? >=20 > Windows XP was EOL'ed earlier this week, but everyone knows that it is > still in disturbingly widespread use. >=20 > Windows Server 2003 is supposed to be in extended support until the > middle of 2015. >=20 > Is there any prospect of an SChannel update for these systems that = would > make these clients behave better on the modern network? >=20 >=20 > 1) opportunistic TLS in fallback-to-clear contexts > --------------------------------------------------- >=20 > as broken as RC4 is, it's better than cleartext. There are contexts = in > which TLS is used only when it can be negotiated, and otherwise the = same > communication is retried in the clear. One such example is SMTP mail > delivery. >=20 > It would be a net loss in security if this draft caused a mailserver = to > fail to negotiate TLS, and then it came back and reconnected to = deliver > the same message in the clear. >=20 > Some text that thoughtfully acknowledges this context and indicates = what > servers and clients should do knowing that old peers exist would > probably be useful. >=20 >=20 >=20 > More generally, and i know i've banged on this drum before, i wish we > had a better idea about how to proactively deprecate weak crypto in > general. It seems like we always do it in an ad-hoc fashion, and we > roll out new crypto without a thought about how we're going to deal = with > its inevitable demise (except maybe by yanking it in some ad-hoc way = in > the future). I've got no good recommendations for how to do this, but = i > would love to hear some. >=20 > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 11 13:51: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 1DD991A0737 for ; Fri, 11 Apr 2014 13:51:41 -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 eofX70xPzN6T for ; Fri, 11 Apr 2014 13:51:36 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1F1A076E for ; Fri, 11 Apr 2014 13:51:35 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id c41so4534663eek.36 for ; Fri, 11 Apr 2014 13:51:34 -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=JisRFstfn4KDTm7M9SRNE7MKGOE5cVNFfQa3WeMK1vE=; b=00Fd1rp493fgc01PBFV82bGuxkzP3UoIHDvBLHqSMbajXEm6Fh0Y2/KLTa0gCwOkAu Q/H+pqoTvj6jLWTEqZ4TCalyDFuUJIDiPn89SVBofTJmTe/wjB39SRS9ie5LpvmJ8NZu uB/YOxZbKtRvBevQXBRdV4INotTF4VCcpmjnRCTW77uJ6ovfnmkk5n6Cc8g/qJPE/OGQ YT3jprDDsZle5xvXfhpSXyKNCqf3rgX8GzSr7/SEtqbHORh3OxKv+S+HaTaz1wpqkHWD gtk0iKX2xomUCHB9ceT3Wy1nQD5dmZ+wUkYjzzZvtp/RPGphA3uIvosa54NYQvvMw6eo cyYA== X-Received: by 10.15.43.77 with SMTP id w53mr31288446eev.10.1397249494141; Fri, 11 Apr 2014 13:51:34 -0700 (PDT) Received: from [192.168.243.52] ([192.116.177.210]) by mx.google.com with ESMTPSA id h47sm20260477eey.13.2014.04.11.13.51.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 13:51:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C3C2C33-AD43-46AD-9F84-A169EEA2185E" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Fri, 11 Apr 2014 23:50:19 +0300 Message-Id: References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> <53483080.1090207@akr.io> <3FDBCD10-DC22-4DB2-9BAB-C0F72277CF08@gmail.com> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nruw9iwtiQoVmosOOhNVwn_i-rU Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 20:51:41 -0000 --Apple-Mail=_1C3C2C33-AD43-46AD-9F84-A169EEA2185E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 11, 2014, at 9:35 PM, Paterson, Kenny = wrote: > On 11/04/2014 19:30, "Yoav Nir" wrote: >>=20 >> -1=20 >>=20 >> RC4 is also used in other protocols such as SSH (See RFC 4345), and = the >> (in)security considerations apply there as well. So I think this = document >> should proceed as AD-sponsored individual or a CFRG document, and not >> specifically a TLS document. >=20 > I tend to disagree. RC4 is *widely* used in TLS, and the specific = attacks > referred to in Andrei's draft are for TLS. It's the TLS WG's > responsibility to clean up its own problems. Previous deprecation documents were individual AD-sponsored. The = exception was DES (the one with =93die-die-die=94 in the filename), = which was specific to Kerberos. AFAICT RC4 is used in TLS, SSH (a little bit), and WEP. WEP is = deprecated altogether, but we might as well deprecate it for SSH (and = any uses I don=92t know about) as well. >=20 >> It is strange that the IETF would publish a die-die-die document only >> three years after RFC 6229, but that=B9s life, I guess. >=20 > That's irrelevant. The state of cryptanalytic knowledge changes, and = IETF > has to respond to that. Reading the security considerations of 6229, the authors did not think = it was secure at the time. I=92m kind of baffled by the =93don=92t use = this, but if you do, might as well make it correct, so here=92s some = test vectors=94 message. Yoav --Apple-Mail=_1C3C2C33-AD43-46AD-9F84-A169EEA2185E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 11, 2014, at 9:35 PM, Paterson, = Kenny <Kenny.Paterson@rhul.ac.uk>= ; wrote:

On 11/04/2014 19:30, "Yoav Nir" = <ynir.ietf@gmail.com> = wrote:

-1 

RC4 is also used in = other protocols such as SSH (See RFC 4345), and the
(in)security = considerations apply there as well. So I think this document
should = proceed as AD-sponsored individual or a CFRG document, and = not
specifically a TLS document.

I tend to = disagree. RC4 is *widely* used in TLS, and the specific = attacks
referred to in Andrei's draft are for TLS. It's the TLS = WG's
responsibility to clean up its own = problems.

Previous deprecation = documents were individual AD-sponsored. The exception was DES (the one = with =93die-die-die=94 in the filename), which was specific to = Kerberos.

AFAICT RC4 is used in TLS, SSH (a = little bit), and WEP. WEP is deprecated altogether, but we might as well = deprecate it for SSH (and any uses I don=92t know about) as = well.


It is strange that the IETF would = publish a die-die-die document only
three years after RFC 6229, but = that=B9s life, I guess.

That's irrelevant. The state = of cryptanalytic knowledge changes, and IETF
has to respond to = that.

Reading the security = considerations of 6229, the authors did not think it was secure at the = time. I=92m kind of baffled by the =93don=92t use this, but if you do, = might as well make it correct, so here=92s some test vectors=94 = message.

Yoav

= --Apple-Mail=_1C3C2C33-AD43-46AD-9F84-A169EEA2185E-- From nobody Fri Apr 11 14:04: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 08A531A022E for ; Fri, 11 Apr 2014 14:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UdG1FhFVkMi for ; Fri, 11 Apr 2014 14:03:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9401A01DF for ; Fri, 11 Apr 2014 14:03:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6788BBEBE; Fri, 11 Apr 2014 22:03:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7hZWl3Wy2tP; Fri, 11 Apr 2014 22:03:55 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.23.50]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16464BEB5; Fri, 11 Apr 2014 22:03:55 +0100 (IST) Message-ID: <534858BA.4080002@cs.tcd.ie> Date: Fri, 11 Apr 2014 22:03:54 +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: Yoav Nir , "Paterson, Kenny" References: <659cabb0f0f240d19001868304e952f2@BL2PR03MB419.namprd03.prod.outlook.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FB51@USMBX1.msg.corp.akamai.com> <9f41a80fdbe243f2915b79d700b7915e@BL2PR03MB419.namprd03.prod.outlook.com> <53483080.1090207@akr.io> <3FDBCD10-DC22-4DB2-9BAB-C0F72277CF08@gmail.com> 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/rONHy5S6Ove2EcRbi6h_eKbEoNw Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:04:01 -0000 FWIW, I don't mind much if this is done in TLS or AD sponsored but have a slight preference for it being a WG document since that's easier (for me:-). I'll fwd something from this thread to the openssh list and if they wanna join the game we can see how to play it from there. Cheers, S. On 04/11/2014 09:50 PM, Yoav Nir wrote: > > On Apr 11, 2014, at 9:35 PM, Paterson, Kenny wrote: > >> On 11/04/2014 19:30, "Yoav Nir" wrote: >>> >>> -1 >>> >>> RC4 is also used in other protocols such as SSH (See RFC 4345), and the >>> (in)security considerations apply there as well. So I think this document >>> should proceed as AD-sponsored individual or a CFRG document, and not >>> specifically a TLS document. >> >> I tend to disagree. RC4 is *widely* used in TLS, and the specific attacks >> referred to in Andrei's draft are for TLS. It's the TLS WG's >> responsibility to clean up its own problems. > > Previous deprecation documents were individual AD-sponsored. The exception was DES (the one with “die-die-die” in the filename), which was specific to Kerberos. > > AFAICT RC4 is used in TLS, SSH (a little bit), and WEP. WEP is deprecated altogether, but we might as well deprecate it for SSH (and any uses I don’t know about) as well. > >> >>> It is strange that the IETF would publish a die-die-die document only >>> three years after RFC 6229, but that¹s life, I guess. >> >> That's irrelevant. The state of cryptanalytic knowledge changes, and IETF >> has to respond to that. > > Reading the security considerations of 6229, the authors did not think it was secure at the time. I’m kind of baffled by the “don’t use this, but if you do, might as well make it correct, so here’s some test vectors” message. > > Yoav > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 11 14:32: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 0B9B41A03DC for ; Fri, 11 Apr 2014 14:32:46 -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 WZXysZB4louS for ; Fri, 11 Apr 2014 14:32:43 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id EBDF11A03CE for ; Fri, 11 Apr 2014 14:32:43 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 88CF233D0FE; Fri, 11 Apr 2014 21:32:42 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Eric Rescorla References: From: Geoffrey Keating Date: 11 Apr 2014 14:32:42 -0700 In-Reply-To: Message-ID: Lines: 22 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/3Ci55FHTs7eA55AjasR9bKP3bbo Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:32:46 -0000 Eric Rescorla writes: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. I support adoption of this draft. I'd like to see other stream ciphers standardised as replacements, but even if there are none, I would still support the draft. From nobody Fri Apr 11 14:38: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 64FA91A02AF for ; Fri, 11 Apr 2014 14:38:16 -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] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3OWQfQR9K9B for ; Fri, 11 Apr 2014 14:38:15 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9D91A01F2 for ; Fri, 11 Apr 2014 14:38:15 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by ns3.dns-engine.com (Postfix) with ESMTPSA id C3BCA1800066 for ; Fri, 11 Apr 2014 22:38:09 +0100 (BST) Received: by mail-yk0-f172.google.com with SMTP id 200so5428985ykr.17 for ; Fri, 11 Apr 2014 14:38:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.128.180 with SMTP id f40mr35370315yhi.71.1397252288208; Fri, 11 Apr 2014 14:38:08 -0700 (PDT) Received: by 10.170.233.215 with HTTP; Fri, 11 Apr 2014 14:38:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Apr 2014 22:38:08 +0100 Message-ID: From: Matt Caswell To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aSrnVYhDj2fVmIhnC3DkpX2Yz_0 Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 21:38:16 -0000 On 11 April 2014 19:50, Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. +1 for adoption. There is no point in waiting for legacy support for RC4 to die out naturally before deprecating it. The whole point of deprecation is to encourage its demise. Matt From nobody Fri Apr 11 16:48: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 5D4091A02ED for ; Fri, 11 Apr 2014 16:48:29 -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 AsolzSqQnten for ; Fri, 11 Apr 2014 16:48:28 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1494C1A02DE for ; Fri, 11 Apr 2014 16:48:28 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 9E77738EFB; Fri, 11 Apr 2014 16:48:26 -0700 (PDT) From: "Jim Schaad" To: "'Eric Rescorla'" , References: In-Reply-To: Date: Fri, 11 Apr 2014 16:46:31 -0700 Message-ID: <03a201cf55e0$441202a0$cc3607e0$@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: AQI/IamTI5US4GWYrLOkYV/jd895i5otfRtQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q_bic7BkaUTpsthq3uWxSdZaHw4 Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 23:48:29 -0000 +1 for adoption of the draft in the WG. Jim From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, April 11, 2014 11:50 AM To: tls@ietf.org Subject: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) Folks, Andrei Popov has refreshed his draft on deprecating RC4: http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 There was significant WG support for this draft previously and then the discussion migrated to UTA where it does not seem to be terminating. The chairs would like to hear from WG members whether they support adoption of this draft in TLS. While this is not a formal call for adoption, if we get strong support we will immediately move for adoption, so now is a good time to raise any objections you have. -Ekr From nobody Fri Apr 11 21:10: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 486281A03DC for ; Fri, 11 Apr 2014 21:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 kEF_qeaOkAYS for ; Fri, 11 Apr 2014 21:10:51 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id CE4921A03D5 for ; Fri, 11 Apr 2014 21:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=196; q=dns/txt; s=iport; t=1397275850; x=1398485450; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=314LC/ZLLjKS5CoFoIgFf6rszrkgnq3FTW52O30NQno=; b=Bx61/EdvGnAmLUb7BFXs3qp+HXmZ9uOD0goaQ1Hjcpfo6wDuXEJZBaB2 6MAQgUzoy3eD/N5JbK2i+yT2mStaRibrvnhvzNWHTA0lvPIAk0548Yu4/ ZPRFC1I1yRNfZlx1itl0obd8Stj8yCMUYYS1U2L4RJYAOwVJ7SpQxNbAI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOK7SFOtJA2M/2dsb2JhbABYgwaBEo0Vty0WdIIsHR1RAT5CJwSID5lbsXwXkheBFASYYJJCgzGCKw X-IronPort-AV: E=Sophos;i="4.97,846,1389744000"; d="scan'208";a="35180078" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 12 Apr 2014 04:10:50 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3C4AowB030199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 12 Apr 2014 04:10:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.184]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 23:10:50 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Working Group Last Call for draft-ietf-tls-encrypt-then-mac-00 Thread-Index: AQHPVgUvGWZItii+pUeCt4kMNctx0Q== Date: Sat, 12 Apr 2014 04:10:49 +0000 Message-ID: <835D117E-86A8-47E0-AEDC-F291F20460DF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.220] 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/XQ0RDuj6S58E33wq00AZychd8ZQ Subject: [TLS] Working Group Last Call for draft-ietf-tls-encrypt-then-mac-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Apr 2014 04:10:53 -0000 This is the working group last call for draft-ietf-tls-encrypt-then-mac-00.= txt. Please send comments on this draft to the TLS list before April 28, 2= 014. =20 Joe (For the TLS chairs)= From nobody Sat Apr 12 03:19: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 7C20C1A0402 for ; Sat, 12 Apr 2014 03:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.333 X-Spam-Level: ** X-Spam-Status: No, score=2.333 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 UrGnyhaC9bpE for ; Sat, 12 Apr 2014 03:19:47 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-05-out.s.azet.sk [91.235.53.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7891A03FE for ; Sat, 12 Apr 2014 03:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1397297983; bh=7z3P6fzaiBhkrD4hajvBP5d0JZpAOVsC/I1KDLhXBJU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=wPeStaIW5+wXJHfKFs+FmjSBlTGdYJKLSOaJMO6zB+IxaLT9u5jpJ4CfrxSuMOo8S pbb0YDqzDSTEa8C4v5mhWjsXMPpstmVrH0DL1NWSQnjRCUq5MRkelMLoyB3/n9W/Qm sChBG2YoD/eWHwXS+r7mzf1ZIfp+1YfNOd0TbAKI= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (afo8.torproject.afo-tm.org [178.254.39.32]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id AB2466B for ; Sat, 12 Apr 2014 12:19:38 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk AB2466B 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: <53491338.6060503@azet.sk> Date: Sat, 12 Apr 2014 12:19:36 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <533622F3.2090406@fifthhorseman.net> <87eh18xtrl.fsf@alice.fifthhorseman.net> <53442983.1030703@pobox.com> <53449A18.9000803@fifthhorseman.net> <5347EB9F.8030400@azet.sk> <534823E1.3020707@fifthhorseman.net> In-Reply-To: <534823E1.3020707@fifthhorseman.net> 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/QIVKno85TsYLr81gew9j7BBlfSI Subject: Re: [TLS] Negotiated Discrete Log DHE revision [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, 12 Apr 2014 10:19:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11.04.2014 19:18, Daniel Kahn Gillmor wrote: > On 04/11/2014 09:18 AM, Fedor Brunner wrote: >> Your groups dldhe3072, dldhe4096 look similar to MODP groups 15, 16. If >> you assume that an attack can be developed for MODP groups, could this >> attack be also developed for dldhe3072, dldhe4096? > > probably, yes. at the moment, i believe such an attack on any given > group would be quite expensive in both time and money. My hope is that > it is prohibitively expensive in general, because of the large amount of > computing power and data storage that would be needed to effectively map > the space. but it's possible that an extremely well-funded organization > could pull it off. will they be able to attack two groups in this way? > not without increasing the expenses even further. > > if we use a single group for everything (IKE as well as TLS), the cost > of attacking that group stays the same, but the value of breaking the > group goes up. > >> If you assume an attack exists for fixed DH group then not fixed DH >> groups generated for each server (as is current option in TLS) would >> make the attack much more expensive. > > this is true, but it also makes it possible for bad groups to be used, > either through malice or misconfiguration. arbitrary groups also > increases the size of the handshake significantly, and clients have no > inexpensive way of verifying that the groups have reasonable structure > and that they are not in a small subgroup. With named groups, both > peers can have pre-computed tables that should make ephemeral keying > cheaper and easier, whereas with arbitrary groups only the server gets > this advantage. > >> For example OpenSSH supplies a set of 40 DH groups for each 1023, 1535, >> 2047, 3071, 4095, 6143, 8191-bit primes . During key exchange one of >> these groups with desired size is selected in server by random. The >> OpenSSH server administrator can also generate his own set DH >> parameters, for each prime length. > > i'm aware of this model. in practice, nearly everyone seems to be > content using the moduli that are shipped by their vendor in > /etc/ssh/moduli. > >> Could you please provide estimated strength of the dldhe2432, dldhe3072, ... >> groups ? For example see the estimated strength of MODP groups in RFC 3526 >> >> https://tools.ietf.org/html/rfc3526#section-8 > > yes, that's a good idea, thanks. > >> Please consider describing the algorithm for generation of the groups >> dldhe2432, dldhe3072, ... >> The generation of MODP groups is described in RFC 2412 (Appendix E) > > do you think the introduction to Appendix A is insufficient? if so, do > you have a concrete suggestion for how it should change? You have stated why the high and low bits are ones (Montgomery or Barrett reduction), please describe also the decision to use the base of the natural logarithm for the middle part of discrete log groups. For example in RFC 2412 (Appendix E) " The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. " > > --dkg -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTSRM4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtiQUQALTcHlrEMKK82SsLaHku1GLL xg+eWZnhkHc36xkeMDQsvY6DIPRHbdyyqP79pdRGJt7ZJHJ53lXxYHoSepnarwNa DFRcwP5HHwPMXpFlylnDXWcBrCalM00AgSUR6tGlHVpnxRnqajKYunLKqSl1/HYC C9hWtyfv7M7J6lba/yq7rP6DDJEK1llGYYxCSwtO1qhXsg7gjTRjDCBIIYv5UIbU CVsrmH7KNchxPID7CGjC0SQcJUATrxuGXtMpOqB7IwnvFNClQ75cDb4eISV6ye6U vkA1xqVgiESp+LUERxOdQzRfL2UMILcNmBBqXYrvL10tW5oR2oRiteoHJLssYTUi BMG9Y662j9EFh+x20TCITOdT/PZkEenpX88oTkMFa6Wxb9Ioz+PclX6V3KFb+RVy nLYqYsuWZq7ewo+r1H+vWbi/tQBPtDbfGUF1akGvwsLhN7a4jJgPty/yCmtGebhr rO//Wi8s1ecjvUBRlS4JN0/KMu/zDQJ8yUEPu9U1aBA7M7PPUF5ePuT9dNrnt5tQ SSisxL/VVxiCeM3xs3ssBpA6bg9UUAFavTU/ngFpuBOw6/rfDvUQAPY+kAQ2d5os 5LaJQi/xUYAk0lyYK3inddyTh9wnp6n1ggoLI33DyibHPZfnh0vIsqpPAfSmeuv4 nyGb7zY1pEoi12n/01mE =8X4w -----END PGP SIGNATURE----- From nobody Sat Apr 12 17:02: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 DFF8B1A0259 for ; Sat, 12 Apr 2014 17:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.427 X-Spam-Level: X-Spam-Status: No, score=0.427 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyoUI6Vib1qs for ; Sat, 12 Apr 2014 17:01:57 -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 A3D591A023D for ; Sat, 12 Apr 2014 17:01:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2B0F7ECAD; Sat, 12 Apr 2014 20:01:55 -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=pULn602W9bqI kzGJoU1bwYcTqmg=; b=KOczKonisDGNh3ydcnTdwjdNn6KJ3SCWr8j5tVdvGKOP kpazWuCSR9Ytbms/D4BQx7W05Qo9Qn7uvMDaEuieuOA/p2erH2xf/0wBT9jWFMmE 6F9tL7gGDSGh7ORplozH7/2qJ/wy5R7GB6fiwRnfs4exCluZmEwamxeSGe8DaSE= 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=Cs0wOL 8N3r4wfxnqmVNV9hmUSmqn/xKWFaEq/FMHbBEGxuSqxdHqYhS+rcS+QKdTayGfco paGlcc9eGV87j2E4le197IMCDRzX/8o7HCgdhEis6Hs/29h/qQsW9t+77BkcZl+V CeCrEM/7X2uDTU74/Mr1HXAqZuOmKMtVFo6og= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2431CECAC; Sat, 12 Apr 2014 20:01:55 -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 E801CECAB; Sat, 12 Apr 2014 20:01:53 -0400 (EDT) Message-ID: <5349D3F0.5010606@pobox.com> Date: Sat, 12 Apr 2014 17:01:52 -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: D25FC6C0-C29E-11E3-A4A2-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QgXUAIGOSHAUID6exARLFkVo9DA Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 00:02:00 -0000 Watson Ladd wrote: > > Professor Gutman has generously cleaned up the mess left by this WG. Would you please stop with the divisive comments? Peter Gutmann is a member of this WG too, so in fact the WG is cleaning up after itself. Mike From nobody Sun Apr 13 02:28: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 1C66E1A02A5 for ; Sun, 13 Apr 2014 02:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.428 X-Spam-Level: * X-Spam-Status: No, score=1.428 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 iwWys5sMzAl7 for ; Sun, 13 Apr 2014 02:27:58 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC831A02A0 for ; Sun, 13 Apr 2014 02:27:57 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 3706D160C1; Sun, 13 Apr 2014 11:27:54 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 4610E2903E; Sun, 13 Apr 2014 11:27:53 +0200 (CEST) Message-ID: <534A5898.6070200@polarssl.org> Date: Sun, 13 Apr 2014 11:27:52 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Lhj83GbnGdnM5ruNG_-eQmKPGd4 Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 09:28:00 -0000 On 11/04/2014 20:50, Eric Rescorla wrote: > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. > I support adoption of this draft by the TLS WG. If the SSH people (and/or others) want to join in and a draft with larger scope than just TLS can be finalized pretty fast, it would be great. Otherwise, I think it's better to deprecate RC4 in TLS asap, and let the other protocols follow at their own pace. Manuel. From nobody Sun Apr 13 09:25: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 785441A01DA for ; Sun, 13 Apr 2014 09:25:41 -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_50=0.8, 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 NJcVBmfpxTOX for ; Sun, 13 Apr 2014 09:25:37 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC6D1A01E7 for ; Sun, 13 Apr 2014 09:25:37 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id rr13so7354274pbb.15 for ; Sun, 13 Apr 2014 09:25:35 -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=WdLDHxBjnp+gudT4iPJVaaOPegwU8G6dqC9ZUFnzs2I=; b=oNU4BKnPxHp4WJTlYaQacO7UkZCpb5aaSPEkxE4VLhwzetUSWEh9T/D5+7WDKxdido ru828qs300j/Q/C2JtweuvS8E4t2IL2E8wsiJpgvhv0o5glRiCTR3ntd1uk5FmXf2nka Ml5kC4qCjDwCjeMst2iHMIFxkL9LPWS6T+sapuUXsDIoLUBV/2BM4va48qY694+vop8Q v9VnFN+66A2FsYOnEVAbxdjmIhfbMHXIVu1jhtn1VIx+958+Xy5r6kUQJjpNBOmXuktB SWaJOIkAst8jJuuwiRrADR9n6rP+zz6SaHieDN8CkKJUnf9yP2wLSKAjcNYtAgyQxqD0 a8rw== MIME-Version: 1.0 X-Received: by 10.66.150.228 with SMTP id ul4mr39467691pab.16.1397406335363; Sun, 13 Apr 2014 09:25:35 -0700 (PDT) Received: by 10.70.131.16 with HTTP; Sun, 13 Apr 2014 09:25:35 -0700 (PDT) In-Reply-To: <53441A51.2080800@fifthhorseman.net> References: <20140107201722.ECDA01AB93@ld9781.wdf.sap.corp> <5341EFA4.7070808@brainhub.org> <53441A51.2080800@fifthhorseman.net> Date: Sun, 13 Apr 2014 09:25:35 -0700 Message-ID: From: Peter Bowen To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PtUdj9bV3atxhxFtyMHtgrloCpg Cc: "tls@ietf.org" Subject: Re: [TLS] Next steps for draft-agl-tls-padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 13 Apr 2014 16:25:41 -0000 On Tue, Apr 8, 2014 at 8:48 AM, Daniel Kahn Gillmor wrote: > On 04/07/2014 01:40 PM, Watson Ladd wrote: >> I read the F5 explaination. It's worth keeping it around so in the future, >> when tempted to upgrade a binary protocol we ask the guy proposing the >> upgrade how to distinguish old and new. >> >> In particular, tossing it down the memory hole out of misguided >> professional courtesy would probably mean making the same mistake in the >> future. >> >> In particular treating this extension's proper use as something to be >> passed on by word of mouth hurts new implementors who don't know the magic >> number. Embarrassment for F5 is nowhere near as serious. > > I agree with Watson here. Including some variant of Xiaoyong Wu's > explanation in the padding draft would be useful for future > implementers. The global network *does* still have SSLv2 endpoints on > it, and they connect to and listen on ports that SSLv3/TLSv1.{0,1,2} > peers also use. This sounds like ideal example appendix material. It doesn't need to explicitly call out certain products by name, rather it could suggest that real world implementations have been observed... Thanks, Peter From nobody Sun Apr 13 13: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 875DD1A0245 for ; Sun, 13 Apr 2014 13:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.071 X-Spam-Level: ** X-Spam-Status: No, score=2.071 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 EaAmFDHbmiiP for ; Sun, 13 Apr 2014 13:14:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 37FC21A0242 for ; Sun, 13 Apr 2014 13:14:26 -0700 (PDT) Received: from [192.168.37.143] ([81.145.171.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MO7Ca-1Weuy11zwS-005bo8; Sun, 13 Apr 2014 22:14:21 +0200 Message-ID: <534A8314.4070104@gmx.net> Date: Sun, 13 Apr 2014 13:29:08 +0100 From: Hannes Tschofenig 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: <71FF0D29-AD00-4438-BB30-11F4FFDFB42C@cisco.com> In-Reply-To: <71FF0D29-AD00-4438-BB30-11F4FFDFB42C@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sBjUHN12WN3omIti3rttrlsf33DgFt730" X-Provags-ID: V03:K0:KnMCys3h4+byXgSf6xgO73xM1KkzvhcrczND/ZLRYl1AArvq8QF q0UkqzOTDUZV4vbNCTeRe/+qeSVQPp/vw5G8B1+8watUvVNnhj/8WNi6V3zOAHzg4EywAx9 8oZPj7gG7fF3O5UBS4jsfkrY1P9PjfERLEK7x1FOHoWo0iEvpGENzk2A22jvvHeQo8ITraf lqnyPfvkiLJcCkHUb7u/Q== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qp5plcVXNAH626MDnRZD45pGyRQ Subject: Re: [TLS] TLS Interim Meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 20:14:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sBjUHN12WN3omIti3rttrlsf33DgFt730 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe, Hi Sean, I cannot do this date if the meeting is in the US. Could we have a few more dates to choose from? Ciao Hannes On 04/10/2014 08:17 AM, Joseph Salowey (jsalowey) wrote: > Folks, >=20 > The chairs want to schedule a TLS WG interim to see if we can close on = some of the handshake flow issues. We hope to get key contributors to thi= s discussion on the dates below. >=20 > Cisco has agreed to let us use their office in Denver, which is central= ly located and an airline hub. We would like to shoot for 1 1/2 or 2 days= =2E In order to avoid requiring people to travel on the weekend, we were = thinking of May 13-14 or May 14-15. We will also try to have Webex availa= ble for remote attendance.=20 >=20 > If you have an opinion about these dates, please let us know by email b= y Monday April 14 to tls-chairs@tools.ietf.org. We intend to finalize the= date immediately thereafter. >=20 > Thanks, > [Chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --sBjUHN12WN3omIti3rttrlsf33DgFt730 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTSoMUAAoJEGhJURNOOiAtHnQH/0W1TpHwTNLew9TGhPAHUG1o FtYnuXUdSWnJ6p61hHfEnlMYClyo9rGBDb/Nhz0J+dDaepH4EGrShvhdpFTHclKx qNJMt872fUs5aFGYObV0KXJP6PpuH2go9RnvKNS/rzNa4uQkRjhAUQFkQpfhSGEs b0ayzOiGhIBQXqUPQZwIc198ZewQpEjrZJ65N1db3NgCcjvHD75jgU2/4LDNoSWp 4ANB/1Q2DQ8a6C2t5fPGKETNH9Nz5+3DfZ5LYkVZne7lCRHRQcLFWsMAtDmDSfAs qxUFFPAgyc3pH68Yt47QuGSpJl/TJ1kD3wqFdThPeraiFP134tSunOCvNNgDUYw= =azVo -----END PGP SIGNATURE----- --sBjUHN12WN3omIti3rttrlsf33DgFt730-- From nobody Sun Apr 13 19:03: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 6A97E1A02F9 for ; Sun, 13 Apr 2014 19:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruhV3S8B4tis for ; Sun, 13 Apr 2014 19:03:48 -0700 (PDT) Received: from mail24c25-2209.carrierzone.com (mail7c25.carrierzone.com [64.29.147.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5D21A02EC for ; Sun, 13 Apr 2014 19:03:48 -0700 (PDT) X-Authenticated-User: ppelleti.speakeasy.net Received: from WhiteAndNerdy.local (dsl017-096-185.lax1.dsl.speakeasy.net [69.17.96.185]) (authenticated bits=0) by mail24c25-2209.carrierzone.com (8.13.6/8.13.1) with ESMTP id s3E23JtU018175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 02:03:21 +0000 Message-ID: <534B41E7.2060004@funwithsoftware.org> Date: Sun, 13 Apr 2014 19:03:19 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Watson Ladd , Dan Brown , "tls@ietf.org" References: <20140409232505.0d6e02b8@hboeck.de> <5346E261.6070602@gmx.net> <20140411002030.6672532.52002.12768@certicom.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=2.1 cv=f9dxWoCM c=1 sm=1 tr=0 a=3bGt9MXpJgS1DxBngKRbCQ==:117 a=3bGt9MXpJgS1DxBngKRbCQ==:17 a=eVbW6KzvAAAA:8 a=g0qM3YM6AAAA:8 a=Cl-syre4SQwA:10 a=0UrRPsxmZrwA:10 a=rtZ2W72OR7QA:10 a=IkcTkHD0fZMA:10 a=SF9KqDZ7AAAA:8 a=CFUF-9m0FYj6wTlU3NsA:9 a=yzQCUNNwnOsEqCj7:21 a=1PjgaCcA5NJQwRR_:21 a=QEXdDO2ut3YA:10 X-CTCH-RefID: str=0001.0A020206.534B41EA.004B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y0cZuqkhw9wN8z-ZtJ00xa6q2Bw Subject: Re: [TLS] Heartbleed / protocol 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: Mon, 14 Apr 2014 02:03:50 -0000 On 4/10/14, 7:24 PM, Watson Ladd wrote: > Systematically ensuring that all invalid length combinations would > have triggered an error would have worked. That's more than some test > vectors. Furthermore, it's not clear how you supply test vectors to a > protocol implementation: it can be done, and should be, but it is > quite a bit of work. Presumably in the form of a pathological client (or server) that sends nasty things to its peer, and checks how it responds to them. Although it would be a lot of work, I think the first step would just be establishing such a test suite that could be used by all TLS implementations, and then many could contribute to it over time. > What could have mitigated this bug would be not disabling OS > protection measures in malloc. Had OpenSSL not used their own malloc, > then on OpenBSD the malloc flags "FGJZ" would have significantly > reduced the impact of the attack, and quite possibly crashed the > process if exploitation was tried. (OpenSSL has bugs that are only > found when you disable their own malloc wrapper, which is why they > didn't do it). Can you elaborate on this, or point me to a place where it has been discussed before? Although crypto/mem.c is complicated enough that I could easily be missing something, I thought that by default, CRYPTO_malloc essentially just wraps the system malloc. How does this wrapper make the system malloc behave any differently? > Various proposals for taint analysis in C have floated around for a > number of years. However, qmail demonstrates that one can write secure > C code without this assistance. One *can* write secure code in any language, but it's a question of ease and probability. Even though DJB can write secure C code, I'm of the opinion that on the whole we'd be a lot better off if security-critical code was written in a memory-safe language. > Furthermore, there was no need to implement heartbeats over TLS for > web servers. Yes. It seems like TLS/DTLS could benefit from "profiles" indicating which features are recommended for which uses. There could be a "web profile", a "mail profile", an "Internet of Things" profile. etc. > However, the fundamental problem isn't anything more than the > developers of OpenSSL being lackadaisical about security. I'm inclined to agree with you, but to be a bit more charitable and specific, I think the problem boils down to two main things: 1) Lack of process. It's unclear who's in charge of OpenSSL, how they decide what features to put in or leave out, when they decide to fix bugs, and so forth. Bugs often languish in the bug tracker, without ever being marked "yes, we will fix this" or "no, we won't." For an outsider, it's unclear how to become involved in OpenSSL in a constructive way, since there seems to be a lack of structure, and almost a certain hostility to outsiders. 2) Trying to be all things to all people. OpenSSL is a huge, general-purpose cryptography library, of which TLS is only a part, despite the name. Besides having the kitchen sink, feature-wise, it also tries to be extremely portable. Supporting obscure, obsolete, or embedded operating systems means the code is much more complicated than it needs to be to support typical use on mainstream desktop and server operating systems. Not to mention that a lot of code is doubled due to the FIPS versus non-FIPS distinction. > miTLS does a much better job, is in a > high level language, costs 10x as much in computation time, and is > guaranteed to be correct. Yes, miTLS seems very tantalizing; it seems like it ought to be used more. (Although I shouldn't be one to talk, since I'm using OpenSSL in my project at work, despite all of its horribleness.) --Patrick From nobody Sun Apr 13 20: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 4068B1A0328 for ; Sun, 13 Apr 2014 20:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkXsW8FnPH0C for ; Sun, 13 Apr 2014 20:31:15 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1F1A0325 for ; Sun, 13 Apr 2014 20:31:15 -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=1397446273; x=1428982273; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=wXEauvY+Ub9hLr12d31T4ckquVscwG21+egAGKyYb2M=; b=EBZH3IKHiDT2J2xi+VAxVafNIXcCLMkgfhvwTic8ZqCtqHJkDxkrP7T4 LtAQdgAsk9y75Ke5afmhrR/JF3yTCDZUFaLJUQ7CeZ0/FerVrtBaVKju8 yv8jukANcpH/st+rCvvKgwMNmjuN8QAmQMEkDHciVIMhrN/snVIlShX+3 4=; X-IronPort-AV: E=Sophos;i="4.97,854,1389697200"; d="scan'208";a="247215190" 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 Apr 2014 15:31:12 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 14 Apr 2014 15:31:11 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] TLS process thread Thread-Index: Ac9XkfttWAvuAW66RZStkL7XroUiOw== Date: Mon, 14 Apr 2014 03:31:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@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/k2luJHb2LRcpnuWC8sAZ08BJc1s Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 03:31:19 -0000 Sean Turner writes:=0A= =0A= >In this case, however, our charter provides a clear starting point, namely= =0A= >RFC 5246, and a mandate to minimize the changes to that document.=0A= =0A= If the charter really does require that then it sounds like it's high time = to=0A= update the charter...=0A= =0A= Peter.= From nobody Sun Apr 13 22:44: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 492301A035B for ; Sun, 13 Apr 2014 22:44:19 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=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 1jzyK8nP1zIu for ; Sun, 13 Apr 2014 22:44:15 -0700 (PDT) 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 1789C1A0354 for ; Sun, 13 Apr 2014 22:44:15 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so7607028yha.16 for ; Sun, 13 Apr 2014 22:44: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=r4odjHTxtKXz/97xlbEYU12Z95RJIOd+cz8w+Ff9xTo=; b=1E9au42axGos5MsUXIKF+52KNCRjjRqSJEfSsn0UcjSk7iq4TANOPEkCdyBk81E3FR MV2JQSK3UGlV+WfnY3KJF+b7jEGYfwa5CRA2Y1kstI7wdHksvZ2mJnkWx23qTMi0ExEv JdZrx7ft0ay0iQq1oTG1OMwqJeBZmm6J4cFE2CmS+vbHbMGN0oe0Rtlc7oWRzzBh2Zru tYoI6pVjFzze9+hpVjYkMnMN6vetpvgTZxVafR6PQQGjjaFv3xF4XeccjW/l4jEqcci4 bjMAEwB9/et5rlCOk1oGAi8YSVf7GWFcYkKuKo8jjzMcQ4m3/hsbL5xIPeWGlU7ZoOoT H/QA== MIME-Version: 1.0 X-Received: by 10.236.162.65 with SMTP id x41mr54144866yhk.25.1397454252685; Sun, 13 Apr 2014 22:44:12 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 13 Apr 2014 22:44:12 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Sun, 13 Apr 2014 22:44:12 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PuckphtX1rk2Sho5J8vIAj_9Ctw Cc: "" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 05:44:19 -0000 On Sun, Apr 13, 2014 at 8:31 PM, Peter Gutmann wrote: > Sean Turner writes: > >>In this case, however, our charter provides a clear starting point, namely >>RFC 5246, and a mandate to minimize the changes to that document. > > If the charter really does require that then it sounds like it's high time to > update the charter... In particular, we need to make significant changes to the handshake to address insecure resumption, use a completely different record layer because of Lucky13 (might as well make it AEAD, as Chacha20+Poly1305 and AES-GCM do that, and whatever fixed up AES+hash people want to use can be shoehorned in), renegotiation is probably going to die as no one needs it. (HTTP can use another header number to signal that you need a certificate, a reconnection is not the worse thing in the world, no one understands what renegotiation is supposed to do, and client certificate sensitivity can be fixed by not putting real names in them) That's going to be a pretty big change from RFC 5246. Trying to keep the textual changes minimal probably a lost cause at this point, and will hurt, rather than help clarity. This is before we try to reduce round-trips, eliminate unused ciphersuites, introduce the Edwards curves (necessary for security because people do not write perfect code, even when they should), and ensure that what we write matches what we prove (because as I'm sure you know from my opposition to Dragonfly, I do not support mechanisms that are not shown to be secure from well picked assumptions) We can't not make the first changes, and it seems like the second half of the changes are going to happen anyway. Unless you want another block of MTI extensions that obviate vast swaths of the RFC, the entire protocol needs to be edited and presented as a whole. I don't see a way to do that and adhere to "minimize changes". Sincerely, Watson Ladd > > Peter. > _______________________________________________ > 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 Apr 13 23:24: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 B03141A0366 for ; Sun, 13 Apr 2014 23:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ArZUg4tuoUtq for ; Sun, 13 Apr 2014 23:24:19 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AC8681A0269 for ; Sun, 13 Apr 2014 23:24:19 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F288A1022404C; Sun, 13 Apr 2014 23:24:16 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 13 Apr 2014 23:24:17 -0700 (PDT) Message-ID: <893a7ae7cda81ea367513ef5bd107088.squirrel@www.trepanning.net> In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Sun, 13 Apr 2014 23:24:17 -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/BCqnPqKuLFJhV4tpYJOtoLIcGMo Cc: tls@ietf.org Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 06:24:20 -0000 On Sun, April 13, 2014 10:44 pm, Watson Ladd wrote: > That's going to be a pretty big change from RFC 5246. Trying to keep > the textual changes minimal probably a lost cause at this point, and > will hurt, rather than help clarity. This is before we try to reduce > round-trips, eliminate unused ciphersuites, introduce the Edwards > curves (necessary for security because people do not write perfect > code, even when they should), and ensure that what we write matches > what we prove (because as I'm sure you know from my opposition to > Dragonfly, I do not support mechanisms that are not shown to be secure > from well picked assumptions) Really? And Edwards curves will necessarily result in perfect code? Certainly not as a result of draft-ladd-safecurves! So what assures perfection in Edwards curves implementations then? Dan. From nobody Sun Apr 13 23:29: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 786CC1A037E for ; Sun, 13 Apr 2014 23:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvH5kok2nAQe for ; Sun, 13 Apr 2014 23:29:44 -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 2BC761A0377 for ; Sun, 13 Apr 2014 23:29:44 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A9ECB474C0; Mon, 14 Apr 2014 06:29:39 +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 9DC8B474BF; Mon, 14 Apr 2014 06:29:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 940A1FE070; Mon, 14 Apr 2014 06:29:39 +0000 (GMT) Received: from Tereva.local (172.19.44.105) by USMA1EX-CASHUB4.kendall.corp.akamai.com (172.27.105.20) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 14 Apr 2014 02:29:38 -0400 From: Brian Sniffen To: Watson Ladd , Peter Gutmann In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Mon, 14 Apr 2014 02:29:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1PTRuAeS2uwGFoFuYHd-U4zZEXM Cc: "" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 06:29:45 -0000 Watson Ladd writes: > On Sun, Apr 13, 2014 at 8:31 PM, Peter Gutmann > wrote: >> Sean Turner writes: >> >>>In this case, however, our charter provides a clear starting point, namely >>>RFC 5246, and a mandate to minimize the changes to that document. >> >> If the charter really does require that then it sounds like it's high time to >> update the charter... > > That's going to be a pretty big change from RFC 5246. Trying to keep > the textual changes minimal probably a lost cause at this point, and > will hurt, rather than help clarity. This is before we try to reduce > round-trips, ... [...] > I don't see a way to do that and adhere to "minimize changes". The most complicating factor I can imagine is multiple regular protocol roles, any of which could be run in parallel: three different ways a client could behave and three different corresponding server behaviors. They can even run in parallel, given an anycasted server! The most important simplification I can imagine is to make the handshake implementation crystal clear and dead simple, up through an authenticated and encrypted channel: amenable to formal methods, to automated search for differences from a verified implementation, and to high-performance implementation without much risk. I'd rather give up fast session resumption for half a decade than continue with a fire-drill of ~annual protocol vulnerabilities. -Brian "Implementation is hard" can be my motto for the week. -- Brian Sniffen Information Security Akamai Technologies From nobody Mon Apr 14 01:34: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 143481A03D6 for ; Mon, 14 Apr 2014 01:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 OQtE9-j_3vRI for ; Mon, 14 Apr 2014 01:34:20 -0700 (PDT) Received: from mordell.elzevir.fr (unknown [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB81A0295 for ; Mon, 14 Apr 2014 01:34:19 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 463801617F for ; Mon, 14 Apr 2014 10:34:16 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 6B24929063 for ; Mon, 14 Apr 2014 10:34:15 +0200 (CEST) Message-ID: <534B9D83.8060401@polarssl.org> Date: Mon, 14 Apr 2014 10:34:11 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "" References: <20140413213329.31266.93177.idtracker@ietfa.amsl.com> In-Reply-To: <20140413213329.31266.93177.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140413213329.31266.93177.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7iBFMpdOQMFScKKV3KhsAdRJfmc Subject: [TLS] Fwd: New Version Notification for draft-josefsson-tls-curve25519-05.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, 14 Apr 2014 08:34:24 -0000 Hi, The "Curve25519 in TLS" draft has been updated. Highlight of the main changes: 1. Switch to little-endian for points (aka public keys). Besides the arguments that has been discussed previously, I feel like it makes the exposition clearer and shorter by allowing to use "Curve25519 from the paper" as a black box, rather than looking at its internals. 2. Add a leading 0x41 byte to the point format, and a corresponding ECPointFormat value to negotiate use of this format in TLS. (The goal here is to allow other formats to be use with Curve25519 in the future.) 3. Update the "Security Consideration" section: a. Mention ephemeral vs "cached" keys in relation with side-channels. b. Don't attempt an exhaustive comparison of Curve25519 with all other curves available in TLS, but limit the comparison to two specific curves : NIST P-256 and Brainpool P-256. Writing an exhaustive comparison is a lot of work, and should probably be a CFRG rather than a TLS document. 4. Add a description of the Curve25519 function, with complete formulas and implementation hints, in an appendix. I'm not sure if this appendix should be part of this document, or become the basis for a separate document, since it is not specific to TLS. Anyway, for now it seemed easier and faster to put a first version here as an appendix. I'm sure many parts of the text can still be improved, but I really think/hope that the parts that affect interop (negotiation, wire format, definition of the PMS) are now quite stable. Unfortunately, I'll be offline for one week starting this afternoon, so I apologize in advance for the delay in responding to your comments. Manuel. -------- Original Message -------- Subject: New Version Notification for draft-josefsson-tls-curve25519-05.txt Date: Sun, 13 Apr 2014 14:33:29 -0700 From: internet-drafts@ietf.org To: Simon Josefsson , "Manuel Pegourie-Gonnard" , "Simon Josefsson" , Manuel Pegourie-Gonnard A new version of I-D, draft-josefsson-tls-curve25519-05.txt has been successfully submitted by Manuel Pegourie-Gonnard and posted to the IETF repository. Name: draft-josefsson-tls-curve25519 Revision: 05 Title: Curve25519 for ephemeral key exchange in Transport Layer Security (TLS) Document date: 2014-04-13 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-josefsson-tls-curve25519-05.txt Status: https://datatracker.ietf.org/doc/draft-josefsson-tls-curve25519/ Htmlized: http://tools.ietf.org/html/draft-josefsson-tls-curve25519-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-josefsson-tls-curve25519-05 Abstract: This document specifies the use of Curve25519 for ephemeral key exchange in the Transport Layer Security (TLS) protocol, as well as its DTLS variant. It updates RFC 5246 (TLS 1.2) and RFC 4492 (Elliptic Curve Cryptography for TLS). 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 Mon Apr 14 03:43: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 4C0491A02B2 for ; Mon, 14 Apr 2014 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi6VU4T4_UrH for ; Mon, 14 Apr 2014 03:43:05 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F21A02A9 for ; Mon, 14 Apr 2014 03:43:02 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id DE10E1A0097 for ; Mon, 14 Apr 2014 12:42:59 +0200 (CEST) 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 rR7maJBvFQh6 for ; Mon, 14 Apr 2014 12:42:55 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 758B31A0088 for ; Mon, 14 Apr 2014 12:42:55 +0200 (CEST) Received: from [10.53.40.204] (port=31390 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WZeLm-00055s-O1 for ; Mon, 14 Apr 2014 12:42:54 +0200 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.181.6; Mon, 14 Apr 2014 12:42:54 +0200 Message-ID: <534BBBAC.1000907@secunet.com> Date: Mon, 14 Apr 2014 12:42:52 +0200 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: References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WuevsDlxnMGNcfwd3pswJ6KG6H0 Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 10:43:07 -0000 I support adoption Johannes Eric Rescorla wrote on 11.04.2014 20:50: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 14 04:04: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 28A221A03C2 for ; Mon, 14 Apr 2014 04:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKhKPScwpEu2 for ; Mon, 14 Apr 2014 04:03:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E6C041A02AE for ; Mon, 14 Apr 2014 04:03:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EBF93BE51; Mon, 14 Apr 2014 12:03:54 +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 sRe88LWCSWCc; Mon, 14 Apr 2014 12:03:54 +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 C86A4BE35; Mon, 14 Apr 2014 12:03:54 +0100 (IST) Message-ID: <534BC09B.6020204@cs.tcd.ie> Date: Mon, 14 Apr 2014 12:03:55 +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: Eric Rescorla , "tls@ietf.org" 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/bW_i-5mQ2v5FNmDby1rUTcn15qE Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:03:59 -0000 I sent a mail to the SSH list. Right now it looks to me like it might be better for TLS and SSH to handle this separately, however each WG wants to deal with it. If that changes and you're in the middle of doing stuff on this, I'll yell. Cheers, S. On 04/11/2014 07:50 PM, Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 14 04:11: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 B0AE41A02AF for ; Mon, 14 Apr 2014 04:11: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 PDMNXnHRTOPv for ; Mon, 14 Apr 2014 04:11:54 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id CB0961A03C1 for ; Mon, 14 Apr 2014 04:11:41 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so3817753wiv.7 for ; Mon, 14 Apr 2014 04:11: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=x8uDtfHsXzbFnKqlaVENHAQbCqVEN7PpP8h2JQKgSyA=; b=BPPxahAj7Bg8IPQL+/mTVlu17V63+F39GWhOr2IO/3xfzLNSkLW+FwAis4qYD79Deb 5zgTiEwjPd/WaprCmXajGMSxUBdlOpKVxRk+zpKG4Ve+7b05+zGprExZdE39Flsput11 bn2Jxp17LVWKrRFY7lxS2bEvnoaUuWGEPOx1eAexlBjw7aabGAQO3cYluFmABviNU+8F T6NgTL8ykyCJ2VR67M8xGIMFTqLrPA1nJ0hZSW6W/d8C2VbANkjrxbLPlUknLnnlmN02 ZfvSrLjhv+IOcg1gNDx8nhhII7CZkVMqDC/wv/JA7/hAGi40TjambRDZbUDTY8BwHtw3 8SXg== MIME-Version: 1.0 X-Received: by 10.180.188.130 with SMTP id ga2mr9257878wic.18.1397473898651; Mon, 14 Apr 2014 04:11:38 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Mon, 14 Apr 2014 04:11:38 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Mon, 14 Apr 2014 04:11:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 13:11:38 +0200 Message-ID: From: Richard Hartmann To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c3862e4fe45a04f6febf41 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/exHRBuo0f03meoKSmvhsrgOJdUE Cc: tls@ietf.org Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 11:11:55 -0000 --001a11c3862e4fe45a04f6febf41 Content-Type: text/plain; charset=UTF-8 Strong support. Richard Sent by mobile; excuse my brevity. --001a11c3862e4fe45a04f6febf41 Content-Type: text/html; charset=UTF-8

Strong support.

Richard

Sent by mobile; excuse my brevity.

--001a11c3862e4fe45a04f6febf41-- From nobody Mon Apr 14 05: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 5FC981A040C for ; Mon, 14 Apr 2014 05:05:59 -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 PwZ-XKQHrNh3 for ; Mon, 14 Apr 2014 05:05:57 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 599C81A0402 for ; Mon, 14 Apr 2014 05:05:50 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so6487885eek.17 for ; Mon, 14 Apr 2014 05:05:47 -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=gGj9N9OQXxDmreounB549WG6sQ8zSt9Zy89dt20wD0c=; b=i7aAeyfqmRnXNr4QtnXKxEeLDBCvOgJ6TdBmb9vva0dH0nEo+MZoh+z4nkgRmzJFTc umSxAfXdER+NDz/64lH9A1vlvv91Qf8G8zUcZEs9IBgmb8BiCd1vEVGmzGrXsn9NT7uF Kch4p89fdHedPvKHkkcqufGdgln0mZpXLMtbN32CyD7Y0ZwhP8KjzKQdeAYLu9GBkOXu lr9/qfQAYD3ac4X4Qw9Q8qkR7URASxYOwrtgJZGuIBpklnY3PQMMNNfwfvxxH/IAswPQ 6zcMeq34306f5dhDVnmhQHEWH5D2y0JUI+3nmNXBgl4XpXhaNi+l8g5L1StmyVzS/o62 nZ4g== X-Received: by 10.15.64.132 with SMTP id o4mr51351159eex.14.1397477147467; Mon, 14 Apr 2014 05:05:47 -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 48sm40539087eei.24.2014.04.14.05.05.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 05:05:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EE7F29D5-B07F-40DE-A0F3-774B71366B50" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Mon, 14 Apr 2014 15:05:19 +0300 Message-Id: <6A868689-C1A5-4E62-BBBB-96A8E8374DB3@gmail.com> References: To: Richard Hartmann X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SWBVrkQvZgshAbFnrzB43eGPj5o Cc: tls@ietf.org Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 12:05:59 -0000 --Apple-Mail=_EE7F29D5-B07F-40DE-A0F3-774B71366B50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Yoav Sent from a computer. Brief nonetheless. On Apr 14, 2014, at 2:11 PM, Richard Hartmann = wrote: > Strong support. >=20 > Richard >=20 > Sent by mobile; excuse my brevity. >=20 >=20 --Apple-Mail=_EE7F29D5-B07F-40DE-A0F3-774B71366B50 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1

Yoav

Sent from a computer. Brief nonetheless.

On Apr 14, 2014, at 2:11 PM, Richard Hartmann <richih.mailinglist@gmail.com> wrote:

Strong support.

Richard

Sent by mobile; excuse my brevity.





--Apple-Mail=_EE7F29D5-B07F-40DE-A0F3-774B71366B50-- From nobody Mon Apr 14 06:56: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 40B771A045D for ; Mon, 14 Apr 2014 06:56:57 -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_34=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 E2xGZKFEoxKl for ; Mon, 14 Apr 2014 06:56:55 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id A40401A03F0 for ; Mon, 14 Apr 2014 06:56:55 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so7916535wes.26 for ; Mon, 14 Apr 2014 06:56: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RNdN0PlzBaEwTeCvE25EpBKukMNhpXQ2Ekm86ccHrGo=; b=HYbs65ybK+4l2Mp3MQ+KuHuAm/TlL4u0F/f3o/LooxoWqpUrK9bpiS3iliBnEXGXee QNgkETB5tPWQGekVq/NCPqK2w1+qvMEZeTUv4J+i/BGITajp3bV6ND/JThNtCPJAf66S QwlqXM5+dWcXg0tZFouYT3utsJ80UcT53vfo6U+dzoUWFGNtn852HM+oJTVb8C4pYux7 +ztzBlTdaHFU1ZSVqPykmPSIXrPHkMQ/gc0tDltdhW2BdrImin46Zfhfo3J/lgijX7px DG5lcruBh/LECg4f28dGDOuC+6BrdyNzkkJmQhZ5xSauSB7yjirjBQSbI8+DR+GVBJqo VoYg== X-Gm-Message-State: ALoCoQncrFWzqI70PamqJJOan++U4RrOqGRrg+OO47PKy9SlTy5uph/RiBq1OecYflc6KY2aTEEu X-Received: by 10.194.187.107 with SMTP id fr11mr647243wjc.70.1397483812724; Mon, 14 Apr 2014 06:56:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 14 Apr 2014 06:56:12 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> From: Eric Rescorla Date: Mon, 14 Apr 2014 06:56:12 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bb03f603cb8b704f7010ebb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/es5hWXXJ6Z4ag_KO1Z0XBOaEihg Cc: "" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 13:56:57 -0000 --047d7bb03f603cb8b704f7010ebb Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 13, 2014 at 10:44 PM, Watson Ladd wrote: > On Sun, Apr 13, 2014 at 8:31 PM, Peter Gutmann > wrote: > > Sean Turner writes: > > > >>In this case, however, our charter provides a clear starting point, > namely > >>RFC 5246, and a mandate to minimize the changes to that document. > > > > If the charter really does require that then it sounds like it's high > time to > > update the charter... > > In particular, we need to make significant changes to the handshake to > address insecure resumption,use a completely different record layer because of Lucky13 (might as well make it AEAD, as Chacha20+Poly1305 > and AES-GCM do that, and whatever fixed up AES+hash people want to use > can be shoehorned in), The latter already exists in Section 6.2.3.3 of RFC 5246. http://tools.ietf.org/html/rfc5246#section-6.2.3.3 All that's required is removing 6.2.3.1 and 6.2.3.2 which define block and stream ciphers and merging any of the relevant text from those into the AEAD section. > renegotiation is probably going to die as no > one needs it. (HTTP can use another header number to signal that you > need a certificate, a reconnection is not the worse thing in the > world, no one understands what renegotiation is supposed to do, and > client certificate sensitivity can be fixed by not putting real names > in them) > Also a simple matter of removing text, though I don't think it's clear that we will actually be able to get away with this. -Ekr --047d7bb03f603cb8b704f7010ebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Apr 13, 2014 at 10:44 PM, Watson Ladd <= ;watsonbladd@gma= il.com> wrote:
On Sun, Apr 13, 2014 at 8:31 PM, Peter Gut= mann
<pgut001@cs.auckland.ac.nz<= /a>> wrote:
> Sean Turner <TurnerS@ieca.com> writes:
>
>>In this case, however, our charter provides a clear starting point,= namely
>>RFC 5246, and a mandate to minimize the changes to that document. >
> If the charter really does require that then it sounds like it's h= igh time to
> update the charter...

In particular, we need to make significant changes to the handshake t= o
address insecure resumption,use a completely different record layer
because of Lucky13 (might as well make it AEAD, as Chacha20+Poly1305
and AES-GCM do that, and whatever fixed up AES+hash people want to use
can be shoehorned in),

The latter already e= xists in Section 6.2.3.3 of RFC 5246.


All that's required is removing 6.2.3.1 and 6= .2.3.2 which define block
and stream ciphers and merging any of t= he relevant text from those
into the AEAD section.

=A0
renegotiation is probably goi= ng to die as no
one needs it. (HTTP can use another header number to signal that you
need a certificate, a reconnection is not the worse thing in the
world, no one understands what renegotiation is supposed to do, and
client certificate sensitivity can be fixed by not putting real names
in them)

Also a simple matter of removi= ng text, though I don't think it's clear
that we will act= ually be able to get away with this.

-Ekr

--047d7bb03f603cb8b704f7010ebb-- From nobody Mon Apr 14 07:15: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 05F7A1A02C4 for ; Mon, 14 Apr 2014 07:14:57 -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 iF2bGNqFSEWz for ; Mon, 14 Apr 2014 07:14:52 -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 6F2A51A011A for ; Mon, 14 Apr 2014 07:14:52 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so4088571wiv.7 for ; Mon, 14 Apr 2014 07:14: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=6bUa4QichXDELf2gaaa+HSPgIlZnQDk73/sPxRlVEo0=; b=PApeDgv7JaxHTKDWlhBkM1pNxHLQRp4KibCR9v91hPrAJK8PUYNxeF/QtWww4Qs7mf A15TINDd9Qy1pC+c3JVZ9ZYT/sbj0xDBqYQNunnfz8qZhgoUKDVzD886GZIOcClXNoWe dB0g//gi1yQmk5ZxFKuIyG5/2tdh5fBsYUOELpS27sOpFkYb1nbuiKLgdcWyZDbdJJ49 Bbtad51uJClHH5dqGpHr30DHNJrTmqRXkXI0pnOAln9XQNabU53kKGTaI5wpigWXqXKc n7c36azL8t7JqBYqaNTNKap7+B0YDfq26xGSMc8kE7l8ILa4Iz0ZuOshhkQT51wbu4R8 dOPQ== X-Gm-Message-State: ALoCoQnnGFca3F1KVj9kRJX1F0zPtUzaxT3ekS+cJuncE8Kz/AN5DA8iXbl81SyNIp9MGpOkRSR0 X-Received: by 10.194.238.231 with SMTP id vn7mr725388wjc.76.1397484889425; Mon, 14 Apr 2014 07:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 14 Apr 2014 07:14:09 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz> From: Eric Rescorla Date: Mon, 14 Apr 2014 07:14:09 -0700 Message-ID: To: Brian Sniffen Content-Type: multipart/alternative; boundary=089e01493d6069e65604f7014ec3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AGb2jOKdnkVVc_H7e8-68ARlymw Cc: "" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 14:14:57 -0000 --089e01493d6069e65604f7014ec3 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 13, 2014 at 11:29 PM, Brian Sniffen wrote: > > The most important simplification I can imagine is to make the handshake > implementation crystal clear and dead simple, up through an > authenticated and encrypted channel: amenable to formal methods, to > automated search for differences from a verified implementation, and to > high-performance implementation without much risk. This certainly seems like a useful goal, but of course likely requires feature set tradeoffs. As I noted in London, probably the biggest complicating feature is SNI encryption, so I'd like to take this opportunity to ask people to read and respond to Rich Salz's message about that: http://www.ietf.org/mail-archive/web/tls/current/msg11823.html Which reminds me that I need to do so myself.... -Ekr --089e01493d6069e65604f7014ec3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Apr 13, 2014 at 11:29 PM, Brian Sniffen <bsniffen@akamai.com&g= t; wrote:
The most important simplification I can imagine is to make the handshake implementation crystal clear and dead simple, up through an
authenticated and encrypted channel: amenable to formal methods, to
automated search for differences from a verified implementation, and to
high-performance implementation without much risk. =A0
This certainly seems like a useful goal, but =A0of course likel= y
requires feature set tradeoffs. As I noted in London, probably = the
biggest complicating feature is SNI encryption, so I'd like to tak= e
this opportunity to ask people to read and respond to Rich Salz= 's
message about that:


Which reminds me that I need to do so myself....<= /div>

-Ekr


--089e01493d6069e65604f7014ec3-- From nobody Mon Apr 14 07:32: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 A627F1A047E for ; Mon, 14 Apr 2014 07:32:54 -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_50=0.8, 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 yDz1MJ0Hy3Hx for ; Mon, 14 Apr 2014 07:32:49 -0700 (PDT) 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 6319D1A0476 for ; Mon, 14 Apr 2014 07:32:49 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so8107571yha.30 for ; Mon, 14 Apr 2014 07:32:46 -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=nJvfcU7U6cAF1VnP+1DBYYGEGd3LnOnw3DOV9vQXymw=; b=u5pGlYDimgS3CtPgICRws5lMSja1MIQO85sAOPenDN8KzAwu1s78LNY6uwHhz0yRXV njHRgsLcfbazbGNEgS6m027zd8vCdi8iFfwoUowGwaDTHL1EmGfTcnAOb3mBszlUCNVm /ucytYa0yo8/6ue6sCMJAexuXosT+po9HHil7v5M3IWKE+Q1qEwPYAi79NUsAnY8sulE FFBxZYiKNExe8r3CPT4F0lhTxCQBe3m7uaG+Nvgi1ho7r9yzf0HBrY91yXo4aqkwW7+M wxeZDFqXQ5k8crmpLJhR6CCjbxLANf9sQk4HVu2qMtXxFdOBaHvGpmoKUv1Qv76Bk3uB eSXA== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr13479648yhi.83.1397485966692; Mon, 14 Apr 2014 07:32:46 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 07:32:46 -0700 (PDT) Date: Mon, 14 Apr 2014 07:32:46 -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/yEwpybx0IVRy7ei4euSCfBmpWWY Cc: "tls@ietf.org" Subject: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 14:32:54 -0000 On Sun, Apr 13, 2014 at 11:24 PM, Dan Harkins wrote: > > On Sun, April 13, 2014 10:44 pm, Watson Ladd wrote: >> That's going to be a pretty big change from RFC 5246. Trying to keep >> the textual changes minimal probably a lost cause at this point, and >> will hurt, rather than help clarity. This is before we try to reduce >> round-trips, eliminate unused ciphersuites, introduce the Edwards >> curves (necessary for security because people do not write perfect >> code, even when they should), and ensure that what we write matches >> what we prove (because as I'm sure you know from my opposition to >> Dragonfly, I do not support mechanisms that are not shown to be secure >> from well picked assumptions) > > Really? And Edwards curves will necessarily result in perfect code? > Certainly not as a result of draft-ladd-safecurves! So what assures > perfection in Edwards curves implementations then? Nothing: you can always do something stupid that leaks information. But on a Weierstrass curve, to add two points you have to 0: Be assured they are on the curve 1: Check that both are not the identity 2: Check they are not the same (and if so double them instead) 3: Check they are not inverses of each other 4: Add them Doing this without branching is hard. Furthermore, to avoid leaking information about the top bit of your exponent, you need to either massage the exponent representation or do dummy calculations, along with tracking when to start doing the real calculations. I've written constant time P256 code. It wasn't easy, and there is one particular exponent that will not get handled correctly (namely the group order, which is fine because I'm doing ECDH with random secret keys, and signature verification runs in not constant time). RFC 6090 gets this completely wrong. By contrast on Edwards curves, there are no cases to consider: there is only a formula that holds true for all cases. There can be no curve checks: via compression we ensure that all considered points are on the curve. There are no side channels at this level if you use a masked table load, as there are no branches. It's significantly easier to write the code and reason about it: naive double and add will work. The same holds true for Montgomery curves, which is why the Curve25519 has attracted a lot of interest. Of course, you could always suggest text to be added to draft-ladd-safecurves or write one yourself on implementation of these curves if you are dissatisfied with it. You could always write your own draft if you had an alternative approach to presenting them. Sincerely, Watson Ladd > > Dan. > > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Apr 14 07: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 697971A0466 for ; Mon, 14 Apr 2014 07:40:52 -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_50=0.8, 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 THOLr8tPOGmk for ; Mon, 14 Apr 2014 07:40:45 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 485E61A043E for ; Mon, 14 Apr 2014 07:40:45 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so7492712ykq.35 for ; Mon, 14 Apr 2014 07: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:content-transfer-encoding; bh=4rpLB5JwMVhmUB7c21dvcDgJbfFuuPVI99aQpyPD/wU=; b=vZauduA9NllD9kMFSXTn36Ls1/qnYrBOy+m+zOESYcn5bfSI6kvU1tj/ZAKGHy0RcU uikeu5fqNc8UI71cfgkeIPv0JyFi0F2Sp/mFzHQm37nPbbZJiJgpDxRTXBWujqkw4Csb y4AkQR6RKnZcTux+FCfCILbakTxxmVYui1iTTNGY/ryX9lrlNu/WGwxoK8E6T4Z7xFku KL//JZlh0eMgfimEn/EcjqHXOaUIOxO10/2V9pFP3S8gFgQ/aXUTpaTp9Zff23xFt/Id xK5gj2CDhQnnW0Pdaf65Y7qRjY/EEB3mwvX0KKRzB3g2wslB7j3mtvCWvc2gsnahNn8O y6JA== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr57582401yhj.63.1397486442643; Mon, 14 Apr 2014 07:40:42 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 07:40:42 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> Date: Mon, 14 Apr 2014 07:40:42 -0700 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/uN2pbsH3ze_el2u3wS3ZTaJ8s-o Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:40:52 -0000 On Mon, Apr 7, 2014 at 7:29 AM, Salz, Rich wrote: > I have concerns some about SNI encryption. > > First, I think it addresses a problem that is actually not that important= for most. There are comparatively few sites on the web that have multiple = properties served from a single host (or cluster). Certainly the biggest si= tes that received the most publicity for being under attack by the NSA -- M= icrosoft, Google, Yahoo, etc. -- are really a few to smallish number of ser= vices. And those companies have the wherewithal to deploy separate identiti= es and IP addresses for their properties. > > Second, it potentially disadvantages a portion of the net: large CDN's an= d their customers. My employer, for example, serves thousands of sites on i= ts TLS network, and encrypting SNI requires us to either have a single long= -lived keypair for all customers, or require an extra RTT for clients to fe= tch an EDH key, perhaps still shared, but hopefully more secure. The latter= is particularly off-putting since customers paying for a "faster, better" = end-user experience are now at a disadvantage. Some in this community might= not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame. > > Third, we have not heard from the real potential community of consumers o= f this. I posit that they are mid-size sites with a "handful" of hosted pro= perties. They are currently adequately served by virtual IP's, and even mor= e so in the future by IPv6. And in terms of adversaries, does it matter whi= ch property within peacefire, for example, a user is contacting? A site un= der surveillance by a national-scale adversary will have *everything* scoop= ed up anyway. > > Let me put some numbers on the previous points. We deliver content for ar= ound 10K domains, each with its own RSA keypair, out of 1500 locations. Wit= hout SNI, that means we need 15Million IP addresses, while being able to us= e SNI we only need one per location (region in our terminology). With SNI e= ncryption we either need to share keys (bad for security, and perhaps not c= ompliant with some regulations) or fragment IPs (bad for the web long-term)= . And that's just us. Add in all the CDNs, hosting companies, cloud provid= ers... it's big. Do we know what people like AWS, Rackspace, IBM Cloud, et= c., think about this? > > Fourth, it potentially "unlevels" the playing field. Organizations that h= ave both a browser and servers of interest could, trivially, arrange to pus= h out keys on a regular basis. I am not suggesting that anyone is planning = on doing this, but I fear the temptation to do so in the name of "improving= the user experience" will prove too great. In darker moments, I extrapolat= e the " browser list of CA's" story and imagine a future where Chrome talk= ing to Google will be faster than IE talking to Bing, and Firefox will end = up selling slots in its EDH store (sic) to attract revenue. > > Fifth, it introduces unknown security and trust implications in browsers.= It took years to make "certificate stores" actually secure. And we are pot= entially opening up a new avenue of active attacks over the network while i= ncreasing the expectation that things are more secure. We are also increasi= ng the client-side attack surface. > > Sixth, it adds an extra burden to servers. I think it also improves poten= tial DoS attacks, since they could start at the first PDU exchange. > > Seventh, it ignores some of our own history. When HTTP/1.1 mandated the H= ost header, the virtual hosting industry was created. Until virtual IP's we= re well-known and SNI was widely adopted (I'm being charitable here), adopt= ion of TLS among hosting providers had significant drag. If SNI is routing,= then routing is plaintext and we are now going hide it without understandi= ng the trade-offs. > > Finally, it is a lot of mechanism. As ekr said in London, "you have to d= o all this if you want to protect the SNI." It's not worth it. > > I think we're going too far, and we should come down on the side of simpl= icity, not for its own sake, but for security's sake. Furthermore, it doesn't actually protect the SNI in the current envisioning. Censorship-resistance and privacy can come from TOR, which you need to use anyway to get both. I think Rich Salz has outlined very compelling reasons not to support SNI. 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 Mon Apr 14 07:48: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 C33FD1A044B for ; Mon, 14 Apr 2014 07:48:26 -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 L9fGVJTE1n5J for ; Mon, 14 Apr 2014 07:48:25 -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 6FA131A0468 for ; Mon, 14 Apr 2014 07:48:25 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id i57so6706991yha.28 for ; Mon, 14 Apr 2014 07:48:22 -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=J5lgFII3oEHkvN/aa/b6KtOXyxV+E03w8PZOP2q2ejw=; b=JXB7P+06IqjXn/jMecyUh79NX8GEYk8UR0+iVGrDifF/9WZOnOPjysuWP6Ra60z0s6 rZrkPm5/0xxkf1qc/+S88WB960Kxh875OG6uSD6paEqa3xajumzXY7/XuT8d/lBEv8OG YpchVXUpwuA1D1WdJmJ0eNLmvZMB8Ch17Mi8qH7aERZ+Jd9x4kQO/3ErDwu94gVx/8RB FnhSt+mcd+tJDoO2te3ZEYJR0Q6ZAU2eOQVSgqmboejFoWZF2PuBIDOo/0WdFZlC8LAY TqB4z9on1kXT2JG8A+8SB7QjNjwKEfCWx61fOzVc81RgOJsvRLn9Q3Y12fg5xyJ1eM8S NmRQ== MIME-Version: 1.0 X-Received: by 10.236.66.135 with SMTP id h7mr3102100yhd.60.1397486902921; Mon, 14 Apr 2014 07:48:22 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 07:48:22 -0700 (PDT) Date: Mon, 14 Apr 2014 07:48:22 -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/OypOoKn4LvxmdEFtyTtOCWa8InM Subject: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 14:48:26 -0000 Dear all, Are there any users of renegotiation beyond authentication with client side certificates? In particular has anyone come up with a use for changing the claimed identity of the server? I think we can do client authentication upgrades via a channel extraction+signing solution while preserving the privacy currently given by renegotiation. I haven't yet run Proverif on this solution, so it might not work, but my intuition is that this will work better than trying to expose the semantics of renegotiation correctly. Renegotation has been responsible for two major security issues, and significantly complicates the TLS handshake state machine and semantics. Sincerely, Watson Ladd From nobody Mon Apr 14 07:49: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 6B3871A049C for ; Mon, 14 Apr 2014 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 1PYihj-pgKMy for ; Mon, 14 Apr 2014 07:48:58 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5D41A0476 for ; Mon, 14 Apr 2014 07:48:58 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E1CB1F3C003; Mon, 14 Apr 2014 10:48:45 -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 B0VvmlKdnv1C; Mon, 14 Apr 2014 10:48:24 -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 E19DBF3C008; Mon, 14 Apr 2014 10:48:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 14 Apr 2014 10:48:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93DF63D4-B003-4B9D-9D55-E3F065724081@vigilsec.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_UxuYpLyYRvFBtPhnG1Y0pKFsoI Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 14:49:02 -0000 > On Sun, Apr 13, 2014 at 11:24 PM, Dan Harkins = wrote: >>=20 >> On Sun, April 13, 2014 10:44 pm, Watson Ladd wrote: >>> That's going to be a pretty big change from RFC 5246. Trying to keep >>> the textual changes minimal probably a lost cause at this point, and >>> will hurt, rather than help clarity. This is before we try to reduce >>> round-trips, eliminate unused ciphersuites, introduce the Edwards >>> curves (necessary for security because people do not write perfect >>> code, even when they should), and ensure that what we write matches >>> what we prove (because as I'm sure you know from my opposition to >>> Dragonfly, I do not support mechanisms that are not shown to be = secure >>> from well picked assumptions) >>=20 >> Really? And Edwards curves will necessarily result in perfect code? >> Certainly not as a result of draft-ladd-safecurves! So what assures >> perfection in Edwards curves implementations then? >=20 > Nothing: you can always do something stupid that leaks information. > But on a Weierstrass curve, to add two points you have to > 0: Be assured they are on the curve > 1: Check that both are not the identity > 2: Check they are not the same (and if so double them instead) > 3: Check they are not inverses of each other > 4: Add them >=20 > Doing this without branching is hard. Furthermore, to avoid leaking > information about the top bit of your exponent, you need to either > massage the exponent representation or do dummy calculations, along > with tracking when to start doing the real calculations. >=20 > I've written constant time P256 code. It wasn't easy, and there is one > particular exponent that will not get handled correctly (namely the > group order, which is fine because I'm doing ECDH with random secret > keys, and signature verification runs in not constant time). RFC 6090 > gets this completely wrong. >=20 > By contrast on Edwards curves, there are no cases to consider: there > is only a formula that holds true for all cases. There can be no curve > checks: via compression we ensure that all considered points are on > the curve. There are no side channels at this level if you use a > masked table load, as there are no branches. It's significantly easier > to write the code and reason about it: naive double and add will work. >=20 > The same holds true for Montgomery curves, which is why the Curve25519 > has attracted a lot of interest. >=20 > Of course, you could always suggest text to be added to > draft-ladd-safecurves or write one yourself on implementation of these > curves if you are dissatisfied with it. You could always write your > own draft if you had an alternative approach to presenting them. >=20 > Sincerely, > Watson Ladd Watson: One thing that I like about the Weierstrass form is that we already have = a lot of code that uses it. Unfortunately, the NIST Prime Curves do not transform onto Edwards for = because they are co-factor 1, and Edwards curves are co-factoer 4. = There are many people that will want FIPS 140 certification of their = implementations, so we need to find a way to accommodate the NIST Prime = Curves even if they are not the default curve. Russ From nobody Mon Apr 14 07:52: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 B09B81A0165 for ; Mon, 14 Apr 2014 07:52:08 -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 h0-_W-Vux-fb for ; Mon, 14 Apr 2014 07:52:07 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 031711A044B for ; Mon, 14 Apr 2014 07:52:07 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id DFE76F3C037 for ; Mon, 14 Apr 2014 10:51:54 -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 cEtk2rh-2YZB for ; Mon, 14 Apr 2014 10:51:33 -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 45302F3C008 for ; Mon, 14 Apr 2014 10:51:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Mon, 14 Apr 2014 10:51:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u3Cusw3Pjf_LWDdkzfu_83JAFCY Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:52:08 -0000 > I think Rich Salz has outlined very compelling reasons not to support = SNI. While I might quibble with a detail here or there, I do agree with the = conclusion. If you need to protect SNI, then TOR or to a lesser extent = TLS-in-TLS can be used. Russ From nobody Mon Apr 14 07:52: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 0AA641A011A for ; Mon, 14 Apr 2014 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InO_A4DOIYfC for ; Mon, 14 Apr 2014 07:52:32 -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 9CDA41A04A1 for ; Mon, 14 Apr 2014 07:52:32 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D72101656A7; Mon, 14 Apr 2014 14:52:29 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id CC6B5165695; Mon, 14 Apr 2014 14:52:29 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id B3EAB47BD2; Mon, 14 Apr 2014 14:52:29 +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; Mon, 14 Apr 2014 10:52:29 -0400 From: "Salz, Rich" To: Watson Ladd , "tls@ietf.org" Date: Mon, 14 Apr 2014 10:52:28 -0400 Thread-Topic: [TLS] Renegotation redux Thread-Index: Ac9X8Jl0vAAangjaRSSLOfrUtZakNgAAEKMg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FEC2@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/wLzk_VttnJnK9brhSIuQfYFxyzA Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 14:52:34 -0000 > Are there any users of renegotiation beyond authentication with client si= de certificates? Yes, although these days it's a pretty narrow window. Under certain circum= stances, a client can recognize that a server is "authorized" to do stronge= r crypto, and will renegotiate. Search for step-up or server-gated cryptogr= aphy. It's not really needed much any more, although we have at least one = customer with embedded clients that wants it. -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 14 08:01: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 DC9F41A04A7 for ; Mon, 14 Apr 2014 08:01:17 -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 0z0sA88BMYae for ; Mon, 14 Apr 2014 08:01:14 -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 712A21A04BA for ; Mon, 14 Apr 2014 08:01:08 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so8334860wes.32 for ; Mon, 14 Apr 2014 08:01:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OvHqULrFAMtVxgyVrf+8IxVK9v5iTy53CzzGCuPY5VE=; b=SByLAn2DuOuDhZUHVvdwiZcq+Kla4lY+x4U2z926rvn2cf8kyvGelYuOVjp1/iP/vg XZLIR44K8BvIol8rZ+yQbxAB6QUejhK23nJQetaszCbztzhdawXwBnKzQlMfmzHftdbk MBpehN9LTyzTfY4uDJm6Ta2CefZXXlX1zmknhrz/ZZelsplDcBZ7G/gvxIbHeELIxScQ gs5gKVJ+MJPwpkvvKt8IB9SaWIaevW50Nawj+Ec/klIYMc+z8iPxMUioHfYomylotSwk om3xdEXfuoXMlHQzoKxN8XnEykZwK8bgWNarsuEMcsC43Ajgl6Gu377KlrpSzLQ+9Trm gi9Q== X-Gm-Message-State: ALoCoQkD3vLfiGC2W/G+zOoeazDc7fbtEOYRHVBEWvZsjER3UOg9G/4hqSBVrurY+Swxk3M4HK52 MIME-Version: 1.0 X-Received: by 10.180.11.36 with SMTP id n4mr10058071wib.4.1397487665259; Mon, 14 Apr 2014 08:01:05 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 14 Apr 2014 08:01:05 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Mon, 14 Apr 2014 11:01:05 -0400 Message-ID: From: Warren Kumari To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qWSRIGII5km5CTlINM_l1AL8RSg Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:01:18 -0000 On Fri, Apr 11, 2014 at 2:50 PM, Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > There was significant WG support for this draft previously and > then the discussion migrated to UTA where it does not seem > to be terminating. > > The chairs would like to hear from WG members whether they > support adoption of this draft in TLS. Yes please! > While this is not a formal > call for adoption, if we get strong support we will immediately > move for adoption, so now is a good time to raise any > objections you have. 'm confused -- why hold a pre-adoption call and then another adoption call? (not trying to be an ass, really wondering) W > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Apr 14 08:03: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 77C9C1A04A1 for ; Mon, 14 Apr 2014 08:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFpNjZ7OKYX5 for ; Mon, 14 Apr 2014 08:03:44 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 408261A01A6 for ; Mon, 14 Apr 2014 08:03:44 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f73so8092943yha.41 for ; Mon, 14 Apr 2014 08:03: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:content-transfer-encoding; bh=zwmTonPF3ndtxryOpWxy/V4uHyWhjYXD1KiiLf6ZYUE=; b=URPDQArsFUykGee0KXF6yvCd+vKhXhYGs1icn2YUGX4cYUS1gUNpxIntwBdLrc5M8I 92s/s1++MVm9AisGWCv64ot6j/nVmhMEQ5dSRcVBZC8HkTOz6t5+Rt+JuHqUjLfwGoLh ohSTp0hK+uBZNLY9bOfF3fnwXiwjnZHakc4GimfidwXL5yviglEOrGQVQ8j2B3Adydop k4i15vV9Aw8Ea2kEgJacz2DtYlDs5iXlGpbAgfIDgBKjNhGTW694RyX0W2Zg026+k7Gv sRFsnPcW//qcKP7vnpFoclB90neSFeZGVpoZIGinP0tbIVTh0eUhvktUD0IIgqrHkTpN PtQw== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr13732455yhi.83.1397487821655; Mon, 14 Apr 2014 08:03:41 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 08:03:41 -0700 (PDT) In-Reply-To: <93DF63D4-B003-4B9D-9D55-E3F065724081@vigilsec.com> References: <93DF63D4-B003-4B9D-9D55-E3F065724081@vigilsec.com> Date: Mon, 14 Apr 2014 08:03:41 -0700 Message-ID: From: Watson Ladd To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XstFC4H6hKBDR_vsO0Qgz3EUjgs Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 15:03:49 -0000 On Mon, Apr 14, 2014 at 7:48 AM, Russ Housley wrote: > >> On Sun, Apr 13, 2014 at 11:24 PM, Dan Harkins wrot= e: >>> >>> On Sun, April 13, 2014 10:44 pm, Watson Ladd wrote: >>>> That's going to be a pretty big change from RFC 5246. Trying to keep >>>> the textual changes minimal probably a lost cause at this point, and >>>> will hurt, rather than help clarity. This is before we try to reduce >>>> round-trips, eliminate unused ciphersuites, introduce the Edwards >>>> curves (necessary for security because people do not write perfect >>>> code, even when they should), and ensure that what we write matches >>>> what we prove (because as I'm sure you know from my opposition to >>>> Dragonfly, I do not support mechanisms that are not shown to be secure >>>> from well picked assumptions) >>> >>> Really? And Edwards curves will necessarily result in perfect code? >>> Certainly not as a result of draft-ladd-safecurves! So what assures >>> perfection in Edwards curves implementations then? >> >> Nothing: you can always do something stupid that leaks information. >> But on a Weierstrass curve, to add two points you have to >> 0: Be assured they are on the curve >> 1: Check that both are not the identity >> 2: Check they are not the same (and if so double them instead) >> 3: Check they are not inverses of each other >> 4: Add them >> >> Doing this without branching is hard. Furthermore, to avoid leaking >> information about the top bit of your exponent, you need to either >> massage the exponent representation or do dummy calculations, along >> with tracking when to start doing the real calculations. >> >> I've written constant time P256 code. It wasn't easy, and there is one >> particular exponent that will not get handled correctly (namely the >> group order, which is fine because I'm doing ECDH with random secret >> keys, and signature verification runs in not constant time). RFC 6090 >> gets this completely wrong. >> >> By contrast on Edwards curves, there are no cases to consider: there >> is only a formula that holds true for all cases. There can be no curve >> checks: via compression we ensure that all considered points are on >> the curve. There are no side channels at this level if you use a >> masked table load, as there are no branches. It's significantly easier >> to write the code and reason about it: naive double and add will work. >> >> The same holds true for Montgomery curves, which is why the Curve25519 >> has attracted a lot of interest. >> >> Of course, you could always suggest text to be added to >> draft-ladd-safecurves or write one yourself on implementation of these >> curves if you are dissatisfied with it. You could always write your >> own draft if you had an alternative approach to presenting them. >> >> Sincerely, >> Watson Ladd > > > Watson: > > One thing that I like about the Weierstrass form is that we already have = a lot of code that uses it. > > Unfortunately, the NIST Prime Curves do not transform onto Edwards for be= cause they are co-factor 1, and Edwards curves are co-factoer 4. There are = many people that will want FIPS 140 certification of their implementations,= so we need to find a way to accommodate the NIST Prime Curves even if they= are not the default curve. I'm not suggesting we throw out short Weierstrass. I'm saying that Edwards curves need to be a viable alternative for people who don't want the extra complexity and lower performance of short Weierstrass. But yes, the low round trip handshake does have its own requirement on a few commonly supported curves or else the initial offering will be rejected unnecessarily. Having separate curve specific implementations is necessary anyway for optimal performance as the primes are different and the performance characteristics of fields change as you increase the size. Kasper's P224 and AGL's P256 use different radices. Embedded implementations can pick one curve and stick with it, and use generic bignums (with some care to avoid timing issues). Adding Edwards curves to a Weierstrass implementation can be as small as writing a new add and double function, each of about 20 indirect calls, if the implementation was highly generic in the first place. If not, you have to recode and rename more functions. Sincerely, Watson Ladd > > Russ > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Apr 14 08:04: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 BC98F1A049D for ; Mon, 14 Apr 2014 08:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weHqrRp-eoTz for ; Mon, 14 Apr 2014 08:04:25 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7B1A0262 for ; Mon, 14 Apr 2014 08:04:24 -0700 (PDT) Received: from [10.178.100.3] (85-76-79-19-nat.elisa-mobile.fi [85.76.79.19]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 1553540017; Mon, 14 Apr 2014 18:04:17 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Mon, 14 Apr 2014 18:04:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <65998A05-0400-41D9-A641-11F9BE18568F@iki.fi> References: To: Watson Ladd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Cgb0w9a3UiRHw1jPW9gWC68PGzs Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 15:04:26 -0000 > On 14.4.2014, at 17.48, Watson Ladd wrote: >=20 > Dear all, >=20 > Are there any users of renegotiation beyond authentication with client > side certificates? In particular has anyone come up with a use for > changing the claimed identity of the server? I've been under the impression that renegotiation can be used to keep the co= nnection open when the encryption is based on nonces and client/server runs o= ut of usable nonces. The current counters are large enough that this is unli= kely to happen, but if some crypto defines smaller nonces it might be a prob= lem. Disallowing renegotiation would leave both parties with no other choice than= hanging up the connection. Juho From nobody Mon Apr 14 08:07: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 0199E1A04B8 for ; Mon, 14 Apr 2014 08:07:31 -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 jUnVgUOk7CpL for ; Mon, 14 Apr 2014 08:07:26 -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 7D8051A016B for ; Mon, 14 Apr 2014 08:07:25 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so4191968wiv.3 for ; Mon, 14 Apr 2014 08:07: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u7GuErx4AgWc3wjhomf1bA4dqPdVd4ygQ0ErnjiCnpE=; b=gqFg+3ixmZSDrtloacaFRMi16Dq+mSkmxOMUXsdxr0gbdgBquFwL/33NuQ6jrzdBRC EYkzufC7OOnk9bYT7cnjouemwAwgBlYCZrO79RG3o+OAHdpOgrMD2pcq4JqNbS1XZDRF 7h6BVPWwLUg014AYmVywoceaAbRZ70t60uwmvkQMgCLnKrfvQ4FPyLgTR4Ar/Ly3b3vR BaLHqBRQ4zFggy3fMAXXkxlWMzJ9FxLXzWmHxxlwiJOlY44UYYPDPzeUGrswGjH5gbBu 22jP78WGUErDsfgGrruRggqviYmjRv/jK1gBrelxMkJdoQFoon8zREOsLW0LUDzAiMPz aLzg== X-Gm-Message-State: ALoCoQlajfxO7kGyxbIGCiudRO4z6q39EdR8cbWb9/FJNYvG+NsY94VyjfmmnNyFY+qIPxiDBpV8 X-Received: by 10.180.94.226 with SMTP id df2mr9942371wib.1.1397488042526; Mon, 14 Apr 2014 08:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 14 Apr 2014 08:06:41 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Mon, 14 Apr 2014 08:06:41 -0700 Message-ID: To: Warren Kumari Content-Type: multipart/alternative; boundary=f46d04447e615a6ad204f7020aa1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/owOSx5t_nVzZ3Gq1gh_s0AauPxo Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:07:31 -0000 --f46d04447e615a6ad204f7020aa1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 14, 2014 at 8:01 AM, Warren Kumari wrote: > On Fri, Apr 11, 2014 at 2:50 PM, Eric Rescorla wrote: > > Folks, > > > > Andrei Popov has refreshed his draft on deprecating RC4: > > > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 > > > > There was significant WG support for this draft previously and > > then the discussion migrated to UTA where it does not seem > > to be terminating. > > > > The chairs would like to hear from WG members whether they > > support adoption of this draft in TLS. > > Yes please! > > > While this is not a formal > > call for adoption, if we get strong support we will immediately > > move for adoption, so now is a good time to raise any > > objections you have. > > 'm confused -- why hold a pre-adoption call and then another adoption call? > (not trying to be an ass, really wondering) It seemed like there might be a lot of discussion and we were hoping to let that happen and then if it looked like we were going to adopt it, have a mostly discussion free consensus call, much like in-person meetings where we have discussion and then a call for adoption. -Ekr --f46d04447e615a6ad204f7020aa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Apr 14, 2014 at 8:01 AM, Warren Kumari &l= t;warren@kumari.net<= /a>> wrote:
On Fri, Apr 11, 2014 at 2:50= PM, Eric Rescorla <ekr@rtfm.com>= wrote:
> Folks,
>
> Andrei Popov has refreshed his draft on deprecating RC4:
>
> http://tools.ietf.org/html/draft-popov-tls-prohibitin= g-rc4-02
>
> There was significant WG support for this draft previously and
> then the discussion migrated to UTA where it does not seem
> to be terminating.
>
> The chairs would like to hear from WG members whether they
> support adoption of this draft in TLS.

Yes please!

> =A0While this is not a formal
> call for adoption, if we get strong support we will immediately
> move for adoption, so now is a good time to raise any
> objections you have.

'm confused -- why hold a pre-adoption call and then another adop= tion call?
(not trying to be an ass, really wondering)

It seemed like there might be a lot of discussion and we were hoping to
let that happen and then if it looked like we were going to adopt i= t,
have a mostly discussion free consensus call, much like in-person
meetings where we have discussion and then a call for adoption.
=

-Ekr


--f46d04447e615a6ad204f7020aa1-- From nobody Mon Apr 14 08:50: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 B877E1A04AE for ; Mon, 14 Apr 2014 08:50:15 -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 Oqr6hiB43eQ4 for ; Mon, 14 Apr 2014 08:50:11 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id EAF2E1A04D2 for ; Mon, 14 Apr 2014 08:50:10 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 03537F3C03C; Mon, 14 Apr 2014 11:49:59 -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 s0lOJob43E5i; Mon, 14 Apr 2014 11:49:37 -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 C6131F3C036; Mon, 14 Apr 2014 11:49:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 14 Apr 2014 11:49:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <44747264-0367-49BD-AFC7-BB35AEDA12A6@vigilsec.com> References: <93DF63D4-B003-4B9D-9D55-E3F065724081@vigilsec.com> To: Watson Ladd X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QV-CmZ6zKggKwqQHGiIQL7pYdq4 Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 15:50:15 -0000 > On Mon, Apr 14, 2014 at 7:48 AM, Russ Housley = wrote: >>=20 >>> On Sun, Apr 13, 2014 at 11:24 PM, Dan Harkins = wrote: >>>>=20 >>>> On Sun, April 13, 2014 10:44 pm, Watson Ladd wrote: >>>>> That's going to be a pretty big change from RFC 5246. Trying to = keep >>>>> the textual changes minimal probably a lost cause at this point, = and >>>>> will hurt, rather than help clarity. This is before we try to = reduce >>>>> round-trips, eliminate unused ciphersuites, introduce the Edwards >>>>> curves (necessary for security because people do not write perfect >>>>> code, even when they should), and ensure that what we write = matches >>>>> what we prove (because as I'm sure you know from my opposition to >>>>> Dragonfly, I do not support mechanisms that are not shown to be = secure >>>>> from well picked assumptions) >>>>=20 >>>> Really? And Edwards curves will necessarily result in perfect code? >>>> Certainly not as a result of draft-ladd-safecurves! So what assures >>>> perfection in Edwards curves implementations then? >>>=20 >>> Nothing: you can always do something stupid that leaks information. >>> But on a Weierstrass curve, to add two points you have to >>> 0: Be assured they are on the curve >>> 1: Check that both are not the identity >>> 2: Check they are not the same (and if so double them instead) >>> 3: Check they are not inverses of each other >>> 4: Add them >>>=20 >>> Doing this without branching is hard. Furthermore, to avoid leaking >>> information about the top bit of your exponent, you need to either >>> massage the exponent representation or do dummy calculations, along >>> with tracking when to start doing the real calculations. >>>=20 >>> I've written constant time P256 code. It wasn't easy, and there is = one >>> particular exponent that will not get handled correctly (namely the >>> group order, which is fine because I'm doing ECDH with random secret >>> keys, and signature verification runs in not constant time). RFC = 6090 >>> gets this completely wrong. >>>=20 >>> By contrast on Edwards curves, there are no cases to consider: there >>> is only a formula that holds true for all cases. There can be no = curve >>> checks: via compression we ensure that all considered points are on >>> the curve. There are no side channels at this level if you use a >>> masked table load, as there are no branches. It's significantly = easier >>> to write the code and reason about it: naive double and add will = work. >>>=20 >>> The same holds true for Montgomery curves, which is why the = Curve25519 >>> has attracted a lot of interest. >>>=20 >>> Of course, you could always suggest text to be added to >>> draft-ladd-safecurves or write one yourself on implementation of = these >>> curves if you are dissatisfied with it. You could always write your >>> own draft if you had an alternative approach to presenting them. >>>=20 >>> Sincerely, >>> Watson Ladd >>=20 >>=20 >> Watson: >>=20 >> One thing that I like about the Weierstrass form is that we already = have a lot of code that uses it. >>=20 >> Unfortunately, the NIST Prime Curves do not transform onto Edwards = for because they are co-factor 1, and Edwards curves are co-factoer 4. = There are many people that will want FIPS 140 certification of their = implementations, so we need to find a way to accommodate the NIST Prime = Curves even if they are not the default curve. >=20 > I'm not suggesting we throw out short Weierstrass. I'm saying that > Edwards curves need to be a viable alternative for people who don't > want the extra complexity and lower performance of short Weierstrass. > But yes, the low round trip handshake does have its own requirement on > a few commonly supported curves or else the initial offering will be > rejected unnecessarily. >=20 > Having separate curve specific implementations is necessary anyway for > optimal performance as the primes are different and the performance > characteristics of fields change as you increase the size. Kasper's > P224 and AGL's P256 use different radices. Embedded implementations > can pick one curve and stick with it, and use generic bignums (with > some care to avoid timing issues). >=20 > Adding Edwards curves to a Weierstrass implementation can be as small > as writing a new add and double function, each of about 20 indirect > calls, if the implementation was highly generic in the first place. If > not, you have to recode and rename more functions. >=20 > Sincerely, > Watson Ladd Watson: As you say, code optimization is a curve-specific activity. Some people = have spent a fair amount of time to make the modular reduction very = efficient for the NIST Prime curves. If these primes are used in other = contexts, then we can continue to use these efficient routines. Are = there other places we can leverage existing efficient code? Russ From nobody Mon Apr 14 10:14:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B877E1A0663 for ; Mon, 14 Apr 2014 10:14: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 14fDi2E8tFPa for ; Mon, 14 Apr 2014 10:14:20 -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 F378C1A0564 for ; Mon, 14 Apr 2014 10:14:19 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so5683211wib.0 for ; Mon, 14 Apr 2014 10:14: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:from:date :message-id:subject:to:cc:content-type; bh=BlbRDU4/mPWwDU8e60df9T/iQmtbDav3bMkmlCUYSuc=; b=C19n/Z5TVz1DIO+2+7ydtL798YMQyZS4hhGTCe1lZVxHfyud3R+HopQ/PEC+P3Ik3M YJxYuGjC3ioWG48t38iIWElzT3H1ptzyE4iGbgnBXfFzO/9UBndKrdhT5G4LRALrgih+ vFYoDyagThKyle1gIOZEmSU3Dhv0VafdPGvfXrTHMpksDABDc6oGsnsvsXdh1RJbVvLy +RPCd/Ti1nqs56WUW/g3+RuuErWJfraY4n6Q9qeYqgMRkXMxBrYuFTcfYVPpAY2QoHQy 7Rv3FNuvQ7WCvUkERMeVySBZ+y10DKZMkm6jugsGEuf5yTi9S/VVWb+Zj9amJsEcabW1 zF/g== X-Gm-Message-State: ALoCoQlE7xyTQqCFC6a2u9B8Uzv32kCdvZUa/mibf8brrkC6vsCpHBT1jYBoQhOxINojpd2f1Ghu X-Received: by 10.180.94.226 with SMTP id df2mr10411953wib.1.1397495656999; Mon, 14 Apr 2014 10:14:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Mon, 14 Apr 2014 10:13:36 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> From: Eric Rescorla Date: Mon, 14 Apr 2014 10:13:36 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=f46d04447e6136086f04f703d03a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/58cr_ujFYahUrmHUtIG81sZjBf4 Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:14:24 -0000 --f46d04447e6136086f04f703d03a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 14, 2014 at 7:51 AM, Russ Housley wrote: > > > I think Rich Salz has outlined very compelling reasons not to support > SNI. > > While I might quibble with a detail here or there, I do agree with the > conclusion. If you need to protect SNI, then TOR or to a lesser extent > TLS-in-TLS can be used. > I'm not sure that this addresses the requests I have heard for SNI encryption which is to conceal the sites people are going to by default rather than as a special case for the privacy conscious. Hopefully some of the people who have asked for this (e.g., dkg) will weigh in but as I understand it, the concern is that if the only people who attempt to conceal the site being connected to are the privacy conscious, then that's a signal that those connections are worth monitoring. It's certainly the case that there are some additional changes that would be required to make concealing SNI worth doing (principally encrypted name resolution, but also a clear model for how to do traffic padding and other things), but conversely if we don't change TLS to permit concealing the SNI, then we won't get as much value from encrypted DNS. I'm not saying that either of these are slam dunk arguments, but I wanted to make sure they were on the table. -Ekr --f46d04447e6136086f04f703d03a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 14, 2014 at 7:51 AM, Russ Housley <housley@vigilsec.com>= wrote:

> I think Rich Salz has outlined very compelling reasons not to support = SNI.

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

I'm not su= re that this addresses the requests I have heard for SNI
encryption which is to conceal the sites people are going to by defaul= t
rather than as a special case for the privacy conscious. Hopefu= lly
some of the people who have asked for this (e.g., dkg) will w= eigh in
but as I understand it, the concern is that if the only people who
attempt to conceal the site being connected to are the privacy
=
conscious, then that's a signal that those connections are worth
monitoring.

It's certainly the case that = there are some additional changes that
would be required to make = concealing SNI worth doing
(principally encrypted name resolution= , but also a clear model
for how to do traffic padding and other things), but conversely
<= div>if we don't change TLS to permit concealing the SNI, then we
<= div>won't get as much value from encrypted DNS.

I'm not saying that either of these are slam dunk arguments, but
I wanted to make sure they were on the table.

=
-Ekr





=A0
--f46d04447e6136086f04f703d03a-- From nobody Mon Apr 14 11:16: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 C61D21A065A for ; Mon, 14 Apr 2014 11:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZp5m9k8JV9i for ; Mon, 14 Apr 2014 11:16:34 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8601A0655 for ; Mon, 14 Apr 2014 11:16:33 -0700 (PDT) Message-ID: <534C25FE.5060604@akr.io> Date: Mon, 14 Apr 2014 19:16:30 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FEC2@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B48FEC2@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FrXROcO15L06iNGYSfqAtlxgIqo Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 18:16:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14/04/2014 15:52, Salz, Rich wrote: >> Are there any users of renegotiation beyond authentication with >> client side certificates? > Yes, although these days it's a pretty narrow window. Under > certain circumstances, a client can recognize that a server is > "authorized" to do stronger crypto, and will renegotiate. Search > for step-up or server-gated cryptography. It's not really needed > much any more, although we have at least one customer with > embedded clients that wants it. An extraordinary case: those must be VERY embedded clients! :-) I seem to recall those circumstances were clients with 'export-grade' 40-bit crypto who'd step up to 128-bit with an SGC certificate. Weren't we talking about completely removing Ye Olde 40-bit 'Export' Suites? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTCX9AAoJEOyEjtkWi2t6BkUP/1lcXwJAkWrcEeMTvtmyzsU6 u95zG7ZQ207cRbpcxJc70LQtnlCT0ZYk61dk9ncp6a6wMNvEMPTeFwtmpBdxP5E6 N+6rzezR9uZvNgxSwUMUXyyNVlXptSi04MVBZQAzQkoY2cngvG6zJERjdHKl+ZZ4 4ebRbxghqEY1oSZApVb8qHP5LafSTS1jStaCMKXHu7MZTGkkNm5iSoZQggfnHdB9 urAhiHmwRs/EGVhARzi7RH5GDEyX9oJzMVEWX16pocPdLatsCKQCccPXKu4D9xcn mFVfzt5tm35+4UtBlZ9cEoNuBIOqzhFKg69P0ssfD1FKL8TesoWkrZub8A7lWm8o fF/4gw0Q0HjodbwXrGyzXJR5Ftv0GIhcwjy5tMii2ETlBkxo/lEueAeMmGvL5wyz /W+tTIcS0O1xUSak+7qDAPSB5aNvzjpXlKb6CsG9ayUehulwtFyOdKFiCxEbSHee 1571sBUyd0bXvYihOaq5yn872k8yuPNFriQ643TRmLb51022QDDujtK/G1kz+utx P8yUil+luZUwFI+sF/6epCxy46r8YkIQTRnZBlTK+EkqTuTx/XRS6IQly7/LQOKO SdIXAZVbDGh634/hTg7B83GNrG3mxj6+v6plOm/DUTRvQHYoXOu+Sh0v6kVXgZ5d gxX0orP2Ax3RuLB6S7G+ =UAJP -----END PGP SIGNATURE----- From nobody Mon Apr 14 11:18: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 8B5041A0203 for ; Mon, 14 Apr 2014 11:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_D8Ew6yyoOo for ; Mon, 14 Apr 2014 11:18:33 -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 413071A0297 for ; Mon, 14 Apr 2014 11:18:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6927648282; Mon, 14 Apr 2014 18:18:29 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 5D5AF481DD; Mon, 14 Apr 2014 18:18:29 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 45CFB1E03E; Mon, 14 Apr 2014 18:18:29 +0000 (GMT) Received: from Tereva.local (172.19.41.77) by usma1ex-cashub5.kendall.corp.akamai.com (172.27.105.21) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 14 Apr 2014 14:18:28 -0400 From: Brian Sniffen To: Eric Rescorla , Russ Housley In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Mon, 14 Apr 2014 14:18:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YFUQ-FX8et9SlulGP3dykGt8yV0 Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:18:38 -0000 Eric Rescorla writes: > On Mon, Apr 14, 2014 at 7:51 AM, Russ Housley > wrote: > > > > I think Rich Salz has outlined very compelling reasons not to > support SNI. > > > While I might quibble with a detail here or there, I do agree with > the conclusion. If you need to protect SNI, then TOR or to a > lesser extent TLS-in-TLS can be used. > > I'm not sure that this addresses the requests I have heard for SNI > encryption which is to conceal the sites people are going to by > default rather than as a special case for the privacy conscious. It sounds like the information about who is visiting which sites will leak to a passive adversary either from DNS, or from unencrypted SNI, or from which server IP address is used---as long as servers have different opinions about crypto. And as long as the Fed-compliant sites have NIST crypto and the "subversive" sites avoid NISt crypto, they'll have to be on different addresses. A design to preserve anonymity-style privacy from even purely passive adversaries can't fit into the TLS layer---or else Tor wouldn't have so hard a problem. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Mon Apr 14 11:39: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 93C171A06AC for ; Mon, 14 Apr 2014 11:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_24=0.6, 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 4PWqPY14XzF2 for ; Mon, 14 Apr 2014 11:39:33 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1D1A0203 for ; Mon, 14 Apr 2014 11:39:33 -0700 (PDT) Message-ID: <534C2B62.7080301@akr.io> Date: Mon, 14 Apr 2014 19:39:30 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D6SoGbOviM3QbZ5kUcqNA7Hy6yw Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:39:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 14/04/2014 18:13, Eric Rescorla wrote: > I'm not sure that this addresses the requests I have heard for SNI > encryption which is to conceal the sites people are going to by > default rather than as a special case for the privacy conscious. Precisely. Tor (for example) wants to look like a common-or-garden browser to avoid Eve fingerprinting it (and real, actual jackboots knocking doors in as a result). This means, say, browsers should make - and be able to make - the most privacy-preserving choices, too. That benefits everyone. Plaintext SNI makes it really easy to demux connections to the same ip:port tuple without needing state from DNS lookups. That's an advantage for Bob, where Bob has a lot of servers (like Rich does) - but it's also a huge advantage for Eve and Mallory. We should also consider if we can use the same method to protect returned certificates, and any other plain-text ClientHello fields (notably ALPN). We do want that if we can get it practically, so maybe we want something slightly more general than just for SNI. > It's certainly the case that there are some additional changes > that would be required to make concealing SNI worth doing > (principally encrypted name resolution, but also a clear model for > how to do traffic padding and other things), but conversely if we > don't change TLS to permit concealing the SNI, then we won't get as > much value from encrypted DNS. What I'm worried about is the circular argument of doom and defeat: · We don't have encrypted DNS requests, so why encrypt SNI? · We don't have encrypted SNI, so why encrypt DNS? · We don't have encrypted IP: why encrypt over TCP which can be RST'd? · Privacy is hard: let's go shopping. Maybe we should worry less about what we don't have yet: and instead, let's do what we can to build the things we don't have to make Eve's life a little harder in steps. Counterbalancing our wishes of course is how much is useful, practical, and technically feasible, especially at the scales Rich needs to worry about. And I empathise with his troubles there. (I seriously doubt any solution that requires iteration in linear-time with the number of hosted domains is workable, for example!) How can we protect the Hellos in general from Eve and Mallory as much as we can without making Bob's (or, to a lesser extent, Alice's) life too hard? Can we do that in a backward-compatible way? (I'm getting the vague sense that if we can't, things look more like TLS 2.0?) But I don't think we should give up on doing it just because it's a tough problem to solve. It's literally the first thing listed in the WG charter as a "do want" for TLS 1.3: so if we can't deliver that easily, then I think we need to try harder! I'll let you know if any sudden epiphanies arise. Anyone got any bright ideas? - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTCtiAAoJEOyEjtkWi2t6y0kP/1IIj9/ckBXw4Uqsxc2hi998 oPyAC6txJug13s1HyB0Xy0hpcCBiUpzVudbuboBTAc5gEixNFifT+P+GtcpTEcWB MqgRsQd5yCQGsEEzPIqQHwiuaY2bx/V1o4FT6bKqoKAr18aafUuUqD26IchEEVEy 4eaXwNtbAdVOOioke8CBRe4TvdSYg38wpAqMZIdEUlRAOb5wIJ0C+RWNOfLFW7CL OxA1xXNq0y1OOdoOH1rzgfxdi443GskKOWRdcz2NAvBfDQzakvz5NEe9kpF1CFgW fSBk5Z+uIONOlU5rWvXaGuNk+kuSIUquHyLo6pdkBgfD0qE2Z84jEcN83knEHT29 fRNl/OxTUbvjRUv5rfhwGNs/BgLKB/tX4X8hLYLAo6Z/cqdD/hXjZiTDAEEQaqgt Lp1lWqBNKXQbp7FaOC9+RcrETTMw4EW364To9zwn+xFZG94E2Duy0daowZZapVVM 0sNWvvtIMCC2a71NfNqi0BhGkk8ExGwUVsEj333H4ljBb6ywnzPeYpCHXpk9oVYP OFwhzHxlul7qAXq8O7gzuMkQs0BhqbiZR2Myur70kOcdiUkqRuuDh6j6x4W4q9gh YffPV9RrTHVgO+5WxyPk6WCHgKRc2OzSB7g9T7ccmQZ/lzRCrSbEfl89EHWe6wYo LJbuQo1ZYP6GXO63mFyX =wBko -----END PGP SIGNATURE----- From nobody Mon Apr 14 11:40: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 387FC1A06AC for ; Mon, 14 Apr 2014 11:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 vQwXYocox8Qe for ; Mon, 14 Apr 2014 11:40:09 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7715D1A06D9 for ; Mon, 14 Apr 2014 11:40:07 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id mc6so5921617lab.22 for ; Mon, 14 Apr 2014 11:40: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=EOAmnFZLNnn+aGZ7d458Pwtj0mbaDiXVqNAGUgiD3wE=; b=zEffu/yDtYlu+zx7hcs37ZjqwQseZeYwduOl52ycm6XsOwkxah2EubP815OHZ4upmW SQxDwXEOyuGICNK+Gl/XSpVVflPG3jZ/aSdLpJJHq8PfZck0FuuHb33dEq+yHlTonR+H mSqnTewdtjg4MODqUCIPWbZmkfszhOGY8Mh00hV9ficjjidcADod2kHtTgPX+gwWcDz/ Q5hip6I1BgVIacipsVjZLSeeKNu3Db+m34x2rkXUZFXrAcC+OTfYmbmLrS68WMcqzvQj uL3koZNGYqxeFU0+K0uLAEfy+riiBqAxCcQlk9HxKKFrwF5wqf0+YVusAHqHHFGDzoh/ q3Vg== MIME-Version: 1.0 X-Received: by 10.152.120.168 with SMTP id ld8mr31212784lab.12.1397500804359; Mon, 14 Apr 2014 11:40:04 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.90.5 with HTTP; Mon, 14 Apr 2014 11:40:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 14:40:04 -0400 X-Google-Sender-Auth: 1wJT7B-ZaGjqL9KnVnLP9ovRMNk Message-ID: From: Nick Mathewson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pMtWhhCpMIQfssl7F2TIUSxTpCk Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 18:40:10 -0000 On Mon, Apr 14, 2014 at 10:48 AM, Watson Ladd wrote: > Dear all, > > Are there any users of renegotiation beyond authentication with client > side certificates? In particular has anyone come up with a use for > changing the claimed identity of the server? > > I think we can do client authentication upgrades via a channel > extraction+signing solution while preserving the privacy currently > given by renegotiation. I haven't yet run Proverif on this solution, > so it might not work, but my intuition is that this will work better > than trying to expose the semantics of renegotiation correctly. So, I've got an example, but I hesitate to bring it up. Long ago, Tor added a link authentication mode in which we do an innocuous TLS handshake designed to look like a browser talking to a webserver, and then renegotiate with the actual parameters and certificates we wanted. The goal here was to resist attempts to block users from connecting to the network. Using renegotiation here was a mistake and a very bad design. The versions of Tor which prefer this link protocol are all deprecated now. Renegotiation was not a good solution for this problem, for a few reasons: * It only helped somewhat against blocking. It turns out that renegotiating in the way we were renegotiating was weird enough that it didn't actually make us less conspicuous. * It seriously complicated our code. * Because we depending on renegotiation, many of the workarounds for TLS renegotiation bugs broke our clients and servers. I'm only mentioning it here so nobody brings up Tor as an example of projects that need renegotiation. We would have been better off if we had never used renegotiation. Please do not cite Tor as a good use case for renegotiation. > Renegotation has been responsible for two major security issues, and > significantly complicates the TLS handshake state machine and > semantics. To add to the parade of ugliness: the presence of negotiation keeps programmers from implementing post-handshake TLS as a filter: you need a notion of "[TLS] read blocked on [TCP] write" and "[TLS] write blocked on [TCPl] read." This adds a great deal of complexity and bugginess to non-blocking programs that want to use TLS libraries. cheers, -- Nick Mathewson From nobody Mon Apr 14 11:57: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 9B41E1A06FA for ; Mon, 14 Apr 2014 11:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 m8hddU5180h9 for ; Mon, 14 Apr 2014 11:56:54 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9F1A0670 for ; Mon, 14 Apr 2014 11:56:53 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so5985753lab.41 for ; Mon, 14 Apr 2014 11:56:50 -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=AXHZknIDqYdRgZALxyOiMG5alHENqVVZ/f52P20hLDE=; b=JbVZQW2NyBfve91BTuenwco6RMBM0BVkS2RivZ75fD8LQfDwkwxY00t2DSsyLKbqvt /QRUebA4AQkGJ1R7c7DhITYOENJhFQMiLam/XMFdKaiHtbA3csA+EO88NRxPTcCZiHPD L6O2GRMh2I8iG4VpGjaK89v4Cttx6YfTlEMsexnJMt4winc5itxyBQU0gp3ZSPbADjNN 6HUC7MmgqfqgsRudjcLVg0iHszM3KKnQmp9349YvrQpSf/auomt1eKAVkiF7DgIFhZoQ e9gH4J1loT5ak5g+PUdVyJIKqp1VolTSPiFgZ3DlXvmv7610dSeyLDfXitgiShreaZ4R OKGw== MIME-Version: 1.0 X-Received: by 10.152.2.131 with SMTP id 3mr30641956lau.20.1397501810823; Mon, 14 Apr 2014 11:56:50 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.90.5 with HTTP; Mon, 14 Apr 2014 11:56:50 -0700 (PDT) In-Reply-To: <534C2B62.7080301@akr.io> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> <534C2B62.7080301@akr.io> Date: Mon, 14 Apr 2014 14:56:50 -0400 X-Google-Sender-Auth: RJ3cVjLAd6La1Ckbu1BuYZ3JT1Q Message-ID: From: Nick Mathewson To: Alyssa Rowan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GzY_ySEl7Zrr1Nho50fcs-6RKac Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:56:58 -0000 On Mon, Apr 14, 2014 at 2:39 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 14/04/2014 18:13, Eric Rescorla wrote: > >> I'm not sure that this addresses the requests I have heard for SNI >> encryption which is to conceal the sites people are going to by >> default rather than as a special case for the privacy conscious. > > Precisely. > > Tor (for example) wants to look like a common-or-garden browser to > avoid Eve fingerprinting it (and real, actual jackboots knocking doors > in as a result). This means, say, browsers should make - and be able > to make - the most privacy-preserving choices, too. That benefits > everyone. [marginally offtopic from the rest of the thread.] In the case of Tor, that's no longer exactly the case. We don't want to deviate _too much_ from typical browser behavior, but we no longer consider "emulate a browser talking TLS to a webserver" to be a viable way to achieve censorship-resistance. We've found, over the years, that there are simply too many degrees of freedom in TLS and X.509 to make this trick work well. Our current link-anticensorship architecture relies instead on a pluggable layer to handle superencipherment and protocol obfuscation/emulation. I don't claim to know what implications this might or might not have for SNI (non-)encryption. cheers, -- Nick Mathewson From nobody Mon Apr 14 12:11: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 42BA61A0666 for ; Mon, 14 Apr 2014 12:11:28 -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 1orjEpzHc1d7 for ; Mon, 14 Apr 2014 12:11:20 -0700 (PDT) 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 4ED971A04A1 for ; Mon, 14 Apr 2014 12:11:20 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id hr17so6076351lab.33 for ; Mon, 14 Apr 2014 12:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BF8cygDWtGjpX+2NNqg49Ykocdybxq9CopWwaSQgtc4=; b=jcxXMR2c45NRZXjXVNN6SoFR9qPMMf8pDU7YgaLm2Bl+mm9r1h1d+IZktZ3vp/EpLb ECOOER7W6vmeWfyEYPQY49MaPEqdgEqsh//vL7IoBH5NFqDaDxzy4/9bq2HxOV2jxFR2 iBsyp5usoqCbLGm2A7LhQmfczQpeuNUQhhIhL+LEq+NkWj7qc2k4QZdn7lhBpPJWFNK+ 5i/9aSkxFWlHAjuXUtewu758oJWdxHWrIlsMrZXZYK5nmX+qTSbEHaq28mugAwoDrsmG j0jX9ZGlWi3LG3aUvF/EkoQ+z8wekI8/gIxEnWZA+KgYoKhT9/uwii2xfdSN0xEdqdlY cT+Q== MIME-Version: 1.0 X-Received: by 10.112.221.227 with SMTP id qh3mr2306935lbc.55.1397502677147; Mon, 14 Apr 2014 12:11:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.35.131 with HTTP; Mon, 14 Apr 2014 12:11:16 -0700 (PDT) In-Reply-To: <44747264-0367-49BD-AFC7-BB35AEDA12A6@vigilsec.com> References: <93DF63D4-B003-4B9D-9D55-E3F065724081@vigilsec.com> <44747264-0367-49BD-AFC7-BB35AEDA12A6@vigilsec.com> Date: Mon, 14 Apr 2014 12:11:16 -0700 X-Google-Sender-Auth: 9tAnM4b5jVnHMemO5TYO6CjlGws Message-ID: From: Adam Langley To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZhWgkyDkQMCQLREkWbmLnTxjpns Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 19:11:28 -0000 On Mon, Apr 14, 2014 at 8:49 AM, Russ Housley wrote: > Some people have spent a fair amount of time to make the modular reductio= n very efficient for the NIST Prime curves. If these primes are used in ot= her contexts, then we can continue to use these efficient routines. Are th= ere other places we can leverage existing efficient code? The generalised-Mersenne forms of the NIST P-curve primes has, I believe, turned out to be a mistake with the benefit of hindsight. More modern curves tend to use near-Mersenne primes which are faster and easier to optimise for. I wouldn't suggest that anyone aim to use NIST P-curve primes because of the existing code base. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Apr 14 12: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 DF43A1A0726 for ; Mon, 14 Apr 2014 12:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qigHEGLRHKnA for ; Mon, 14 Apr 2014 12:56:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 326BF1A0654 for ; Mon, 14 Apr 2014 12:56:24 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 4F2EBF984; Mon, 14 Apr 2014 15:56:19 -0400 (EDT) Message-ID: <534C3D5A.3020406@fifthhorseman.net> Date: Mon, 14 Apr 2014 15:56: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: "Salz, Rich" , "TLS@ietf.org (tls@ietf.org)" References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wiauwvs430RSK51I5bjCvi5CoBM44CHCv" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iTLr1AgB4eizi1mJggBZ6gMVGzQ Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:56:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wiauwvs430RSK51I5bjCvi5CoBM44CHCv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rich, all-- I want to speak up in favor of encrypting SNI (and the rest of the TLS handshake) if at all possible. It would be a shame if TLS did not support sites who wanted to be private except to their clients. If we drop plans to encrypt SNI, we make the tasks of would-be censors and surveillance operators much easier. On 04/07/2014 10:29 AM, Salz, Rich wrote: > First, I think it addresses a problem that is actually not that importa= nt for most. There are comparatively few sites on the web that have multi= ple properties served from a single host (or cluster). Measured by traffic, you may be correct. But if you measure by number of web sites, the opposite is likely to be true. Far more small sites (each with low amounts of traffic) are aggregated on shared hosting providers that re-use IP addresses between sites. These are sites that we will want to protect from passive monitoring. If the default is to protect SNI information from passive eavesdropping, websites which share IP addresses with other sites will be able to remain "dark". (yes, the dns-privacy project will also have to come up with a reasonable fix to that leak). If there is no expectation that servers should be able to handle encrypted SNI, then clients will be unable to hide the identity of the web site they visit from an eavesdropper. For web sites whose names themselves are cause for concern to censors or surveillance operators, and who may evade network address based censorship or monitoring by changing IP addresses fluidly, encrypted SNI is an important mechanism. > Second, it potentially disadvantages a portion of the net: large CDN's = and their customers. I appreciate that large CDNs and their customers face special operational concerns. They already do, whether we encrypt SNI or not. Large CDNs are also uniquely positioned to be able to sort out technical solutions to the challenges posed by encrypted SNI to their business mode= l. On the other hand, If we don't support a mechanism that permits encrypted SNI, then instead we instead severely disadvantage smaller sites that are more vulnerable to censorship and surveillance, and those smaller sites have little recourse other than requiring their guests to use Tor, which comes with its own set of concerns. This is a bad tradeof= f. > encrypting SNI requires us to either have a single long-lived keypair = for all customers, or require an extra RTT for clients to fetch an EDH ke= y, perhaps still shared, but hopefully more secure. The latter is particu= larly off-putting since customers paying for a "faster, better" end-user = experience are now at a disadvantage. Some in this community might not de= ploy TLS 1.3 to avoid the "retry penalty." This would be a shame. The discussion of possible handshake flows suggests that the extra RTT does not need to be in every handshake; several proposals for "semi-static" DHE keys have been put forward already, and second-connections need not have the extra RTT. Depending on how we define the mechanism, the initial SNI-protecting DHE key could even be per-IP address, rather than per-domain, which would allow further reductions in RTT for sites hosted on large farms with a few public-facing IP addresses. > Third, we have not heard from the real potential community of consumers= of this. I posit that they are mid-size sites with a "handful" of hosted= properties. They are currently adequately served by virtual IP's, and ev= en more so in the future by IPv6. And in terms of adversaries, does it ma= tter which property within peacefire, for example, a user is contacting? = A site under surveillance by a national-scale adversary will have *every= thing* scooped up anyway. A major goal is to make traffic to a domain that would be censored as indistinguishable as possible from traffic that would not be censored. If the "solution" is to give each site its own IP address, then we've lost that goal: a censor simply blocks based on IP address. > Let me put some numbers on the previous points. We deliver content for = around 10K domains, each with its own RSA keypair, out of 1500 locations.= Without SNI, that means we need 15Million IP addresses, while being able= to use SNI we only need one per location (region in our terminology). Wi= th SNI encryption we either need to share keys (bad for security, and per= haps not compliant with some regulations) or fragment IPs (bad for the we= b long-term). And that's just us. Add in all the CDNs, hosting companies= , cloud providers... it's big. Do we know what people like AWS, Rackspac= e, IBM Cloud, etc., think about this? You're describing this as though encrypting SNI would mean no more SNI, or one IP address needed per web site. This is not the proposal. > Fourth, it potentially "unlevels" the playing field. Organizations that= have both a browser and servers of interest could, trivially, arrange to= push out keys on a regular basis. I am not suggesting that anyone is pla= nning on doing this, but I fear the temptation to do so in the name of "i= mproving the user experience" will prove too great. In darker moments, I = extrapolate the " browser list of CA's" story and imagine a future where= Chrome talking to Google will be faster than IE talking to Bing, and Fir= efox will end up selling slots in its EDH store (sic) to attract revenue.= ??? If browser vendors want to play these kinds of games, there are already many ways they can play them, up to and including deliberate miscommunication with a competitors' services or software. they're generally not doing that, because it's bad for business. If speed is critical enough to encourage vendors to publish DHE keys for specific IP addresses on a regular basis, they'll want to do this in a standard way that browsers and web site operators could collaborate on. > Fifth, it introduces unknown security and trust implications in browser= s. It took years to make "certificate stores" actually secure. And we are= potentially opening up a new avenue of active attacks over the network w= hile increasing the expectation that things are more secure. We are also = increasing the client-side attack surface. I'm not convinced that certificate stores are "actually secure" if we look at them from a usability perspective, but i think that's a tangent to the SNI point. I think the "new avenue of active attacks" you describe are attacks that: a) are likely to result in connection failures if we design the protocol well b) require timing-sensitive, active control on the 'net, and c) result in revealing server name indication and other handshake parameters. If we opt to avoid encrypting SNI or other parts of the handshake, then a simple passive attacker gets (c) for free, and doesn't need to bother with their own increased visibility (a) or technical difficulty (b). I don't see how avoiding encrypted SNI is a security win, when seen from this perspective. > Sixth, it adds an extra burden to servers. I think it also improves pot= ential DoS attacks, since they could start at the first PDU exchange. I agree, we need to consider this computational burden. Whatever we can do to ensure that DoS amplification is minimal would help legitimate deployments. > Seventh, it ignores some of our own history. When HTTP/1.1 mandated the= Host header, the virtual hosting industry was created. Until virtual IP'= s were well-known and SNI was widely adopted (I'm being charitable here),= adoption of TLS among hosting providers had significant drag. If SNI is = routing, then routing is plaintext and we are now going hide it without u= nderstanding the trade-offs. SNI is communications metadata. If we've seen anything from the discussions and information leaked over the last year, it's that communications metadata is of deep and abiding interest to global surveillance regimes, including those whose activities the IETF has clearly indicated are worth treating as an attack on the 'net. One of the oft-cited complaints about attempts to secure e-mail in an end-to-end fashion is that the header information is not protected. We should avoid leaving TLS in that same state if we can help it. I'm happy to work with folks who have performance and operational concerns to make sure we can address them with an encrypted handshake. These are design tradeoffs that lend themselves to gradual improvement, whether through caching or preloading or other mechanisms. But if we design a new version of TLS that does not encrypt the handshake properly, we leave critical pieces of metadata exposed on the wire for passive attackers, and there are no clear ways to avoid the leakage for people who care about it. Regards, --dkg --wiauwvs430RSK51I5bjCvi5CoBM44CHCv 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/ iQJ8BAEBCgBmBQJTTD1aXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpciCQP/RMkOeD1S2OT0rhPJNo8yiTj M2Vjr6GpgxW1OoO1nJH9TJGlfukxGJU67A6FWhqsbi/l8KrQu5vCqSWiqpRY5idB wEm2HG0hbmk3MKkzUERCcGMqKCxj7iLpeFyj0YC98TQ66WKHcN+prhh1vfkudsxO eveiiCH2NizBrxHPvb9q5INm/AhBRzW9XpriXYJp3ZCqWSocstncqkczKyeDbXYO XXvNHVRt1S+Iybayeh0uZtNaASHodmwREFmFihDUupGCS3CSVuW/zArvOK1bD843 Pkby3hfeiM70NmL5VOJMF8J+9WN0PyKN8ZT7ZPGfiaRBJqJg4NW+Dx4v7kGqDZnz MbzBwjT/pHiNVqzOHmso/fchsHlbi6C7OqCZok/BYCOr7yj2T4W78vG7BHjrchoD 3NnCQV/x0KdWa8NesfdB3xwegnIQHE7oRqLojf1HhwqRpIf+Y49HWT/Cb9SdIAQo UBnsQewIGYylx0KW7uwnYEVIytmJ2yOSdn3kHOdH0iKAQPRKbM06egvpx275wF+H ix8f3DA2rNIlbbz3eMHZ2S0OLgtw5yPGrCrs27LDeXmPmGVxgC3TnZlYxa/gAfEc eTTQzPlow4fplB0mwBYhC5+GCnZMAy+WxIKkJQkO47uUOwkoI/IsYdjFCGFHf+6F mXvG7WJnplsc05IhZGYC =VYpU -----END PGP SIGNATURE----- --wiauwvs430RSK51I5bjCvi5CoBM44CHCv-- From nobody Mon Apr 14 13:38: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 B7B841A06F9 for ; Mon, 14 Apr 2014 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZdUC13ZHhp4 for ; Mon, 14 Apr 2014 13:38:27 -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 D309F1A06E7 for ; Mon, 14 Apr 2014 13:38:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2856A1655CB; Mon, 14 Apr 2014 20:38:24 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 136921655C9; Mon, 14 Apr 2014 20:38:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id E4BA19803E; Mon, 14 Apr 2014 20:38:23 +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; Mon, 14 Apr 2014 16:38:22 -0400 From: "Sniffen, Brian" To: Daniel Kahn Gillmor Date: Mon, 14 Apr 2014 16:38:21 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9YIXnLs1knShYrSpStmfpuoDN2gg== Message-ID: <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> In-Reply-To: <534C3D5A.3020406@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_21F8FD2D-D245-471A-A4E0-545A2097865D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vqb_BWU-uCkX7g8jkRWrKqzQKMo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:38:31 -0000 --Apple-Mail=_21F8FD2D-D245-471A-A4E0-545A2097865D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 14, 2014, at 3:56 PM, Daniel Kahn Gillmor = wrote: >> encrypting SNI requires us to either have a single long-lived keypair = for all customers, or require an extra RTT for clients to fetch an EDH = key, perhaps still shared, but hopefully more secure. The latter is = particularly off-putting since customers paying for a "faster, better" = end-user experience are now at a disadvantage. Some in this community = might not deploy TLS 1.3 to avoid the "retry penalty." This would be a = shame. >=20 > The discussion of possible handshake flows suggests that the extra RTT > does not need to be in every handshake; several proposals for > "semi-static" DHE keys have been put forward already, and > second-connections need not have the extra RTT. >=20 > Depending on how we define the mechanism, the initial SNI-protecting = DHE > key could even be per-IP address, rather than per-domain, which would > allow further reductions in RTT for sites hosted on large farms with a > few public-facing IP addresses. More narrowly to that point: We are in a historically rare position of having one suite of = generally-agreed good crypto: ECDHE, ECDSA*, AES, SHA2. That hasn't = been true most days since the creation of SSL; we've wondered about = export vs. not, 3DES vs RC4, DSA vs RSA, and so on. We're probably = going to end up in that conflicted and confused world again, in which = reasonable people can disagree about their cipher suite choices. = Encrypted SNI means that every site on an address must agree on certain = parts of their cipher suite. In a world where I'd like to operate a backwards-compatible site for = vehicle firmware upgrades, prominent social media sites, and mobile app = back-ends off of one address, that means I'm stuck! I expect to see = that around ECDSA (required by governments) vs. Ed25519 (required by = those frightened by governments), AES (for GCM to computers > 1 kg) vs. = ChaCha (for Poly1305-AEAD to computers < 1 kg), and similar. =20 I don=92t see a path to low-RTT protection of the host identity that = doesn=92t require all hosts in an identity-group to share their = cryptographic politics on many dimensions. And at that point, I can=92t = tell whether you=92re talking to HRW or AI, but if you=92re doing it = from Tibet, you=92re dead anyway. -Brian * With carefully chosen nonces --Apple-Mail=_21F8FD2D-D245-471A-A4E0-545A2097865D 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 - http://gpgtools.org iQEcBAEBAgAGBQJTTEc9AAoJEKC8r+lsJnHJ83kH/3tbGHzbAIuqpUmZDdBZivvY roJlIeGLPDEJH/Eyd7sZYnFeqQWpSlB0PoG4BrsS7lakx/4Jrm3mtZuGDpdmfmmc NubIgtc0lNpQgbeZ4MC1tXq7s3oL98McHf6mu/c34t1CTdH5bPaZt66rNoL6LARY VHH56RzfpcytFdeedgYDyXBZX2R+4MYlor4vw4ZRA5sry1TLFzaveUdUCuvMioZj +jZZTxmR53/QJTsjpdDYF59upY4JpXperlJANFg9nhdpEcJ4kHTTdZgbYhsD1Z1j 9cyixu9/JvIxyhstuguo6IZg2IayZB/+bVtHaUcP5d6UXZhYa7CyPRRsi654KH4= =6CkK -----END PGP SIGNATURE----- --Apple-Mail=_21F8FD2D-D245-471A-A4E0-545A2097865D-- From nobody Mon Apr 14 14:33: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 A1CB21A0671 for ; Mon, 14 Apr 2014 14:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 5Tn1uES2d5BJ for ; Mon, 14 Apr 2014 14:33:13 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 31C621A0231 for ; Mon, 14 Apr 2014 14:33:13 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3ELX9gf020521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Apr 2014 23:33:09 +0200 (MEST) In-Reply-To: To: Eric Rescorla Date: Mon, 14 Apr 2014 23:33:09 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140414213309.0F4821ACBF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5siTGo8bowJBilnblpGTQ0iKMcQ Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) 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, 14 Apr 2014 21:33:17 -0000 Eric Rescorla wrote: > Folks, > > Andrei Popov has refreshed his draft on deprecating RC4: > > http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02 This document does not provide any rationale for "prohibiting" RC4. I'm not aware of any information that RC4 is "broken". As noted in the security consideration section of rfc6229, the RC4 keystream has a small bias that might enable statistical plaintext recovery attacks if the _exact_same_data_ is RC4-encrypted at the _exact_same_positions_ many many times. There might be (higher layer) protocols that do this all by themselves (resend the very same data over and over again) potentially including credentials of a disclosing authentication, and there might be communication peers that can be enticed to do this (such as web browsers). -Martin PS: I recently analyzed a customer problem report with a Java SSL 1.6 client (JBoss) failing interop with our server. The client's Finished message decrypted into garbage with CBC cipher suites. It could be that there is an interop problem in Java SSL clients (Sun/Oracle's SSL 1.6 client) with block cipher based cipher suites. The Sun/Oracle SSL 1.6 client sends RC4_128 first in the list, and if our server was configured to prefer RC4_128 over AES128_CBC, then the interop problem would not occur. The 3DES_EDE_CBC cipher suite also failed interop. A quick test with OpenSSL confirmed that the Sun/Oracle Java client was botching the CBC cipher suite handshakes. From nobody Mon Apr 14 14:40: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 C662E1A075F for ; Mon, 14 Apr 2014 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW5cyg-iDlcr for ; Mon, 14 Apr 2014 14:40:14 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 64BE91A0755 for ; Mon, 14 Apr 2014 14:40:14 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so7080005eek.13 for ; Mon, 14 Apr 2014 14:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nQjofRyRRoIT7/xCk3mp8Y0+Lk3Rop7BKHiLCc3XImA=; b=odm0E8te+pyfDVfZ1wqilMYgqKKUvW9EBwZVSnjOIQQtOyZxODYS6UjLDQJuonT5WQ EDtQj7E3Ks1sShepqpJyB4dk0+oxXC8TWipM4ryNYo5saPPBzNsuRM78cMdTGyIHd3Hz TeNkY81xbq2StcSR7Yr9uh95zLUGIVuiiaO/vN4lbqQgtWEWdskJ8N/KkvGvG6r8e3FJ y1b8RGK5q7GfK1fJY7HI7HN0kuO87zGHj5RGgYnNlEok6HBROvA4qMtc/s4yuFAmz9PQ QcSWdp7MlCD9eVWjtI2JgJJDY3vWXgkV0u1sMyrFKzCWvWVgw7kMryKUPWG+06m/QRJK wSxw== X-Received: by 10.14.99.68 with SMTP id w44mr5428525eef.82.1397511611318; Mon, 14 Apr 2014 14:40:11 -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 t44sm44102876eeo.6.2014.04.14.14.40.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Apr 2014 14:40:10 -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: <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> Date: Tue, 15 Apr 2014 00:40:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8XNkPUva_ySdLqQd4b7AyWxbnJg Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 21:40:17 -0000 Hi While I understand dkg=92s argument for privacy in accessing sites on = shared hosting, I don=92t find that argument compelling. What both web hosting providers and CDNs offer is not server name = privacy. What they sell is cost reduction (because getting however many = 9s they give you on your own servers would be way more expensive), and = CDNs add reduced latency to that. Tacking on a security feature onto = somebody else=92s cost-cutting feature is not likely to provide good = security (or privacy). Hiding the SNI only helps if the same IP address has multiple = properties, and access to those properties cannot be distinguished = except by looking at the SNI. Suppose for example that the one = =93subversive=94 site on a server has a landing page with a certain size = for the main HTML resource. Assuming everyone who lands there fetches = the HTML page and none of the other sites has a landing page of the same = size, you can pretty much find these people by traffic analysis. The = hosting providers or CDNs will have to actively help make the sites = resistant to identification through traffic analysis, and that is = expensive to do and it is not what they=92re selling.=20 On balance, I think hiding SNI offers very little for the trouble it = would take to make it happen. Perhaps a better privacy option would be = to avoid sending SNI and then have the server demux based on an HTTP = Host header. You will need some mechanism to associate the certificate = that you=92re getting with the property, and a DANE record might be able = to help there. Yoav From nobody Mon Apr 14 15: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 1F3F91A031C for ; Mon, 14 Apr 2014 15:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 rulouZ1MhA59 for ; Mon, 14 Apr 2014 15:40:49 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5F1A029E for ; Mon, 14 Apr 2014 15:40:48 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 92E5650A85; Mon, 14 Apr 2014 18:40:42 -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: <6c33eca449c34ca29f205e3c60856e7b@BL2PR03MB419.namprd03.prod.outlook.com> Date: Tue, 15 Apr 2014 08:43:34 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <6c33eca449c34ca29f205e3c60856e 7b@BL2PR03MB419.namprd03.prod.outlook.com> To: Andrei Popov X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Th_FH-CL-G5cmDPtX0UKzwYu_JI Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 22:40:53 -0000 I can understand how this feels weird from a TLS perspective. =46rom the application's standpoint, however, it doesn't make sense to = have two different spaces for identifiers -- one for all possible = protocols / versions / stacks, and one for how they're negotiated over = TLS. If TLS doesn't make this a generic space, we're very likely to see many = applications -- not just HTTP -- need to establish registries that = duplicate / overlap with ALPN's.=20 Cheers, On 11 Apr 2014, at 3:31 am, Andrei Popov = wrote: > Well, I feel strongly enough about this to try and explain my position = on the mailing list. However, It is much more important to me that ALPN = be useful for HTTP/2, so if the "expert review" process approves adding = your protocol stack IDs to the ALPN registry, I will not object :) >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com]=20 > Sent: Wednesday, April 9, 2014 1:54 PM > To: Andrei Popov > Cc: Paul Kyzivat; tls@ietf.org > Subject: Re: [TLS] Questions about ALPN >=20 > On 9 April 2014 13:23, Andrei Popov = wrote: >> This is why I feel that "HTTP/2 over TLS" makes little sense = specifically in the context of ALPN, and "HTTP/2 over TCP" makes even = less sense in this context. Both of these protocol stack identifiers may = be useful outside the context of ALPN, as you correctly explain. >=20 > Agreed. >=20 > I think that we only disagree on the scope of the registry. I'll note = that we've consensus in httpbis to use the greater scope, and will > (reluctantly) establish a separate registry if we need to. We'll = probably put in a non-overlapping + inclusion requirement for the ALPN = registry to avoid issues. It would be easier for us to just use ALPN's = registry. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 14 16:35: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 4F9691A03F0 for ; Mon, 14 Apr 2014 16:35: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 St8MEYkw5a7l for ; Mon, 14 Apr 2014 16:35:10 -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 921581A029E for ; Mon, 14 Apr 2014 16:35:10 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so8721199wgh.15 for ; Mon, 14 Apr 2014 16:35: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=mgNnpVt0x7INDb1KmKqkzC7ZJqt8lwi/9Z8wQFkVtdM=; b=tpR6Wez91UwDzT1fVAZ2UKmhpQEPGTyip2x5HAXSdlA+c6AEKxKK1AiUGNpWoSka9w O8EM8dSrCdU7Y6kZbWiTT7g05/fv8IpT/DMTtiuyT1eJISsFFuPI1/JqYF7DiLSRoKm2 vi2x4YknG33CXntLa/vfDmCSBoXbcVEgCsYSnUBffNftW32IHlOl2yxVWTWH4uQCBCrb Fq3b7cRjRib9cW9bg8yrsqek7ZevWTwpZzNV1pWUwLFPrMhprHveWYY2MD9UfDyUInUh ArdvocYvC+1oQS0AppbcM0iSF0G3jV60887QVMf7B1oz7EfkDg/TWLMQX4kDq1tleyT6 VgBw== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr11466627wic.58.1397518507324; Mon, 14 Apr 2014 16:35:07 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Mon, 14 Apr 2014 16:35:07 -0700 (PDT) In-Reply-To: <20140414213309.0F4821ACBF@ld9781.wdf.sap.corp> References: <20140414213309.0F4821ACBF@ld9781.wdf.sap.corp> Date: Mon, 14 Apr 2014 16:35:07 -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/THO576rn4JzlEEAlkFR1yCOTa0w Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 23:35:15 -0000 On 14 April 2014 14:33, Martin Rex wrote: > There might be (higher layer) protocols that do this all by themselves > (resend the very same data over and over again) potentially including > credentials of a disclosing authentication, and there might be > communication peers that can be enticed to do this (such as web browsers). I'm pretty sure that both instances of "might be" can be replaced by "are". Web browsers use HTTP in this way. Hence the desire to end RC4 use, at least in that context. From nobody Mon Apr 14 16:36:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15811A04A4 for ; Mon, 14 Apr 2014 16:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.426 X-Spam-Level: X-Spam-Status: No, score=0.426 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, 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 rx5Eut9F0yxe for ; Mon, 14 Apr 2014 16:36:17 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) by ietfa.amsl.com (Postfix) with ESMTP id D8D641A029E for ; Mon, 14 Apr 2014 16:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=nE0fhiyiAsz+pCAXgTBYL/Um/K2+JhW+WOyviK0E42c=; b=Egm8dZh++0qMInDFx2KApFbSfg4wKUV33pJ1xUbK6KmUnnUn8jjB36Je0Ef2psiTWlXgG0S4UCAYQU8cd/+149H7ORDjH2OyjDAGtWo/hGej1PHfv0l0sPT3rHkV1VjSmhUWYzK9BlzBlQtHXJ99cnq/xtizCqpRCLjoNkgmGrY=; Received: from localhost ([127.0.0.1]:49863 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from ) id 1WZqQB-0000W7-FO for tls@ietf.org; Mon, 14 Apr 2014 16:36:15 -0700 Date: Mon, 14 Apr 2014 16:36:14 -0700 From: Seth David Schoen To: tls@ietf.org Message-ID: <20140414233614.GI2891@sescenties.(null)> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> 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) Received-SPF: skipped for local relay Received-SPF: skipped for local relay Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xPFBtsegS2tLuiabDOfy1pUwGxg Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 23:36:20 -0000 Yoav Nir writes: > Hi > > While I understand dkg’s argument for privacy in accessing sites on shared hosting, I don’t find that argument compelling. > > What both web hosting providers and CDNs offer is not server name privacy. What they sell is cost reduction (because getting however many 9s they give you on your own servers would be way more expensive), and CDNs add reduced latency to that. Tacking on a security feature onto somebody else’s cost-cutting feature is not likely to provide good security (or privacy). It seems like this argument leads to some odd places if applied beyond the HTTP context. For example, we could say that the ideal is for everyone's e-mail to be hosted on a separate server (indeed, there are some projects that are trying to move in that direction by making it easier for individuals and very small organizations to host their own mail). This suggests that the reason that many people share a single mail server today is cost savings (the costs of mail hosting are amortized, as when many people can share the administration services of a single administrator or staff of administrators, for example). The next step from this observation might be to say that a shared mail host like Gmail or Yahoo Mail or GMX is merely offering cost savings (because it would be expensive to pay for an entire dedicated colocated server, sysadmins doing spam filtering, etc., for each of their millions of users). Since the core consideration that underlies the mail hosting architecture is cost efficiency and economies of scale, it must not be very important to provide confidentiality for who e-mails whom, right? If they cared a lot about that, they could, after all, each use their own mail server. (Oops, now the adversary can see which mail servers connect to one another and figure out who's e-mailing whom from _that_ traffic!) It seems appropriate to me to consider separating the historical and economic reasons that particular hosting arrangements arose from the potential privacy benefits that protocol design decisions can offer to their users today. Traffic analysis wasn't a consideration at all in the emergence of HTTP virtual hosting (or CDNs), and it may not have been a consideration in the original SNI specification either. Still, it's something that these layers may be in a position to facilitate -- or mitigate -- today. > Hiding the SNI only helps if the same IP address has multiple properties, and access to those properties cannot be distinguished except by looking at the SNI. Suppose for example that the one “subversive†site on a server has a landing page with a certain size for the main HTML resource. Assuming everyone who lands there fetches the HTML page and none of the other sites has a landing page of the same size, you can pretty much find these people by traffic analysis. The hosting providers or CDNs will have to actively help make the sites resistant to identification through traffic analysis, and that is expensive to do and it is not what they’re selling. I think Alyssa Rowan's concern elsewhere in this thread about the "circular argument of doom and defeat" applies here too. If we were off in the HTML or HTTP working groups talking about defeating traffic analysis, someone might well say that it was impossible to defeat traffic analysis in a virtual hosting environment because of SNI (!). If there are, let's say, five or seven standards that bear on defeating traffic analysis of Internet communications, each of them can avoid or postpone making changes to address that because the other ones haven't. Meanwhile, some of them could protect against at least some threats even without fixing the others. For example, people here in the TLS WG have regarded unencrypted DNS as a reason that securing SNI may not be much of a win. That's definitely true for, say, a user on a corporate LAN who's concerned about surveillance by their employer. But in other cases the person in a position to see the SNI data isn't necessarily on-path with respect to DNS queries. (For example, an attacker might be spying on the network links into a particular data center, but DNS queries might never go through that data center at all, and indeed might already be cached quite close to the client.) There is research beginning about mitigating traffic analysis of HTTP that relies on the volume of traffic flow. If we imagine that Wikimedia decides to adopt some mitigations for this by padding replies upward to fill some bucket, the ability to protect SNI data could be extremely relevant to _reducing_ the overall amount of padding data required, because the appropriate choice of bucket sizes might depend quite directly on how much other contextual information an adversary can observe about which Wikimedia service a client is accessing. For example, if the network adversary doesn't know whether a user is visiting de.wikipedia.org, fr.wikipedia.org, pt.wikipedia.org, or ko.wikipedia.org, there's a much higher initial uncertainty about which possible encyclopedia article the user is downloading, and so it may be possible to add only a small amount of padding to make the adversary extremely uncertain. (Maybe each of those Wikipedias turns out to already have two images, and between one and five text articles, of between 7160 and 7168 bytes.) By contrast, if the adversary is starting with knowledge that the user is definitely reading a particular language Wikipedia, the set of possible pages is initially tiny and a larger amount of padding traffic might be required. So it's possible to imagine that, if a site takes traffic analysis resistance as an explicit goal, protecting SNI will actually make their hosting requirements _milder_ and reduce load by some metrics. There are clearly upper bounds on how uncertain a server can make the adversary about what the user is doing (for example, the Wikimedia Foundation couldn't convince the adversary that the user was actually playing World of Warcraft as opposed to reading Wikipedia). Protecting SNI, like any localized traffic analysis mitigation, can't make those bounds infinite, just higher than they could conceivably be with cleartext SNI. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From nobody Mon Apr 14 16:57: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 721F91A04E8 for ; Mon, 14 Apr 2014 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClwhtFo2TDC8 for ; Mon, 14 Apr 2014 16:57:12 -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 80B001A04A4 for ; Mon, 14 Apr 2014 16:57:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0AC3311AB5; Mon, 14 Apr 2014 19:57:09 -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=lmVi7DmB7haa UYRr0jAiyEhyHC8=; b=Nxa0ogIcrXWg7kZUTT2ghyFpEH/stDCaGl8LMLGjrNBl zIZpIzdir9MxiAoyiU2QtGeoM1cQurjvkBv9NkvVRG4dkZFPK2yGK+n7h+POqLEn 1BQpBXKihMWk6PX0N0pBFRZRwyypwYRtsfbNgfmJuGcOZzVPjw8daAM396H+72g= 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=qutSz0 2qo2IIwG2h9/h8j/v3mS8ezeLFCTulxXH0+4qWNBX1FSYsPmQUGHzEj4XyZCASJJ Mw8ZsAfrar6itED9rRivvqJ9YT6l3jcLJXEwaPfORPTvHlRBegSp/39dxVDcUPbr Wlo4cHwxVB1wLnWXv95j44FUQDIbKPnBORYOk= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 034F811AB4; Mon, 14 Apr 2014 19:57:09 -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 7C78C11AB1; Mon, 14 Apr 2014 19:57:07 -0400 (EDT) Message-ID: <534C75D2.3010308@pobox.com> Date: Mon, 14 Apr 2014 16:57:06 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Mark Nottingham References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <6c33eca449c34ca29f205e3c60856e 7b@BL2PR03MB419.namprd03.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 7C857A4A-C430-11E3-8306-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X72dN43nrwHGGeLlVVLLkaG9ELU Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Apr 2014 23:57:17 -0000 I think the worry is that there is a combinatorial problem when you try to have identifiers for every possible mixture of protocol and transport merged into a single number, similar to how cipher suite numbers are problematic. Additionally, adding a new low-level transport would break things: As an example, suppose you already have defined "http/2 over TCP" and "http/2 over TLS (over TCP)" and all servers recognize these code points. Now whoever wants to create "http/2 over HNTP" (hypothetical new transport protocol) will need to have all http server software everywhere learn the new code point whether it is aware of HNTP or not, before http/2 could be used reliably over HNTP. So instead of making this mistake, I'd like to see a single code point for application protocol (e.g. http/2) which would be used by TLS in ALPN and then you can combine that with another code point representing the transport if you need this level of distinction ("TCP", "SCTP", "UDP", "TLS over TCP", "DTLS over UDP", etc.). Mike Mark Nottingham wrote: > I can understand how this feels weird from a TLS perspective. > >>From the application's standpoint, however, it doesn't make sense to have two different spaces for identifiers -- one for all possible protocols / versions / stacks, and one for how they're negotiated over TLS. > > If TLS doesn't make this a generic space, we're very likely to see many applications -- not just HTTP -- need to establish registries that duplicate / overlap with ALPN's. > > Cheers, > > > > On 11 Apr 2014, at 3:31 am, Andrei Popov wrote: > >> Well, I feel strongly enough about this to try and explain my position on the mailing list. However, It is much more important to me that ALPN be useful for HTTP/2, so if the "expert review" process approves adding your protocol stack IDs to the ALPN registry, I will not object :) >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Wednesday, April 9, 2014 1:54 PM >> To: Andrei Popov >> Cc: Paul Kyzivat; tls@ietf.org >> Subject: Re: [TLS] Questions about ALPN >> >> On 9 April 2014 13:23, Andrei Popov wrote: >>> This is why I feel that "HTTP/2 over TLS" makes little sense specifically in the context of ALPN, and "HTTP/2 over TCP" makes even less sense in this context. Both of these protocol stack identifiers may be useful outside the context of ALPN, as you correctly explain. >> Agreed. >> >> I think that we only disagree on the scope of the registry. I'll note that we've consensus in httpbis to use the greater scope, and will >> (reluctantly) establish a separate registry if we need to. We'll probably put in a non-overlapping + inclusion requirement for the ALPN registry to avoid issues. It would be easier for us to just use ALPN's registry. > > -- > Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 14 17:10: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 98FEE1A0493 for ; Mon, 14 Apr 2014 17:10:03 -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 nvkPEQprV-gA for ; Mon, 14 Apr 2014 17:09:59 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F075A1A0230 for ; Mon, 14 Apr 2014 17:09:58 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9B3F0509B5; Mon, 14 Apr 2014 20:09:52 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <534C75D2.3010308@pobox.com> Date: Tue, 15 Apr 2014 10:09:48 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <6c33eca449c34ca29f205e3c60856e 7b@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> To: Michael D'Errico X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RTBYL7K5Hh3CcFEIFr0G08bMThk Cc: "tls@ietf.org" Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 00:10:04 -0000 On 15 Apr 2014, at 9:57 am, Michael D'Errico = wrote: > I think the worry is that there is a combinatorial problem when you > try to have identifiers for every possible mixture of protocol and > transport merged into a single number, similar to how cipher suite > numbers are problematic. Yes, that's come up in our discussions a number of times. I think our intended use of ALPN tokens is a bit different. Ciphersuite = agility is about combining a number of different components to get = security properties, and as such there are a fairly large number of = them. If we have a large number (i.e., more then a reasonable handful) of ways = to negotiate HTTP, on the other hand, we risk an interop failure. I.e., the negative consequences of a combinatorial explosion are = promoting *good* behaviour here. > Additionally, adding a new low-level transport would break things: > As an example, suppose you already have defined "http/2 over TCP" and > "http/2 over TLS (over TCP)" and all servers recognize these code > points. Now whoever wants to create "http/2 over HNTP" (hypothetical > new transport protocol) will need to have all http server software > everywhere learn the new code point whether it is aware of HNTP or = not, > before http/2 could be used reliably over HNTP. Why?=20 > So instead of making this mistake, I'd like to see a single code point > for application protocol (e.g. http/2) which would be used by TLS in > ALPN and then you can combine that with another code point = representing > the transport if you need this level of distinction ("TCP", "SCTP", > "UDP", "TLS over TCP", "DTLS over UDP", etc.). That would lead people to believe that they can use HTTP over DTLS (for = example), which isn't defined and isn't interoperable. Someone would = have to go and write the document "how to use HTTP/2 over DTLS", and = then we'd need a way to indicate to the peer that this is supported.=20 Transport abstractions are "leaky" -- as the shift from HTTP/1 to HTTP/2 = has shown, the specifics of the underlying transport matters very much = to how we design and use the protocol. We can't define an application = protocol in complete isolation from the transport (although we can take = steps to make introducing a new transport less painful). To be very clear -- in HTTPbis, we've decided to use the ALPN token to = indicate that a particular stack of protocols is in use, whether or not = TLS is in use. If the TLS WG doesn't like that use of their protocol = element, OK, but we're likely to start pushing back on TLS defining what = an application is and is not, and that's a much larger discussion. Cheers, >=20 > Mike >=20 >=20 > Mark Nottingham wrote: >> I can understand how this feels weird from a TLS perspective. >>> =46rom the application's standpoint, however, it doesn't make sense = to have two different spaces for identifiers -- one for all possible = protocols / versions / stacks, and one for how they're negotiated over = TLS. >> If TLS doesn't make this a generic space, we're very likely to see = many applications -- not just HTTP -- need to establish registries that = duplicate / overlap with ALPN's. Cheers, >> On 11 Apr 2014, at 3:31 am, Andrei Popov = wrote: >>> Well, I feel strongly enough about this to try and explain my = position on the mailing list. However, It is much more important to me = that ALPN be useful for HTTP/2, so if the "expert review" process = approves adding your protocol stack IDs to the ALPN registry, I will not = object :) >>>=20 >>> Cheers, >>>=20 >>> Andrei >>>=20 >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: = Wednesday, April 9, 2014 1:54 PM >>> To: Andrei Popov >>> Cc: Paul Kyzivat; tls@ietf.org >>> Subject: Re: [TLS] Questions about ALPN >>>=20 >>> On 9 April 2014 13:23, Andrei Popov = wrote: >>>> This is why I feel that "HTTP/2 over TLS" makes little sense = specifically in the context of ALPN, and "HTTP/2 over TCP" makes even = less sense in this context. Both of these protocol stack identifiers may = be useful outside the context of ALPN, as you correctly explain. >>> Agreed. >>>=20 >>> I think that we only disagree on the scope of the registry. I'll = note that we've consensus in httpbis to use the greater scope, and will >>> (reluctantly) establish a separate registry if we need to. We'll = probably put in a non-overlapping + inclusion requirement for the ALPN = registry to avoid issues. It would be easier for us to just use ALPN's = registry. >> -- >> Mark Nottingham http://www.mnot.net/ -- Mark Nottingham http://www.mnot.net/ From nobody Mon Apr 14 17:51: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 5FA7C1A03EC for ; Mon, 14 Apr 2014 17:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo7mKtRmqZoi for ; Mon, 14 Apr 2014 17:51:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6E11A024C for ; Mon, 14 Apr 2014 17:51:27 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3F0pOiA028447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Apr 2014 02:51:24 +0200 (MEST) In-Reply-To: To: Martin Thomson Date: Tue, 15 Apr 2014 02:51:24 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140415005124.1D8D01ACBF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2f4GwEE0Ut5q-2XCiPxunLDv-J4 Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) 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, 15 Apr 2014 00:51:30 -0000 Martin Thomson wrote: [ Charset UTF-8 unsupported, converting... ] > On 14 April 2014 14:33, Martin Rex wrote: > > There might be (higher layer) protocols that do this all by themselves > > (resend the very same data over and over again) potentially including > > credentials of a disclosing authentication, and there might be > > communication peers that can be enticed to do this (such as web browsers). > > I'm pretty sure that both instances of "might be" can be replaced by > "are". Web browsers use HTTP in this way. Hence the desire to end > RC4 use, at least in that context. I don't think so. A TLS protected communication involves two communication peers, and web browsers are only a fraction of the communication peers in existence (less than half). Web Browsers, in particular those that aggressively execute everything that is sent to them in one way or another, may want to deprecate RC4-based cipher suites fairly quickly. They're free to do so. But the story is different for TLS peers which are less aggressive about executing attacker-supplied active content, and it is different for servers, which do not have the option of a reconnect fallback. What should be done, similar to previous documents of that kind, is provide a useful rationale to the readers of the document, so that they can make a conscious decision and security trade-off between interoperability with an installed base and a potential risk of plaintext recovery under specific, and not necessarily regular conditions. Other examples for rationales: MD2: https://tools.ietf.org/html/rfc6149#section-2 MD4: https://tools.ietf.org/html/rfc6150#section-2 MD5: https://tools.ietf.org/html/rfc6151#section-2 SSLv2: https://tools.ietf.org/html/rfc6176#section-2 DES in TLS: https://tools.ietf.org/html/rfc5469#section-4 DES in Kerberos: https://tools.ietf.org/html/rfc6649#section-4 Personally, I would consider it irresponsible to publish an RFC for deprecation of RC4-based TLS cipher suites *WITHOUT* an adequate rationale / security considerations. -Martin From nobody Mon Apr 14 18:02: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 AA3A81A024C for ; Mon, 14 Apr 2014 18:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frToVtJsSlgU for ; Mon, 14 Apr 2014 18:02:11 -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 A6ABA1A06AA for ; Mon, 14 Apr 2014 18:02:09 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id ABB5711D79; Mon, 14 Apr 2014 21:02:06 -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=x0TAa4idele9 uRjdthjWTC8ikmw=; b=Hx3bXbdRTOKvGmA0rHh9hmau6gfmkKSdHDjZFtOirf8X pxkBbl7GQNAqOJT6N/WiLiyNN+j2n1GplehuTblOwIF3YFFaoOY14nZApG7huEQw 5G4roSdSqRjb1Bvzd1h7fF8r3akygCLYPq8dvocihUvz09ahU6qVvY4hGKqli4g= 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=FC6PTF 0eCvx2oDDpODGY5GdkL573SKkFCq7sffXyzW4O6CZ72OuJTlggPWS8z4d8ceId0f 4mGKqRcRNaT6Nmd/mYRMx4dgZhMAuFRBZOGC4voa7eTRBNBd2ATINniJ5spLFDKq qgrsS7Sl4oz+YPbrN8aml07qRgglnZJ4JbnIE= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A460811D78; Mon, 14 Apr 2014 21:02:06 -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 0BB6E11D76; Mon, 14 Apr 2014 21:02:04 -0400 (EDT) Message-ID: <534C850B.1030505@pobox.com> Date: Mon, 14 Apr 2014 18:02:03 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Mark Nottingham References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <6c33eca449c34ca29f205e3c60856e 7b@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> In-Reply-To: <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 8F929C4A-C439-11E3-BA8F-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wfE1vcIGIaEq_8lwiLLG2F0dru4 Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 01:02:16 -0000 Mark Nottingham wrote: > On 15 Apr 2014, at 9:57 am, Michael D'Errico wrote: > >> Additionally, adding a new low-level transport would break things: >> As an example, suppose you already have defined "http/2 over TCP" and >> "http/2 over TLS (over TCP)" and all servers recognize these code >> points. Now whoever wants to create "http/2 over HNTP" (hypothetical >> new transport protocol) will need to have all http server software >> everywhere learn the new code point whether it is aware of HNTP or not, >> before http/2 could be used reliably over HNTP. > > Why? Suppose that "http/2 over TCP" and "http/2 over TLS" are assigned the code points 23 and 38 respectively (I'm just making up numbers). A TLS stack can be programmed to recognize both of these numbers in ALPN as "http/2" for its purposes. But then some time later, someone registers "http/2 over HNTP" at code point 139. The same TLS stack can not possibly know that protocol 139 in ALPN means http/2 without an upgrade, leading to a failure. Also you'd then have to define "smtp over HNTP", "ftp over HNTP", etc. for all applications that could be delivered over HNTP. Much better to just register one new transport code point for HNTP and you're done. >> So instead of making this mistake, I'd like to see a single code point >> for application protocol (e.g. http/2) which would be used by TLS in >> ALPN and then you can combine that with another code point representing >> the transport if you need this level of distinction ("TCP", "SCTP", >> "UDP", "TLS over TCP", "DTLS over UDP", etc.). > > That would lead people to believe that they can use HTTP over DTLS (for > example), which isn't defined and isn't interoperable. Someone would have > to go and write the document "how to use HTTP/2 over DTLS", and then we'd > need a way to indicate to the peer that this is supported. I'm not saying that every combination needs to make sense. Keeping the code point spaces for transport and application separate will require many fewer registrations and allow for more robust software. Mike From nobody Mon Apr 14 19:12: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 1CF011A02E5 for ; Mon, 14 Apr 2014 19:12:05 -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 gnzFCooQ8mhg for ; Mon, 14 Apr 2014 19:12:00 -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 A0A2B1A0259 for ; Mon, 14 Apr 2014 19:12:00 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so8759079yho.4 for ; Mon, 14 Apr 2014 19:11:57 -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=k8DCkZYdIWwCVxMZ40TEdEB6ax+iNPs+Wi0ctkW+uUE=; b=c9+pJwC60Yv6DGQR2MXlHZmt/QVLc1hBp8IDylHAPooIpL9Hdhg4eSJHyCtHh8QsXc sY1JlieXqkJ+6nFkaT+PvAKAVUdKWf1HxWTi7RNm9COHzkr8zsx6ugUHQNT52L6tWiMF OLeHySu0A4BDzP9/4DjIP5qGwQqJ6VrG5+pob9x/K3iFb4lrQoUZejqJpbeAcn911azd DX0sUjhN0bXa/HOc8Q0gHy9ffCuY4CGoUcTg38h//FeQ9LpW/GvrxD99MgYC6u30eh4B opTKNHNJiM+z9j1Q43MtE90jl71d11TtjHxo27snNvA+o3T33XeXrGSDnq8+PTZD16gx fTmw== MIME-Version: 1.0 X-Received: by 10.236.162.65 with SMTP id x41mr61688358yhk.25.1397527917797; Mon, 14 Apr 2014 19:11:57 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 19:11:57 -0700 (PDT) In-Reply-To: <20140415005124.1D8D01ACBF@ld9781.wdf.sap.corp> References: <20140415005124.1D8D01ACBF@ld9781.wdf.sap.corp> Date: Mon, 14 Apr 2014 19:11:57 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3iMP1EAfeldXNbue-wILQIsQthw Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 02:12:05 -0000 On Mon, Apr 14, 2014 at 5:51 PM, Martin Rex wrote: > Martin Thomson wrote: > [ Charset UTF-8 unsupported, converting... ] >> On 14 April 2014 14:33, Martin Rex wrote: >> > There might be (higher layer) protocols that do this all by themselves >> > (resend the very same data over and over again) potentially including >> > credentials of a disclosing authentication, and there might be >> > communication peers that can be enticed to do this (such as web browsers). >> >> I'm pretty sure that both instances of "might be" can be replaced by >> "are". Web browsers use HTTP in this way. Hence the desire to end >> RC4 use, at least in that context. > > I don't think so. A TLS protected communication involves two communication > peers, and web browsers are only a fraction of the communication peers > in existence (less than half). > > Web Browsers, in particular those that aggressively execute everything > that is sent to them in one way or another, may want to deprecate RC4-based > cipher suites fairly quickly. They're free to do so. > > But the story is different for TLS peers which are less aggressive about > executing attacker-supplied active content, and it is different for > servers, which do not have the option of a reconnect fallback. It really isn't. If you look at the graphs presented in the 2013 RC4 paper (and you did look at this paper, right?), you will see they ignore two things: the fact that plaintext usually has structure, and the cross-byte correlations which are known to exist. That's why RC4 is dead: the initial bytes are just icing on the cake for a serious attacker. Furthermore, the reason browsers have been unable to drop RC4 entirely is misconfigured servers that offer only RC4. Moving away from RC4 needs to begin now. Lastly, at what point do you want us to call RC4 broken? Academic cryptographers had a spate of results against it 2001-2002, culminating in wepcracker. When WEP was replaced by WPA, this stopped being so interesting, and I think 90% of them would have recommend against continuing to use it at that point. However, I'm sure Fort Meade has keep looking. (By the way, TLS was supposed to make everything web browsers do to it now perfectly safe. That's where it was designed) > > > What should be done, similar to previous documents of that kind, > is provide a useful rationale to the readers of the document, so that > they can make a conscious decision and security trade-off between > interoperability with an installed base and a potential risk of > plaintext recovery under specific, and not necessarily regular conditions. We don't know what those conditions are. The cryptanalysis of RC4 is by no means over. By no means should TLS 1.3 continue to allow its use. > > > Other examples for rationales: > > MD2: https://tools.ietf.org/html/rfc6149#section-2 > MD4: https://tools.ietf.org/html/rfc6150#section-2 > MD5: https://tools.ietf.org/html/rfc6151#section-2 > SSLv2: https://tools.ietf.org/html/rfc6176#section-2 > > DES in TLS: https://tools.ietf.org/html/rfc5469#section-4 > DES in Kerberos: https://tools.ietf.org/html/rfc6649#section-4 All of which came years or in some cases a decade late. DES cracker systems existed in 1998. MD5 was broken in 2004, as was MD4. The IETF has a crypto problem: we are terrible at getting rid of broken systems, or at responding appropriately. SHA-1 belongs on that list: collisions in 2^63 time. > > > > Personally, I would consider it irresponsible to publish an > RFC for deprecation of RC4-based TLS cipher suites *WITHOUT* > an adequate rationale / security considerations. Irresponsible why? Perhaps because it isn't convincing. But to me the existence of 2001's Flueher-McGrew biases makes RC4 unfit for purpose. 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 Mon Apr 14 20:09: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 74A701A02FF for ; Mon, 14 Apr 2014 20:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5an5vMNqMGX for ; Mon, 14 Apr 2014 20:09:04 -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 51A581A02EC for ; Mon, 14 Apr 2014 20:09:04 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 62DCC28625; Tue, 15 Apr 2014 03:09:01 +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 5078E28605; Tue, 15 Apr 2014 03:09:01 +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 45BA1FE066; Tue, 15 Apr 2014 03:09:01 +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; Mon, 14 Apr 2014 23:09:01 -0400 From: "Salz, Rich" To: Seth David Schoen , "tls@ietf.org" Date: Mon, 14 Apr 2014 23:08:59 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9YOmo5KKs75q0aQq+/dwewyuIqoAAHR+dQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <20140414233614.GI2891@sescenties.(null)> In-Reply-To: <20140414233614.GI2891@sescenties.(null)> 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/eg6aEfyr1bDpxUY6d3Tg4vi3Qro Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 03:09:06 -0000 PiBJIHRoaW5rIEFseXNzYSBSb3dhbidzIGNvbmNlcm4gZWxzZXdoZXJlIGluIHRoaXMgdGhyZWFk IGFib3V0IHRoZSAiY2lyY3VsYXIgYXJndW1lbnQgb2YgZG9vbSBhbmQgZGVmZWF0IiBhcHBsaWVz IGhlcmUgdG9vLg0KDQpJIHRoaW5rIGl0J3MgYSBsaXR0bGUgdG9vIHNpbXBsZSBhIHdheSB0byB2 aWV3IHRoaW5ncy4gT3VyIGdvYWwgaXNuJ3QgdG8gbWFrZSBFdmUncyBqb2IgYXMgaGFyZCBhcyBw b3NzaWJsZSwgaXQncyB0byBtYWtlIHRoZSBiZXN0IHNldCBvZiB0cmFkZS1vZmZzIHdlIGNhbiwg Zm9yIHRoZSBvdmV3cmFsbCBJbnRlcm5ldC4gIEFzIG15c2VsZiBhbmQgb3RoZXJzIGhhdmUgcG9p bnRlZCBvdXQsIGVuY3J5cHRpbmcgdGhlIFNOSSBoYXMgc29tZSByZWFsIGRyYXdiYWNrcyBhbmQg bWlnaHQgbm90IGFjY29tcGxpc2ggd2hhdCBpcyBkZXNpcmVkLiBJZiB3ZSBkZWNpZGUgdG8gbm90 IHN1cHBvcnQgaXQsIGl0IGNhbiBwdXJlbHkgYmUgYW4gZXZhbHVhdGlvbiBvZiB0aGUgdHJhZGUt b2Zmcy4NCg0KCS9yJCANCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2Ft YWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0K From nobody Mon Apr 14 20:26: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 D1BE31A031A for ; Mon, 14 Apr 2014 20:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.4 X-Spam-Level: *** X-Spam-Status: No, score=3.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, 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 RZbOiEQnGKWq for ; Mon, 14 Apr 2014 20:26:44 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 237881A02F6 for ; Mon, 14 Apr 2014 20:26:44 -0700 (PDT) Received: from [173.75.83.234] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WZu1A-0005fU-Kj; Mon, 14 Apr 2014 23:26:40 -0400 Date: Mon, 14 Apr 2014 20:26:34 -0700 From: Bill Frantz To: Hanno =?UTF-8?B?QsO2Y2s=?= X-Priority: 3 In-Reply-To: <20140411164746.5503c4f8@hboeck.de> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791242ce0609294bf0d396a8c89c97f4f7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.234 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GMBGsjZWL28WHe4TW4maQoQ7TeQ Cc: tls@ietf.org Subject: Re: [TLS] Heartbleed / protocol 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: Tue, 15 Apr 2014 03:26:48 -0000 On 4/11/14 at 7:47 AM, hanno@hboeck.de (Hanno B=C3=B6ck) wrote: >Can anyone name me what real-world applications use TLS Heartbeat with >TCP? Or any use at all? When I designed the E language line protocol=20 back in=20 the late 1990s, I implemented a heart beat function. At the=20 time, we rejected TLS because its security model didn't support=20 our "no central authority" needs. A few years later, some people=20 figured out how to use TLS, but that has never been coded. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345=20 Englewood Ave www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Mon Apr 14 21:27: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 43B9E1A02F0 for ; Mon, 14 Apr 2014 21:27:19 -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 0-lkAjyuktbs for ; Mon, 14 Apr 2014 21:27:15 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 68A901A024D for ; Mon, 14 Apr 2014 21:27:15 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id D1C9827BC064 for ; Mon, 14 Apr 2014 21:27:12 -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=CHFNcCU7BYAlT66k1a94 GlLrATc=; b=b1ug4sp3BkN/rhmzCwY92mcFsc7zUWWdsEmVvWvIfX5tpdYupG7o D/e4U7KpgaiUHvgPqfSbkRVgpYJONQ/76bAmivIZyLr/BxvnOc6phn/tRqHdfl9C v1I2m9ZU+bD4vblOOPVt5wZb4jIu0C5hRSB1AtAH0bhgkQrIO0WlW5A= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 85A8D27BC069 for ; Mon, 14 Apr 2014 21:27:12 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so8897143wgh.31 for ; Mon, 14 Apr 2014 21:27:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr569258wib.42.1397536031210; Mon, 14 Apr 2014 21:27:11 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 21:27:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 23:27:11 -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/u9NewpxI2u3mKrn9e8M-KM27aHI Cc: "tls@ietf.org" Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 04:27:19 -0000 FWIW, I believe the matter is very clear now: Weierstrass curves out, Edwards curves in. For all the reasons Watson gave, and, really, for all the reasons that DJB has given. DJB is so convincing on this subject that the burden of proof is on anyone opposing the switch to Edwards curves. That we have NIST curves code lying around is not a sufficient argument: it will either not be constant time or its performance will not be anywhere near as good as implementations of comparable Edwards curves. The first consideration (no side channels) is unarguably a hard requirement; the second (good performance) is close enough to a hard requirement that it might as well be. Nico -- From nobody Mon Apr 14 21:37: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 E43D91A031F for ; Mon, 14 Apr 2014 21:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ILTJvvdidNW5 for ; Mon, 14 Apr 2014 21:37:00 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 29AF61A024D for ; Mon, 14 Apr 2014 21:37:00 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id ACC732007873F for ; Mon, 14 Apr 2014 21:36: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=aX9ugbgBHCE09qlqLILG MQFrB9o=; b=ou1Qa8FyXMMvdPD8sfGg9qJaCwLmfHFQBRAjbSkc1obOwnsMu8fN MjR8LcBk+3/KhH1WbXYuCS84UFa884frWMvKyyQpCqxo9lJviGKrpKJOfhx3sWUc H5JO/mTE4vvucYXChJt3F33fqXNox6oMWVrTxfjjjQCLYBSDWrWLlSU= 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-a110.g.dreamhost.com (Postfix) with ESMTPSA id 61CEB2007873E for ; Mon, 14 Apr 2014 21:36:57 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so6287021wib.2 for ; Mon, 14 Apr 2014 21:36:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr523315wid.39.1397536616178; Mon, 14 Apr 2014 21:36:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 21:36:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 23:36: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/oGKdrl33VnbPzf9XBHjSRUiPJ6g Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 04:37:01 -0000 On Mon, Apr 14, 2014 at 9:48 AM, Watson Ladd wrote: > Are there any users of renegotiation beyond authentication with client > side certificates? In particular has anyone come up with a use for > changing the claimed identity of the server? Yes, it's been discussed in the context of protecting the server's identity: start with anon ECDHE ciphersuites then renegotiate to [use SNI and] authenticate the server. This is important in general given that privacy protection is desirable. > I think we can do client authentication upgrades via a channel > extraction+signing solution while preserving the privacy currently We call that channel binding. I agree as to that. > given by renegotiation. I haven't yet run Proverif on this solution, > so it might not work, but my intuition is that this will work better > than trying to expose the semantics of renegotiation correctly. > > Renegotation has been responsible for two major security issues, and > significantly complicates the TLS handshake state machine and > semantics. First off, renego was responsible for one bug -- the other is a resumption bug, and BOTH were the result of insufficient or non-existent channel binding between the one connection and the other. Second, we do have uses for renego (see above). Third, I'm skeptical of proposals to throw the baby out with the bathwater. Fourth, renego need not complicate the TLS handshake state machine if we see the two (or three, or...) handshakes as distinct connections with channel binding of inner to outer. I'll admit that the fact that we did not discover the lack of sufficient channel binding in resumption after the renego bug does give me pause. We should audit the protocol and implementations on this point, but we have to anyways. Also, note that your proposal regarding client certs is to push the problem to the app layer and hope that they get channel binding right, which given our collective failure to do the same in TLS should give us pause. I.e., TANSTAAFL, which makes me think even more that yours is a throw-the-baby-out-with-the-bathwater proposal. Nico -- From nobody Mon Apr 14 21:56: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 B2CFA1A06A3 for ; Mon, 14 Apr 2014 21:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 XRZUr2jZjI_r for ; Mon, 14 Apr 2014 21:56:41 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3F1A033C for ; Mon, 14 Apr 2014 21:56:41 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 78F652F4065 for ; Mon, 14 Apr 2014 21:56:38 -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=t0+njLnRPjm+dSOVprx8 G3fhknM=; b=KKmVNxrUtGv+NfOf+kCADm08z9uLVwDgXfrQ/7t/tYjbZVq9ZVFP SFduX3ZKKRnU3r3iBBQ+gQq0jHMs4EtSx+AzzI1TyHO3AjyVeYyeclh5Lrvi+5O5 T3HTWzO/RcRoUn4TydY343vcYQln88H8Y5qH0uVuvqD0IX4a5+MiUmA= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 2A65F2F4060 for ; Mon, 14 Apr 2014 21:56:38 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so9110337wes.10 for ; Mon, 14 Apr 2014 21:56:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr656926wib.42.1397537797158; Mon, 14 Apr 2014 21:56:37 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 21:56:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 23:56:37 -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/3-8jD5g-gcd9yohUAjlUCPKUICM Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 04:56:42 -0000 On Mon, Apr 14, 2014 at 11:36 PM, Nico Williams wrote: >>[...] >> Renegotation has been responsible for two major security issues, and >> significantly complicates the TLS handshake state machine and >> semantics. > > [...] > Fourth, renego need not complicate the TLS handshake state machine if > we see the two (or three, or...) handshakes as distinct connections > with channel binding of inner to outer. To be fair I should add that such a model of renegotiation is actually barely different from yours anyways. That is: a) remove renegotiation b) require a channel binding output (RFC5929 will do, provided resumption is fixed) c) require a channel binding _input_ and check it when provided. You propose (a) and (b). I propose (b) and (c) and an API that looks like (a). This way it is possible to model TLS handshakes as an SChannel-like (or GSS-API-like) initSecContext/acceptSecContext token exchange but with renegotiation being a brand new SecContext with channel binding from the inner to the outer. This way there's no complication of the TLS state machine at all. The application becomes responsible for doing the renego _if_ it wants to. I think you and I are closer to agreement on this than I thought ten minutes ago. Now, if some implementations want to keep renego the old way, as long as it does the necessary channel binding and on the wire it interops with new-style implementations, I won't mind! Nico -- From nobody Mon Apr 14 22:01: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 4375D1A074D for ; Mon, 14 Apr 2014 22:01:01 -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 7M9euTyZ4Zlf for ; Mon, 14 Apr 2014 22:00:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4191A0750 for ; Mon, 14 Apr 2014 22:00:57 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id CBE581006D for ; Mon, 14 Apr 2014 22:00:54 -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=+MFLaZzFIA6CvfGkvY4I 1u5CVnA=; b=Advl7CJuITB/Zn+21Xe66D2Hz1fo38iD2ZFCybNriRXttp/EVvVl CJLM5/rfzg53QsWNRUcVMbtbtvrfuEi9pFbjH+59zwKsPzf28YC39phu5sx2Qj6u HU/1NXN12pENL1g7qI/OLJSvcwuRlXj4FHd808VjsKthL+z8mvSLhlo= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (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 7F01D10062 for ; Mon, 14 Apr 2014 22:00:54 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so9072291wgh.10 for ; Mon, 14 Apr 2014 22:00:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.204.199 with SMTP id la7mr36164769wjc.4.1397538053372; Mon, 14 Apr 2014 22:00:53 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 14 Apr 2014 22:00:53 -0700 (PDT) In-Reply-To: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> Date: Tue, 15 Apr 2014 00:00:53 -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/nxUW3NtuFuaod5gMGoSvpTuJTyU Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:01:02 -0000 On Mon, Apr 14, 2014 at 9:51 AM, Russ Housley wrote: >> I think Rich Salz has outlined very compelling reasons not to support SNI. > > While I might quibble with a detail here or there, I do agree with the conclusion. If you need to protect SNI, then TOR or to a lesser extent TLS-in-TLS can be used. That's... renego, in so many words. I know, if the composition (with channel binding!) is left to the application then it's not renego in the sense that most people think of it. I'm OK with that. Nico -- From nobody Mon Apr 14 22:22: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 863541A0714 for ; Mon, 14 Apr 2014 22:21:57 -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_50=0.8, 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 oA3zvG0Rh-Bj for ; Mon, 14 Apr 2014 22:21:50 -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 9EBCF1A0338 for ; Mon, 14 Apr 2014 22:21:50 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so8470532ykq.0 for ; Mon, 14 Apr 2014 22: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:content-transfer-encoding; bh=mboPcz7xdWVNsf02VUYMSZAig/7tJJe3PnM78DIaBrQ=; b=i+IumJTVMZfj93DvBaPdVWJkzMgiI/nEcp+iG7iUcn6mkSNsalWy5TOgTZI4BlBvp2 Op2CiaOJpWKhVQkHGVcUuPruj9Odkno9hAlPEwUF/+3VKZVHLcErV2vHy3WjAFu/qLac 2iWZ6cVAWTddL4VR3R1A5RRqpXtO9OfrCjtT6Rf6Migbcf6fM39ng4OC9KKXTU4AKUx2 1dyiwDFusVwCvL+d4voVirhrPsv+zfAsJ04di641ZXm1yfKOABdI4F49/rwfFm8sZ8Hr egiPBl3BoHkO7CbeRi4Wh+ndI2U+70ihdLlQUtpRw8GCK74CBOl+MveKq6u/BM9XHTN7 pznA== MIME-Version: 1.0 X-Received: by 10.236.135.104 with SMTP id t68mr63850543yhi.35.1397539307787; Mon, 14 Apr 2014 22:21:47 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 22:21:47 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> Date: Mon, 14 Apr 2014 22:21:47 -0700 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/J06e91BdZ4kDdMAeAwhWTt5tdMU Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:21:59 -0000 On Mon, Apr 14, 2014 at 8:08 PM, Salz, Rich wrote: >> I think Alyssa Rowan's concern elsewhere in this thread about the "circu= lar argument of doom and defeat" applies here too. > > I think it's a little too simple a way to view things. Our goal isn't to = make Eve's job as hard as possible, it's to make the best set of trade-offs= we can, for the ovewrall Internet. As myself and others have pointed out,= encrypting the SNI has some real drawbacks and might not accomplish what i= s desired. If we decide to not support it, it can purely be an evaluation o= f the trade-offs. It all depends on the mechanism that is proposed, and how that works. The mechanism in the current TLS 1.3 doesn't actually work: a censor can break a few connections to see what you are looking at, then take a look himself to see if they want to censor it. Even if we did have a magic mechanism that encrypted the handshake without knowing to whom it was to be encrypted (I'm sure someone will dig up an IACR paper that presents a wildly impractical solution using fully homeomorphic encryption) a censor could probably take a good guess as to what everyone was looking at, especially from interaction patterns. Censors are generally insensitive to collateral damage. Turkey denied access to all of Twitter, and Pakistan all of Youtube (for everyone worldwide once) over a small amount of subversive content on each. Not to put anyone on the spot, but if you think a major hosting provider is going to bat for you while getting bomb threats and periodically sitewide blocks, you're nuts. They aren't. It isn't their business, and the ones who make it their business are usually collateral damage for a censor as people who don't want to take the cost of getting blocked. Frequently changing IP address and using DNS to send people there doesn't work: the censor knows how to find DNS entries also. I'm not sure what the threat that encrypted SNI is supposed to protect against is: a passive observer looking for connections to a website on shared hosting, insensitive to collateral damage? A merely curious teenager armed only with wireshark, and no idea of what the websites look like? The Great Firewall of China? Finally, a sufficiently motivated censor could cut off all TLS 1.3 entirely if they couldn't break it. Browsers would fallback to TLS 1.2. Some censors are that motivated: they threaten publishers with death and dismemberment Now, the best mechanism I can think off would be to use DNS to preload a per-IP SNI encryption key, or have the handshake optionally involve getting one. But I still can't figure out how to authenticate the gotten key without a lot of complexity. The best solution is for the client and server to do a DH, then pass the desired website (which might get you investigated when the initial handshake is intercepted), and have that cert sign the handled DH, then go back and do a TLS connection. Ugh. Make a clean, per-IP solution, and you solve the big problem. However, I think censors are going to not care about collateral damage, and may very well send a clear message by blocking TLS 1.3. I would love to have a nice, simple, censorship resistance improvement. Maybe there is low-hanging fruit we missed. It's worth still thinking about. But at this moment I don't see a useful way to achieve the goal. 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 Mon Apr 14 22:50: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 2521B1A0348 for ; Mon, 14 Apr 2014 22:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-KaiBNgdgQP for ; Mon, 14 Apr 2014 22:50:52 -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 3D4F41A033B for ; Mon, 14 Apr 2014 22:50:52 -0700 (PDT) Received: from [173.75.83.234] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WZwGe-0002iq-OB for tls@ietf.org; Tue, 15 Apr 2014 01:50:49 -0400 Date: Mon, 14 Apr 2014 22:50:43 -0700 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <6A868689-C1A5-4E62-BBBB-96A8E8374DB3@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79afd443398d72b43e04be2601ecb16e91350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.234 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w7cbLKR9Tg2fVXo6m8fufObkKQI Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 05:50:55 -0000 +1 Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 From nobody Mon Apr 14 23:14:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369D91A033C for ; Mon, 14 Apr 2014 23:14:23 -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_50=0.8, 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 KNju51V6jzuK for ; Mon, 14 Apr 2014 23:14:18 -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 6F99E1A008B for ; Mon, 14 Apr 2014 23:14:18 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so8537172ykp.29 for ; Mon, 14 Apr 2014 23:14: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=RY7PGWMLb7zHz7c+tWt0G5AmXBFoEsRYSYbwMEh83tw=; b=aCZgER2+31uSzEaammso1srWdrg258MFZq0MnALRD869QryzWFLP0NKQk2gzjVBCBz KG5WVzKTY5EYf3hy7lDNxp/OiLRjvUnxMoIkot/zMAKRXEUHvepJY8KPggmZfdnNoJdq y8zr3g1YbeaIDxCLu+b50BZZJbxAPTxSB3ePQdes+TWiMvEkZ5Lz257isYGRuEc13ym9 tsW/vYFTNTMGAW6u8saCYoGuhc0Bt4i16/1lx3NSh9N9TKjO4dX14BCrlrbe4tmUzelZ muYV4vy790TD3zjpEz8LdLZPuxGL3lOkUQGUcrFdWNqseI2PZn0s2Qpv+N76vjaB6TAa NzYw== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr20698yhi.4.1397542455568; Mon, 14 Apr 2014 23:14:15 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 14 Apr 2014 23:14:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Apr 2014 23:14:15 -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/bYEzyvqQAjYWy5uf88NLT9mJO8E Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 06:14:23 -0000 On Mon, Apr 14, 2014 at 9:36 PM, Nico Williams wrote: > On Mon, Apr 14, 2014 at 9:48 AM, Watson Ladd wrote: >> Are there any users of renegotiation beyond authentication with client >> side certificates? In particular has anyone come up with a use for >> changing the claimed identity of the server? > > Yes, it's been discussed in the context of protecting the server's > identity: start with anon ECDHE ciphersuites then renegotiate to [use > SNI and] authenticate the server. That won't work if you do it like that. Hint: how does the server know who to reveal their identity to? > > This is important in general given that privacy protection is desirable. > >> I think we can do client authentication upgrades via a channel >> extraction+signing solution while preserving the privacy currently > > We call that channel binding. I agree as to that. > >> given by renegotiation. I haven't yet run Proverif on this solution, >> so it might not work, but my intuition is that this will work better >> than trying to expose the semantics of renegotiation correctly. >> >> Renegotation has been responsible for two major security issues, and >> significantly complicates the TLS handshake state machine and >> semantics. > > First off, renego was responsible for one bug -- the other is a > resumption bug, and BOTH were the result of insufficient or > non-existent channel binding between the one connection and the other. It's not "a lack of channel binding". It's a failure to hash transcripts in a key exchange. That's why you can have the same pre-master secret on two different connections, and thus break resumption. If the two connections were completely independent these problems wouldn't have happened as you wouldn't trust the earlier data as coming from the person you now authenticated. (My understanding of insecure resumption is that a renegotiation was necessary to seal the deal: i'll double check the paper to see if that's correct). > > Second, we do have uses for renego (see above). > > Third, I'm skeptical of proposals to throw the baby out with the bathwater. > > Fourth, renego need not complicate the TLS handshake state machine if > we see the two (or three, or...) handshakes as distinct connections > with channel binding of inner to outer.\ And that's not complicated? I don't see how channel binding fixes the confusion that is changing claimed identities across connections, or reduces the impact of renegotiation on implementation complexity. The problem Nick had was the following: you want a software component that sits between a bidirectional stream of bytes and a socket, and applies TLS after the handshake has completed. Because this is C, and not Go (or CML, or etc...), you cannot write an independent event loop without an OS level thread. (Completing the handshake involves a bit more work) The usual solution would be as follows: when the host application writes to the stream, it signals there is new data to send, which the component dutifully encrypts, and sends (since the host application has checked that sending is possible on the fd via poll(3) or equivalent). On read the same thing happens in reverse. However, with renegotiation the component suddenly goes into a state into which sending data is dependent on receiving some data. How you deal with this cleanly is beyond me. It's not solved by any retooling of the API: it's fundamental to any protocol exchange in which a read can block a write. > > I'll admit that the fact that we did not discover the lack of > sufficient channel binding in resumption after the renego bug does > give me pause. We should audit the protocol and implementations on > this point, but we have to anyways. Also, note that your proposal > regarding client certs is to push the problem to the app layer and > hope that they get channel binding right, which given our collective > failure to do the same in TLS should give us pause. I.e., TANSTAAFL, > which makes me think even more that yours is a > throw-the-baby-out-with-the-bathwater proposal. I'm not pushing it to the app layer any more than now, nor am I suggesting that the average application developer be ever trusted with cryptography. The library should say "pass me a cert" (ideally not even that) and handle the rest. In the course of my writing this missive, another email from you arrived. You suggested that we hand this over to the application layer in part, by exposing channel binding inputs and outputs. This is a terrible idea. The application developer is not supposed to know or understand cryptography. They are supposed to write dial("443", "secure.example.com") and have the OS take care of determining which certs are trusted, opening a secure connection, and the fiddly details of managing that connection, and authenticating the user over that connection (if needed). They get it wrong too often to be trusted with it, and shouldn't even be trusted with cert selection (as that means they can read certs). (TCP is spelled dial_insecure, just be sure everyone gets the message). (and by application developer I mean me when I don't want to think about this). What does the application do with the return value of dial? write(2), read(2), poll(3), close(2), just like anything else. 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 Tue Apr 15 00:55: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 2BA181A0222 for ; Tue, 15 Apr 2014 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYesQJhSdskx for ; Tue, 15 Apr 2014 00:55:27 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 71ECA1A0389 for ; Tue, 15 Apr 2014 00:55:27 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so9202188wgh.35 for ; Tue, 15 Apr 2014 00: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hyWFAZ9/pp/KMyphWrBP49WO25416QZEF29ousesd3Y=; b=QphRUhNszIo+EmmgNMqw32Fvuqhn9arMadxHpolOQ5Vp4+DeqjWP/uz2QYNwty2s2E IJMOjiz2YAbmtfz4MNpzxl1sspUmSQ3gI4bk+/Wpk6oReQYG1OTKdJs/4lGpXk8o6GkN xG1O5J1KNsyl9nx6pusx2w7pj8AWyK9hnd4ZKPg7CzCZeMAjfW0anIJ92+CrpShnc/+L MCWtRQaUL37MReNi2WFeyMfpG8blQzBtJL6NQLpWvDLWSUpPhoWAjqRciMZWyi6H83Br SoHg8d+DiTk39X4fX3svf1oSpD7AUXUzZ62z7jrvHwnQDDKZNrTl4VeOjSMbPku0Aurw 9zlQ== X-Gm-Message-State: ALoCoQlS1uzs3hCmQ6CkUtePx9+ee3gBWNxjXXEV2cknGEdqXbfIQQsA55jAVKywxIgRfXyaTogk MIME-Version: 1.0 X-Received: by 10.195.12.14 with SMTP id em14mr273003wjd.15.1397548524224; Tue, 15 Apr 2014 00:55:24 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Tue, 15 Apr 2014 00:55:24 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: Date: Tue, 15 Apr 2014 00:55:24 -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/MBMfEBPg9G0mM8k4BgTTGtgKgu8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 07:55:31 -0000 On Wed, Apr 9, 2014 at 1:49 PM, Sean Turner wrote: > > While the IETF certainly has used competitions in the past, they are > generally used to select one document from multiple starting points > and then the documents undergo substantial revisions. Even then, there > is a fairly mixed track record as WGs often find it very hard to come > to a final selection and instead get bogged down in the selection > process. Hi Sean, Have there really been enough IETF crypto-protocol competitions to draw this conclusion? Could you give examples? IKEv1 was mentioned by Stephen Farrell [1]. But Dan Harkins and Peter Gutmann argued its problems were less due to the ISAKMP/SKIP competition, and more due to what happened afterwards - "option being piled on top of option" creating a "design-by-committee mess" [2,3]. As for getting "bogged down in the selection process" - having so many strong candidates it's hard to choose sounds like a good problem to have. If the designs are similar, we'll have more confidence in them. If they're different, we'll have context to argue the trade-offs. > In this case, however, our charter provides a clear starting point, > namely RFC 5246, and a mandate to minimize the changes to that > document. This does not mean that ideas for significant changes are > are not welcome, but they should be phrased as revisions to RFC 5246 > rather than as a wholesale replacement. As Nikos and Paul pointed out, the charter doesn't mention 5246. It mentions minimizing changes, but only as one goal among several, and only "gratuitous" changes. I think minimizing changes is one of many goals in tension with others (minimizing diffs vs minimizing complexity / adding features; handshake encryption vs handshake latency; new features vs. ease of analysis; merging layers vs. modularity; etc.) Instead of presuming the answer to any of these, or tackling them in isolation, it makes more sense to explore such a complex design space through different proposals. > The chairs do not believe > there is a convincing reason or support to deviate from the plan > described in our previous message [1]. Reviewing the "TLS 1.3 process" threads [4,5], I see more support for alternatives: * Adam Langley suggested a "TLS 1.3 that is a tidying up of 1.2 [...] The more significant changes could be 1.4" [6]. Peter Gutmann endorsed this, and Watson Ladd and Rich Salz seemed somewhat interested in such an approach [7,8,9], as am I. * Nikos, myself, Peter Gutmann, Watson, and Daniel Kahn Gillmor expressed interest in soliciting multiple proposals [10,11,12,13]. * Bill Frantz suggested having a set of "use cases to test our proposals against" [14]. Support was expressed by Watson, Peter Gutmann, and Andy Lutomirski [15,16,17]. It also seems these discussions were cut short by extended_random and heartbleed revelations. I don't know whether the WG has consensus for any of the above, but it's not clear there's consensus for your process either. Perhaps the chairs could try to clarify the main alternatives and put it to the WG for a decision? Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg11679.html [2] http://www.ietf.org/mail-archive/web/tls/current/msg11701.html [3] http://www.ietf.org/mail-archive/web/tls/current/msg11709.html [4] http://www.ietf.org/mail-archive/web/tls/current/msg11657.html [5] http://www.ietf.org/mail-archive/web/tls/current/msg11655.html [6] http://www.ietf.org/mail-archive/web/tls/current/msg11691.html [7] http://www.ietf.org/mail-archive/web/tls/current/msg11711.html [8] http://www.ietf.org/mail-archive/web/tls/current/msg11694.html [9] http://www.ietf.org/mail-archive/web/tls/current/msg11685.html [10] http://www.ietf.org/mail-archive/web/tls/current/msg11677.html [11] http://www.ietf.org/mail-archive/web/tls/current/msg11670.html [12] http://www.ietf.org/mail-archive/web/tls/current/msg11655.html [13] http://www.ietf.org/mail-archive/web/tls/current/msg11656.html [14] http://www.ietf.org/mail-archive/web/tls/current/msg11717.html [15] http://www.ietf.org/mail-archive/web/tls/current/msg11723.html [16] http://www.ietf.org/mail-archive/web/tls/current/msg11720.html [17] http://www.ietf.org/mail-archive/web/tls/current/msg11792.html From nobody Tue Apr 15 01:06: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 C46331A06A7 for ; Tue, 15 Apr 2014 01:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.231 X-Spam-Level: * X-Spam-Status: No, score=1.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RP_MATCHES_RCVD=-0.272, 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 wQTK2E9yjBbS for ; Tue, 15 Apr 2014 01:06:30 -0700 (PDT) Received: from qutexedge07.qut.edu.au (qutexedge07.qut.edu.au [131.181.191.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5ED1A066A for ; Tue, 15 Apr 2014 01:06:30 -0700 (PDT) Received: from EX10HT05.qut.edu.au (131.181.108.103) by qutexedge07.qut.edu.au (131.181.191.24) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Apr 2014 18:06:26 +1000 Received: from EX10MB4.qut.edu.au ([169.254.6.187]) by EX10HT05.qut.edu.au ([131.181.108.103]) with mapi id 14.03.0158.001; Tue, 15 Apr 2014 18:06:26 +1000 From: Douglas Stebila To: Trevor Perrin Thread-Topic: [TLS] TLS process thread Thread-Index: AQHPVDVK2LH02BLn0UGTyaHyruPvQ5sRsA8AgAADA4A= Date: Tue, 15 Apr 2014 08:06:26 +0000 Message-ID: References: In-Reply-To: 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: <40EA9794E90F5449A761F762FC45D4C6@exchange.qut.edu.au> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9iBI8Z6_JQ8MePXjTDOdh7usdl4 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 08:06:35 -0000 On 2014/04/15, at 17:55, Trevor Perrin wrote: > * Nikos, myself, Peter Gutmann, Watson, and Daniel Kahn Gillmor > expressed interest in soliciting multiple proposals [10,11,12,13]. +1=20 From nobody Tue Apr 15 05:49: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 166DA1A0668 for ; Tue, 15 Apr 2014 05:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.771 X-Spam-Level: * X-Spam-Status: No, score=1.771 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_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 L4h60p9ntyho for ; Tue, 15 Apr 2014 05:49:23 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 525D01A03FC for ; Tue, 15 Apr 2014 05:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s3FCnFWu007937 for ; Tue, 15 Apr 2014 14:49:15 +0200 (CEST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E11741BB8 for ; Tue, 15 Apr 2014 14:49:14 +0200 (CEST) Received: by mail-vc0-f169.google.com with SMTP id ik5so9472011vcb.28 for ; Tue, 15 Apr 2014 05:49:13 -0700 (PDT) X-Received: by 10.52.251.199 with SMTP id zm7mr1026224vdc.21.1397566153586; Tue, 15 Apr 2014 05:49:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.242 with HTTP; Tue, 15 Apr 2014 05:48:33 -0700 (PDT) In-Reply-To: References: From: Klaus Hartke Date: Tue, 15 Apr 2014 14:48:33 +0200 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBP7A9Ufrz3osufrAF0-moVRtsI Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 12:49:25 -0000 Trevor Perrin wrote: > As Nikos and Paul pointed out, the charter doesn't mention 5246. It > mentions minimizing changes, but only as one goal among several, and > only "gratuitous" changes. > > I think minimizing changes is one of many goals in tension with others > (minimizing diffs vs minimizing complexity / adding features; > handshake encryption vs handshake latency; new features vs. ease of > analysis; merging layers vs. modularity; etc.) Instead of presuming > the answer to any of these, or tackling them in isolation, it makes > more sense to explore such a complex design space through different > proposals. To me, it seems a critical question is whether a handshake initiated by a (D)TLS vNext client to an existing (D)TLS 1.x server is expected to succeed (without extra round trips, etc.) or not. If yes, then vNext = 1.3 and there's only so much that can actually be changed without breaking backwards compatibility. For example (if I understand it correctly), removing compression basically means that compression must not be negotiated, not that the ClientHello.compression_methods field can be removed. Any significant changes will need to jump through some hoops to remain backwards compatible, like for example the encapsulation of TLS records in ClientHello extensions (ugh). I wouldn't be surprised if most things that can be done could even be done if vNext = 1.2bis. If no, then vNext = 2.0 really and there's no reason why it shouldn't be a clean reinvention of Internet transport layer security that doesn't have to look like TLS 1.2 but nevertheless stands on the shoulders of the 15+ years of SSL/TLS 1.x experience. Klaus From nobody Tue Apr 15 06: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 14F681A046C for ; Tue, 15 Apr 2014 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 tVLosB1BHXL8 for ; Tue, 15 Apr 2014 06:34:48 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id AF90D1A0430 for ; Tue, 15 Apr 2014 06:34:48 -0700 (PDT) Received: from localhost (91-64-50-86-dynip.superkabel.de [::ffff:91.64.50.86]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 15 Apr 2014 15:34:43 +0200 id 0000000000020007.00000000534D3573.00004F36 Date: Tue, 15 Apr 2014 15:34:35 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140415153435.7f82b3a0@hboeck.de> In-Reply-To: References: X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-20278-1397568883-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-cisCc7VuC3CbjTHfg41PbhXLYg Subject: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:34: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-20278-1397568883-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 11 Apr 2014 11:50:22 -0700 Eric Rescorla wrote: > Andrei Popov has refreshed his draft on deprecating RC4: +1 from me. But: I think we should have this discussion more broadly. What other algorithms exist in the TLS spec that should see deprecation? I think there is a bunch of cruft that really shouldn't be deployed anywhere, because we should have learned from heartbleed that code laying around that nobody uses can be a problem. E.g. what about deprecating DSA? Quick facts that let me believe it is ready: * DSA is only widely supported with 1024 bit and there is wide agreement that this is bad (RSA keys with 1024 bit are almost extinct) * Everyone uses RSA anyway, DSA keys on real world websites are basically nonexistent (someone with fast access to one of the latest internet-wide scan datasets could check that). * DSA is very weak if used with bad random numbers, see e.g. latest dual ec research, where they got the DSA private keys easily (this argument is also true for ecdsa, but I'm aware that deprecating ecdsa is probably much more controversial, so I say lets start with the easy one and deprecate DSA). * Removing DSA suites would reduce size of TLS handshake. I never wrote an RFC before, but if there is reasonable agreement that DSA removal makes sense I could think of going ahead and writing a draft similar to the RC4 one on DSA. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-20278-1397568883-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) iQIcBAEBCgAGBQJTTTVrAAoJEKWIAHK7tR5CtKIP/AjmT2dxQiSS0ih8wKjfs64d 22WA9GQ4X5TzPEkv5fsWfUBDjfuHhAHbmHMdPAJij6embZ2QWSjUJDaV6UCf+0JJ WtKd6rgZn/XUmuTz2xx7QrzwKgoD+8vUacfMtceEOcHd50rMMM9Z/xb+NNpqYltx BvinGWIgedr5+xmRP16YeEUdN0h2VkJ4S8pz9+UF0QM2FXYKo8nEqljmXRJoIbNF ZdvAH4c3wlN0jo3O8I3V3IyaBUjxAPjo6+i4IBaK04uiDohcHgNaHVrQ1sANx9Ut qxFbbpOAgqOV2nJWfioqV18WuxOMue637Z4i43r5uOWpyro6zzb9TRA+cEqpgeSS fdvNizeROKwpNKM7ZPW6VFOhRSywV30Ol/GpcG34kcooatRJok/oCwMjfZHkCMVX VjSELytwsxfgvDq/jbtiZUgEAMOdt/Ixxo164Do/d/PvJaYk6/UiE4QHpBgjx6bi h0dPjED+5mTWeB95VWINvX3uHQPixll1IdmDG1lxFOcfUvvF42duY7Y88vv+0N8k oeWcXPThWOp964vB8gcKroM6zvAxjSHmQlyDnOSW01Wxe9uzw16m9mbhlHlWmVPy 1Ns31pmSbVv3qKoeb1uhC/i+FKzMKc4/h0kU/F6IYAZA4sutMCRsojBwjiyNutLb 35x/4N4c510GSZI9R7wg =2tNt -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-20278-1397568883-0001-2-- From nobody Tue Apr 15 06:43:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB641A0455 for ; Tue, 15 Apr 2014 06:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ddlj5JxTYtv for ; Tue, 15 Apr 2014 06:43:00 -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 6ED641A046F for ; Tue, 15 Apr 2014 06:42:59 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 84FF416567D for ; Tue, 15 Apr 2014 13:42:56 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 79DBF16566D for ; Tue, 15 Apr 2014 13:42:56 +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 625BE1E043 for ; Tue, 15 Apr 2014 13:42:56 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 15 Apr 2014 09:42:55 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Tue, 15 Apr 2014 09:42:55 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9YaptDNZZaGmW5Q9aGJsI28yZOhAARUmnA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> 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/23z0D5he4bta_c2qgCRThuxP7DI Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:43:02 -0000 V2hhdCBpZiB0aGUgY2xpZW50IGRvZXNuJ3Qgc2VuZCBTTkksIGJ1dCBpbnN0ZWFkIHRoZSBob3N0 aW5nIHNlcnZpY2UgaGFzIGEgc2luZ2xlIHdpbGRjYXJkIGNlcnQ/ICBXaGF0IGNoYW5nZXMgaW4g dGhlIHByaXZhY3kgYW5kIHRydXN0IG1vZGVsPyAgV2h5IGlzbid0IHRoYXQgYWNjZXB0YWJsZT8N Cg0KCS9yJA0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNo bm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoNCg== From nobody Tue Apr 15 06:53: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 71C2A1A0213 for ; Tue, 15 Apr 2014 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0XE_rgBxVy0 for ; Tue, 15 Apr 2014 06:52:54 -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 E866B1A039C for ; Tue, 15 Apr 2014 06:52:53 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so7730052eek.6 for ; Tue, 15 Apr 2014 06:52:50 -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=JNdlJT05zW3+tPZ1YWNls3Lb71nfuXpzOr26myOejVM=; b=qBET2YozpB6xhcPvkBqbl5MPb6WRgbo059ttLqE2NrP8QH0AaiVFHAbgARZ5Dx35TR uJIfc/Dcj9KMT5VYR7VWUUztWSLR4dnHjiVuD9WDCMwfm2naN0nIuy8fJvRtQLeun1zr 8S+raG6Vrugvt3wUAwb81rgi7/R+VBpK+sQXT0emUta/ot9ygnr84/CqLOL4FryVBO0l 2PxJXpAYjSMKjcwPe4Px+TVfyaZuZl9Nl/YKs5bBY1hvit6npbAdfyLoSK6aFAhTjwtb 0wcxyNPk4UXVLdXu44TLfoSUldlc0oX6CaRTzSc2RZHGr2bMhSZFUQFu5biZyYBcro7T utdQ== X-Received: by 10.14.100.69 with SMTP id y45mr2733594eef.108.1397569970554; Tue, 15 Apr 2014 06:52:50 -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 m44sm49329294eep.14.2014.04.15.06.52.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 06:52:49 -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: <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> Date: Tue, 15 Apr 2014 16:52:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lUc1u-0WExV4mahljODB3Ksxwwo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:52:59 -0000 Currently HTTPS requires the name in the cert (CN or alt-name) to match = the dns name, and a wildcard can cover only one qualifier. So if you=92re hosting like tumblr, you can do yoavnir.tumblr.com and = richsalz.tumblr.com and have a *.tumblr.com certificate. But you can=92t host www.yoavnir.com (not mine!) and = www.imperialviolet.com like that. There is no valid certificate that = won=92t generate red screens that covers both of those. So we=92d have to change the way certificates are matched to domain = names if we wanted that. Perhaps we could have a certificate with the = name =93www.myhostingsite.com=94, and a new DNS record for = www.yoavnir.com that says that this site is hosted with the name = =93www.myhostingsite.com=94. For a site that published this DNS record, = the browser would not send a (clear) SNI. This is a significant change, though. One that affects previous versions = of TLS as well. Yoav On Apr 15, 2014, at 4:42 PM, Salz, Rich wrote: > What if the client doesn't send SNI, but instead the hosting service = has a single wildcard cert? What changes in the privacy and trust = model? Why isn't that acceptable? >=20 > /r$ >=20 > -- =20 > Principal Security Engineer > Akamai Technology > Cambridge, MA >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 15 06:55: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 CFC771A0318 for ; Tue, 15 Apr 2014 06:55:57 -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 o9FzawjICYla for ; Tue, 15 Apr 2014 06:55:53 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAD81A0312 for ; Tue, 15 Apr 2014 06:55:53 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b57so7703916eek.26 for ; Tue, 15 Apr 2014 06:55:50 -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=0qeYiNGuKKs6m2+SEKWLbKL4uREFRJ45keLggqoxTWk=; b=UGVhUZcXRwrwiSeA3T1sNQflwHPK7oF5GK0RDA9jhxpKlvX/wK9UgBEPt5nRN+V+3R j/i1uYYmy2hEWA9mlnxTocKr1L5e52yT4xiD82ffKDx79oRloGiRLqSHyj+ZUIc85QoC K7yT0nhcPwM9ALud9jtb+XRqqudmX/YAm2Vbwe8P5i24pQYvGeP7lKuEI4xes+VB7FaF vXpDT7Ktu/jUwoFoA3WnC0sYBZAKlo4/4tsMpbVi9U8/8Ag4MHUklrZLqIQPSqfYbBGU ZBtFS0IlZz58s6InaH3z+rzAQsbhpKqlGmP+MGl/XOOx1HEDh3dQb/BY6Y+2U0Nju607 5mvw== X-Received: by 10.15.67.142 with SMTP id u14mr2731530eex.19.1397570150150; Tue, 15 Apr 2014 06:55:50 -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 w12sm49327845eez.36.2014.04.15.06.55.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 06:55:49 -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: <20140415153435.7f82b3a0@hboeck.de> Date: Tue, 15 Apr 2014 16:55:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> References: <20140415153435.7f82b3a0@hboeck.de> To: =?windows-1252?Q?Hanno_B=F6ck?= X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vd2_SOMUd5NNU79cuTZFfNCYyD0 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:55:58 -0000 I=92m not against deprecating DSA, but there is actually nothing wrong = with DSA. Use it with 2048-bit keys and you should be fine modulo = implementation bugs. If you have a bad PRNG, you need to fix the PRNG, because it will bite = you some other way. I can=92t think of a single reason to use DSA as opposed to ECDSA, but = we don=92t generally deprecate things that still work. Yoav On Apr 15, 2014, at 4:34 PM, Hanno B=F6ck wrote: > On Fri, 11 Apr 2014 11:50:22 -0700 > Eric Rescorla wrote: >=20 >> Andrei Popov has refreshed his draft on deprecating RC4: >=20 > +1 from me. >=20 > But: I think we should have this discussion more broadly. What > other algorithms exist in the TLS spec that should see deprecation? I > think there is a bunch of cruft that really shouldn't be deployed > anywhere, because we should have learned from heartbleed that code > laying around that nobody uses can be a problem. >=20 > E.g. what about deprecating DSA? Quick facts that let me believe it is > ready: > * DSA is only widely supported with 1024 bit and there is wide > agreement that this is bad (RSA keys with 1024 bit are almost = extinct) > * Everyone uses RSA anyway, DSA keys on real world websites are > basically nonexistent (someone with fast access to one of the latest > internet-wide scan datasets could check that). > * DSA is very weak if used with bad random numbers, see e.g. latest > dual ec research, where they got the DSA private keys easily (this > argument is also true for ecdsa, but I'm aware that deprecating ecdsa > is probably much more controversial, so I say lets start with the > easy one and deprecate DSA). > * Removing DSA suites would reduce size of TLS handshake. >=20 >=20 > I never wrote an RFC before, but if there is reasonable agreement that > DSA removal makes sense I could think of going ahead and writing a > draft similar to the RC4 one on DSA. >=20 > --=20 > Hanno B=F6ck > http://hboeck.de/ >=20 > mail/jabber: hanno@hboeck.de > GPG: BBB51E42 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 15 06:56: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 3BE751A0312 for ; Tue, 15 Apr 2014 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZBDvOvHmKeq for ; Tue, 15 Apr 2014 06:56:36 -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 457FA1A06F2 for ; Tue, 15 Apr 2014 06:56:36 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 49963474DC; Tue, 15 Apr 2014 13:56:33 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 24A4847502; Tue, 15 Apr 2014 13:56:33 +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 9F4A280044; Tue, 15 Apr 2014 13:56:32 +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; Tue, 15 Apr 2014 09:56:32 -0400 From: "Salz, Rich" To: Yoav Nir Date: Tue, 15 Apr 2014 09:56:31 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9YsgAQT7fn9GpuTi2NqVwTVEO9iQAAC/ow Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dWUAMt_lMzaZfCKhan7EZ6Yh_ZM Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:56:41 -0000 > So if you're hosting like tumblr, you can do yoavnir.tumblr.com and richs= alz.tumblr.com and have a *.tumblr.com certificate. Yes, I know. It would mean that aaa.privacy.org and kkk.privacy.org would = be under the same DNS name. You could mitigate that by having a CNAME entr= y. My question is about the security, not the discoverability (or vanity, if y= ou will). /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Tue Apr 15 07:03: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 E47601A0701 for ; Tue, 15 Apr 2014 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 c5Y7MMRsVsGk for ; Tue, 15 Apr 2014 07:03:39 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id D41D21A069F for ; Tue, 15 Apr 2014 07:03:38 -0700 (PDT) Received: from localhost (91-66-81-2-dynip.superkabel.de [::ffff:91.66.81.2]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 15 Apr 2014 16:03:35 +0200 id 0000000000020007.00000000534D3C37.00007681 Date: Tue, 15 Apr 2014 16:03:27 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Yoav Nir Message-ID: <20140415160327.7dd88945@hboeck.de> In-Reply-To: <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> References: <20140415153435.7f82b3a0@hboeck.de> <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-30337-1397570615-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sFO1UCKaFjRkumoVaLBpDnMVYC8 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:03:43 -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-30337-1397570615-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 15 Apr 2014 16:55:51 +0300 Yoav Nir wrote: > I=E2=80=99m not against deprecating DSA, but there is actually nothing wr= ong > with DSA. Use it with 2048-bit keys and you should be fine modulo > implementation bugs. >=20 > If you have a bad PRNG, you need to fix the PRNG, because it will > bite you some other way. My opinion on that is that we should have multiple lines of defense. Sure, if the RNG is bad we should fix it. But we all know good RNGs is a nontrivial problem. So while fixing RNGs is a priority, we also should have algorithms that don't completely break so badly that they spit out the public key if the RNG fails. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-30337-1397570615-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) iQIcBAEBCgAGBQJTTTwvAAoJEKWIAHK7tR5CqBIP/1RMckN2vK9dagGaMxFHVopk jFEL8GM+TQeYLZ+qi7AXarrbqnAvjmxiqjecoj+VIhn6VRka45lQVIa/+97Mwd+6 hsYqCjqaXqJ6dOhsTdlWwrJijsANLqHonclysuIOXgmzZApFvRh1a53SKr2QNYoG ZXlZ/mQhqw/wUz31c3VCxV/Mmp5iOlLcZCC5WL4BlKYkt7I5WO+IwnAHu1rUY8+q EkLzFpfJvjhwdrOw4yQ7IVQm0aWcps6M8dgRkyBQPMAN5cH8fEEItsoDLvY92KnR aQefOgEVKstuchZzbyMAd3oJBGmvXEqnJ3YDlYue15aBW7JRtOs+viWIdr2BW0ve so1m4OAMOe7Lb2NFOhUHZU/BSBwFVULFp9WnwbAQQrduwJHeV1mVUBBrcwtMqHzz O6mp2J5yrqAqYpXoAymxe0WWkRDMB0vFr/w+gBoUT3m0WoV0BdkmkkU8z7ExiuIE qeYxXKjIVMKIB3YRmTWVgxHS4lcPBT+MWBYqhvN+vCsZYOiiaVrgHYddy+rLhZ+1 fzEFmVUt/9UFqjkMLaZSnsTLg3ynlAd+DIgwGIqU3bZVdSCp4wuwXrSyGNW42MBA DfT2IvA6sq630BUYtYJvp9QN8BYyhoig8Zt51jYMEzSgQtQAZv8VKjkgzCtjaD2A UW2PMDJTUFmruH/DwsnI =G1vz -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-30337-1397570615-0001-2-- From nobody Tue Apr 15 07:14: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 F2EA81A0441 for ; Tue, 15 Apr 2014 07:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.802 X-Spam-Level: X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CTYPE_001C_B=0.001, 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 Zh8LdO_L80N1 for ; Tue, 15 Apr 2014 07:14:49 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id C54FA1A00CF for ; Tue, 15 Apr 2014 07:14:46 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 15 Apr 2014 10:14:38 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Tue, 15 Apr 2014 10:14:37 -0400 From: Dan Brown To: "tls@ietf.org" Thread-Topic: Minor note: static DH key exchange also impacted by KCI attacks Thread-Index: Ac9YAEy+i62WjDR6Se6hWsKbkTXMtQ== Date: Tue, 15 Apr 2014 14:14:37 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5C710BE@XMB116CNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CF5893.81216540" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-afJn-JXXVO2HK1bfsj1Gju2IbU Subject: [TLS] Minor note: static DH key exchange also impacted by KCI attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:14:52 -0000 ------=_NextPart_000_0000_01CF5893.81216540 Content-Type: multipart/related; boundary="----=_NextPart_001_0001_01CF5893.81216540" ------=_NextPart_001_0001_01CF5893.81216540 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0002_01CF5893.81216540" ------=_NextPart_002_0002_01CF5893.81216540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The following point about attacks on static DH may be moot because (1) static DH key exchange is rarely (or never?) used in TLS, especially on the client side, (2) maybe most hosts do not even have static DH certs to support these TLS ciphersuites, (3) static DH is already vulnerable to FS attacks, and (4) static DH is likely to be deprecated in favour of ephemeral DH (I'm only presuming this, because I haven't been following TLS closely enough to be sure). Recall that key-compromise impersonation (KCI) means that if Eve learns Bob's long-term private key, then Eve can use it to impersonate Alice to Bob (i.e. not just impersonate Bob to anybody else). Like a forward secrecy (FS) attack, its pre-requisite is a compromised long-term key, but the negative consequence is impersonation rather than secret compromise. Static DH has long been known not to resist either KCI or FS attacks. The heartbleed bugs suggests that the long-term private key compromise pre-requisite to both FS and KCI attacks might have been available. Static DH usage in TLS may therefore have been affected by KCI or FS attacks. If a server lost its static DH private key via heartbleed, then a KCI adversary may have been able to impersonate client's static DH keys (or re-used ephemeral DH keys for any server trusting re-used ephemerals as in TOFU). If some similar bug, or something else, ever leaks client static DH private keys, or re-used ephemeral DH private keys, then such a client may be affected by a KCI attack in which servers using static DH for authentication are impersonated. So, KCI attacks give all the more reason (i.e. in addition to FS attacks) to use key agreement involving ephemeral keys from both sides, and in particular to deprecate static DH key exchange. It TLS wants to keep static DH around, then it should somehow explain or remedy both FS and KCI threats. Authentication via run-time signing prevents KCI attacks, so TLS's [EC]DHE suites resist KCI attacks. If TLS wants authentication without signing (say, for better efficiency or for better off-the-record properties), then it should also be careful to avoid KCI attacks. By the way, resistance to FS attacks does not imply resistance to KCI attacks: for example, the unified model key agreement scheme from SP 800-56A does not resist KCI attacks. Best regards, Daniel Brown Research In Motion Limited ------=_NextPart_002_0002_01CF5893.81216540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following point about attacks on static DH may be moot = because (1) static DH key exchange is rarely (or never?) used in TLS, = especially on the client side, (2) maybe most hosts do not even have = static DH certs to support these TLS ciphersuites, (3) static DH is = already vulnerable to FS attacks, and (4) static DH is likely to be = deprecated in favour of ephemeral DH (I’m only presuming this, = because I haven’t been following TLS closely enough to be = sure).

 

Recall that key-compromise impersonation (KCI) means that = if Eve learns Bob’s long-term private key, then Eve can use it to = impersonate Alice to Bob (i.e. not just impersonate Bob to anybody = else).  Like a forward secrecy (FS) attack, its pre-requisite is a = compromised long-term key, but the negative consequence is impersonation = rather than secret compromise.  Static DH has long been known not = to resist either KCI or FS attacks.

 

The heartbleed bugs suggests that = the long-term private key compromise pre-requisite to both FS and KCI = attacks might have been available.  Static DH usage in TLS may = therefore have been affected by KCI or FS attacks.  If a server = lost its static DH private key via heartbleed, then a KCI adversary may = have been able to impersonate client’s static DH keys (or re-used = ephemeral DH keys for any server trusting re-used ephemerals as in = TOFU).

 

If some similar bug, or something else, ever leaks client = static DH private keys, or re-used ephemeral DH private keys, then such = a client may be affected by a KCI attack in which servers using static = DH for authentication are impersonated.

 

So, KCI attacks give all the more = reason (i.e. in addition to FS attacks) to use key agreement involving = ephemeral keys from both sides, and in particular to deprecate static DH = key exchange.  It TLS wants to keep static DH around, then it = should somehow explain or remedy both FS and KCI = threats.

 

Authentication via run-time signing prevents KCI attacks, = so TLS’s [EC]DHE suites resist KCI attacks.  =

 

If TLS wants authentication without signing (say, for = better efficiency or for better off-the-record properties), then it = should also be careful to avoid KCI attacks.  =

 

By the way, resistance to FS attacks does not imply = resistance to KCI attacks: for example, the unified model key agreement = scheme from SP 800-56A does not resist KCI attacks. =

 

Best regards,

 

Da= niel Brown

= Research In Motion Limited =

 

 

 

------=_NextPart_002_0002_01CF5893.81216540-- ------=_NextPart_001_0001_01CF5893.81216540 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAArALADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3qW6t 4W2yzxRn0dwKV7iGOMSPNGqN0YsADXjPxI8IXfibxi88HifSrRFjSJLaa42up75Ge9TeLfBN4fB/ h/QD4nsLeSzDSSS3c+wy59OeQKAPYY5Y5l3RSI6+qtkU+vI9GY/CHwJLqWpXw1b7VcqI0tnynOcb Sf1rpvAfxHtPHUt3DBYzWslsoZvMIIIP0oA7aivPPGfxWtPB+vLpLabPdyGISFomAxk9KydN+O+k XOpRWl7pd3ZrIwXzXIIXPqKAPWaK4vxD8Q7XQvFWk6ClnJdTaiFKSRsNqhjgZ/nXaUAFFFFABRRX GWXxBgv/AIhXHhOCxlLQAl7ncNnAz0/SgDs6Kiup1tbSa4f7sSM5+gGa8gHx/sn3GPQLx1B+8GFA HslFcV4I+JeleNpZbaCKW1vI13GGUglh6giu1oAKKKKACiiigAooooA8W174Jahr/iu91abWYI47 q4MuBEdyL6A034heB7PX9bs4pfFOnWn2C0S1WG5OX47n3Ne115F4l+C03iTxLd6vNrpi+0uGKCLO 0DoPyoGU/Et1o/w38JaHoGo6emvrIXlBkfaqkY5A9OeK7H4Yaro2teH5LzSNFXSh5mySMc7j6g9x WzL4M0G8tLODUNNgvjaxCKN7hNzACtW00+102yFrYW8VtCoOxI1wBQI+cNZ8SiH4x3+srp7anFbS FEhUZ6ADP55pdQ1h/ip4t0vTYrC00gI3O/Cs3PI9zxwKl8MeIG+HXirXjrGj3U91PKQuIzwNxOQf fIqxp76n8R/ijZ6vZ6S1jb2zIzuUIAC9ycDJPSgZsWMK6z+0CsK5e10uEIhPbYgx+tT/ABAuvEWo eJ3srvxDZaBoyEiM/aPncf3io5z7Vh+CtafRPiV4ghvLS6bU9RleG1IjzscscE56L05rntDvtF07 WdUfxnpF/qWomU+VGwJBbJ+8PfjmgDf8CeI7zQvH66ZB4gl1bR/Kd5ZWBwQqkkgEk8VNBL4v+Lmu Xz2Wovp+kwMVTa5VQO3Tkk1V+GmlDxD4w190shYL9hlWGEIVWPflcc+maTwR42uPhi2o6Hq2lzuv mFl2rg7hx+IPFAHReC7jxt4R8YPo+tRXd5pG1t1wRuRAASGDfhXFeHvHMXhzXfEeteWbjUbtmSyB HyqSx5J9MYrsrLx54u1zw94i1a/t4rfRYrdkhRYCHZm+UKD3wD1rmtH+Gg1H4T3GvIkp1QHzIVOR +7XqMdyeaANubQte03wLq3inxPqly19PFm2tPNIVS3dh647Vzngzx6PB3h6W2bw39s82Qv8AaHUb c4x6dK6DVNT1Lxn8Dkjgile+02dFu02ncyKCN2O/b8qjtfira6f4Mh0O18OTSzLbeQTJGdpYjBPT nmgCv4GkXRrPXPiLO9tvVXigs4T0dz0I7dKzbSXU/GMc2sar48tdMuC58m2knKnjtgEbR+danhrw Hrdx8L/EMr28kU16yTW9uy4LBMngds5/Sub0y+8G2uiGDWPDl/LrUeVAViqOe2e4oA9E+G3xGvjo muw61OLttIhMyT5z5ijIxnv04+tYeiw+L/HS3Pi271x7PTbaUuI1YgMqHJQAflz61VurRNN+FWoa nBob6ZcanLHBFGXZ2kjB5OMcV192G8N/s9rEkbJc3FsBtC8h3OTx9KAMDQovGHxU1K41NdYfT9Jg m2pGpI4/ugD271e+FPiWfTV8V/21fSyRaf8AODM5OACw7+vFdp8IdMbTfh3YCRNksxaVwR6nj9K8 U8R6PqFz8UNW8O6c7gX12FZVPBXg5P05oA9E+Fv9seLPEmo+LNRubhbESMtrb7zsyfbuAOK9irO0 HRrbw/olrpdooEVugXOPvHuT7k1o0CCiiigAooooAhms7a4YNNbxSMOhdAafFDFAmyGNI1/uouBT 6KAKzafZvdi6a0gNwOkpjG4fj1psml6fNci5lsrd5wc+Y0QLfnVuigCGO1t4pWljgjSRvvMqAE/j UVzplheuHurK3ncDAaSMMR+dW6KAIfstv9nFv5EfkjgR7Bt/KnpDHFEIo41WMDAVRgflT6KAIYbW 3t93kwRx7vvbEAz9ajGm2IYMLO3DA5B8sVaooAKpSaRps05nl0+1eUnJdolJz9cVdooAiltoJ0CT QxyKvQOoIFElvBLEIpIY3jHRWUEflUtFAFDVJriw0e4k060E1xHGfJgXgM3YfSvPPhb4J1PTtQ1D xH4khK6tdSEIrNuKKepz78D8K9SooAKKKKAP/9k= ------=_NextPart_001_0001_01CF5893.81216540-- ------=_NextPart_000_0000_01CF5893.81216540 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKEnebhgAAAAACLDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xNDA0MDIwMTAxMDVaFw0xNjA0MDIwMTExMDVaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBBDAjBgkrBgEEAYI3FQIEFgQUw5ebePlhnXu4v2Olo6hBCdO5beQwGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AB9qnJzs3rqTnItONE+oELqQhsc8/EMtU/r613YtCHaBQGyQk7bFuxxvdJ7mQijpNg43iN1YGaQJ Dg8SgUs4xQTnXVAp+6UohFVfRDNTQQsSEotJ7IgHIzjtdXlo4TDL1t9ncfx9Xn9aQMFXlPHfC4I0 8ZX5rYfi6NDEoIVOnqL1oEHHIcoj2ORom0O+M72enzgfNqudRE0l9HWNGJcOTYCzDSVm5f9Sv364 Z+nQ1+hT3Uwg1EIyGDuA8pYtdRjWguiHUIGv9QP30VWfMKZXl0KNTLQh7T60eDFhFSerj2vwWcDR 3Li/xE1eOJh6UpsBiCra8CD461PkU2gSEPW+Ti4rCPNegq2nGV+4ND0pg5Nc5HAqUbDbMvm8clSB 8IomPkmz2NR/xo94MhA3l9e7IDMu62ulgEZ0+vn+bBH6bF5TwGTroTSuW7Rs13ZsrSz1svaHpyiw D5VMFR8rcOnwaibJZZ/MRfEbcjULg8r1CS1gskdSo39iuqcMiJrzFWXv+8Oxws7AHIG19p/TK5BL tJhn/8SaF3t4QXMqG8Ag8xjOqUQbrm2/p32eDwutNn9W+uXekdmI7nQ5Dko/bSoLdkGzOzZjxwWA D2E7xH3OLjiqe6ZeSjLiXHDwmVl+j0DdW6XFdHlwuQ10v/CcaRnF6TDNf6OsB1oKligAIqck/cyo MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNDE1 MTQxNDM2WjAjBgkqhkiG9w0BCQQxFgQU6tSY6iS/2cUgQtyxhHN3H2eCSsIwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgM1ez4nuBXrq OEJ6EF4jcTczhzh0XNZ/NsC8Gwe7NsmVQ+cTrMDtKTjMfElvW0KkpXRC+yT1uLism4I/WfKZmAcZ AqeBhEq48fa1plX34nMiHCNSKW8a1l9skwD2z9S6DqhRe6hsbAxEqHekJ6DwPCXvy1THXTuX4/hW KqImVY9bAAAAAAAA ------=_NextPart_000_0000_01CF5893.81216540-- From nobody Tue Apr 15 07:22: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 EB7FB1A0451 for ; Tue, 15 Apr 2014 07:22:53 -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 5LFrE1WEmrAO for ; Tue, 15 Apr 2014 07:22:51 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9701A01E2 for ; Tue, 15 Apr 2014 07:22:51 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9944EF2C04B; Tue, 15 Apr 2014 10:22:38 -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 bLuTX3w8fmuZ; Tue, 15 Apr 2014 10:22:17 -0400 (EDT) Received: from [192.168.2.107] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C0B5AF2C07E; Tue, 15 Apr 2014 10:22:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 15 Apr 2014 09:12:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dB9OhlbiD4e8NayYIZPqAUh_lT0 Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 14:22:54 -0000 On Apr 15, 2014, at 12:27 AM, Nico Williams wrote: > FWIW, I believe the matter is very clear now: Weierstrass curves out, > Edwards curves in. For all the reasons Watson gave, and, really, for > all the reasons that DJB has given. >=20 > DJB is so convincing on this subject that the burden of proof is on > anyone opposing the switch to Edwards curves. >=20 > That we have NIST curves code lying around is not a sufficient > argument: it will either not be constant time or its performance will > not be anywhere near as good as implementations of comparable Edwards > curves. The first consideration (no side channels) is unarguably a > hard requirement; the second (good performance) is close enough to a > hard requirement that it might as well be. >=20 > Nico Nico: If your last paragraph is a response to the postings that I made = yesterday, then you are over simplifying my points. I am not arguing against the adoption of Edwards curves. However, I am = saying that there are many that will need FIPS 140 certification, and we = need to accommodate that community as well. This will be important in = the way that the curve being used is negotiated. Russ From nobody Tue Apr 15 08:01:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295761A02CB for ; Tue, 15 Apr 2014 08:01:23 -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 iRgzj_Pq_KPE for ; Tue, 15 Apr 2014 08:01:17 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9120F1A0186 for ; Tue, 15 Apr 2014 08:01:17 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id 29so9395980yhl.6 for ; Tue, 15 Apr 2014 08:01: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=7m2wG9nf1NYyTlBhRDSGuJWXlRAl9AAWkYqDrciVjtQ=; b=MsjicvyUS5Oe7nQTu0eCXbKIkgqzlAXVI+B9iM7N2Qq8ys/Z8z9dunA40LYsGWsvVe AiOkzXbkGuR4gEn7U/Gx+1M8koGJAp0lpTlYk5g7rOO98fD4hRhzNTm6sZVqOZgEECKT p2qFcu3fmwz9QjEH4LJq3AKo5ATRtXxjPu0FktG14HOdcPFTRinvUtOwb8ZLI3kHVmQ8 /8DDW+2vb8rk9Hz6in2uHxzTvFTAKneSIyWUckNZ5kkUjN9MMXs1me9IQHfbGcxe/9ox /IcR1TeIGyTnUJXXmfKli1MS8TxzcHyTjQy2vl1+BYcj+85Xvc3dr4mcelVY7u8zCBII NVKw== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr3411931yhh.66.1397574074625; Tue, 15 Apr 2014 08:01:14 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 15 Apr 2014 08:01:14 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> Date: Tue, 15 Apr 2014 08:01:14 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zvHN3C2QeufDHGBFOcKHptU-spw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:01:23 -0000 On Tue, Apr 15, 2014 at 6:56 AM, Salz, Rich wrote: >> So if you're hosting like tumblr, you can do yoavnir.tumblr.com and richsalz.tumblr.com and have a *.tumblr.com certificate. > > Yes, I know. It would mean that aaa.privacy.org and kkk.privacy.org would be under the same DNS name. You could mitigate that by having a CNAME entry. > > My question is about the security, not the discoverability (or vanity, if you will). Figure out how the browser knows to not send SNI (are we going to do this for everything? probably not) and I think we've solved the problem. DNS entries may or may not work: I need to think about it more. Sincerely, Watson Ladd > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > 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 Apr 15 08:04: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 2C2CB1A0201 for ; Tue, 15 Apr 2014 08:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmB_exbcHdO6 for ; Tue, 15 Apr 2014 08:04:28 -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 30D931A01F8 for ; Tue, 15 Apr 2014 08:04:28 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2B751481B9; Tue, 15 Apr 2014 15:04:23 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 1F93A481CD; Tue, 15 Apr 2014 15:04:23 +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 0708D98042; Tue, 15 Apr 2014 15:04:23 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 15 Apr 2014 11:04:22 -0400 From: "Salz, Rich" To: Watson Ladd Date: Tue, 15 Apr 2014 11:04:22 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9Yu42H3ms5oA2YTcqiQM3omoPxSQAADByQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B490359@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@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/uVHsYQHX2GovGvvNUwR7TQVn2Ng Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:04:34 -0000 PiBGaWd1cmUgb3V0IGhvdyB0aGUgYnJvd3NlciBrbm93cyB0byBub3Qgc2VuZCBTTkkgKGFyZSB3 ZSBnb2luZyB0byBkbyB0aGlzIGZvciBldmVyeXRoaW5nPyBwcm9iYWJseSBub3QpIGFuZCBJIHRo aW5rIHdlJ3ZlIHNvbHZlZCB0aGUgcHJvYmxlbS4NCg0KQSBzd2l0Y2ggb24gdGhlIGJyb3dzZXIs IGp1c3QgbGlrZSBjb29raWUtY29udHJvbCwgdGhhdCBzYXlzICJlc3RhYmxpc2ggdGhlIHByaXZh dGUgY29ubmVjdGlvbiBiZWZvcmUgaWRlbnRpZnlpbmcgdGhlIGhvc3QiIG9yIHNvbWUgc3VjaC4g IENoYW5nZSBmb3VyIHBpZWNlcyBvZiBzb2Z0d2FyZSBhbmQgeW91J3ZlIHByb2JhYmx5IGdvdCA5 MCUgb2YgdGhlIGJyb3dzZXIgbWFya2V0IGhhbmRsZWQuDQoNCgkvciQNCg0KLS0gIA0KUHJpbmNp cGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0K DQo= From nobody Tue Apr 15 08:36: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 0D8F61A06AD for ; Tue, 15 Apr 2014 08:35: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 cRsceAj7KbFk for ; Tue, 15 Apr 2014 08:35:53 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E48751A0476 for ; Tue, 15 Apr 2014 08:35:51 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 3C6412007F004 for ; Tue, 15 Apr 2014 08:35:49 -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=Oebrapdl+38vl7rOGymdfUtn+F4=; b=xI7YtqmCZBR 3gnEn8g0SSNC7p2EZ8OCt43j1Aq10F6n7lm7tcwoj4QezXehqjBBMLEWadJWUcnp xCvxFMQ01o7+dZNHgWF0/epOcToGtwgMFQ4yg20hEyB/HV+0d4N5p5weH9dWHT0k d4scl5z+m5iWm8xXzVMk/6sZ9izrkjFI= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPSA id E58592007F002 for ; Tue, 15 Apr 2014 08:35:48 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so9477182wes.6 for ; Tue, 15 Apr 2014 08:35:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.191.133 with SMTP id gy5mr2311521wjc.34.1397576147747; Tue, 15 Apr 2014 08:35:47 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 15 Apr 2014 08:35:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 10:35:47 -0500 Message-ID: From: Nico Williams To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7Lr6YWMJYOaqw3jV-ZNW74CuyTo Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 15:35:58 -0000 On Tue, Apr 15, 2014 at 8:12 AM, Russ Housley wrote: >> That we have NIST curves code lying around is not a sufficient >> argument: it will either not be constant time or its performance will >> not be anywhere near as good as implementations of comparable Edwards >> curves. The first consideration (no side channels) is unarguably a >> hard requirement; the second (good performance) is close enough to a >> hard requirement that it might as well be. > > If your last paragraph is a response to the postings that I made yesterda= y, then you are over simplifying my points. It was in response to your post (I should have responded separately, but I also wanted to respond to that generally and in the same place in which I supported Watson's comments). > I am not arguing against the adoption of Edwards curves. However, I am s= aying that there are many that will need FIPS 140 certification, and we nee= d to accommodate that community as well. This will be important in the way= that the curve being used is negotiated. FIPS-140 may be in for some modernization. Nico -- From nobody Tue Apr 15 08:42: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 80C2E1A02D6 for ; Tue, 15 Apr 2014 08:42:45 -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 4uSaMzc9RXxm for ; Tue, 15 Apr 2014 08:42:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6267A1A0176 for ; Tue, 15 Apr 2014 08:42:43 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9EB2CF2C079; Tue, 15 Apr 2014 11:42:30 -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 m9RZiJH4DLFc; Tue, 15 Apr 2014 11:42:09 -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 D4212F2C075; Tue, 15 Apr 2014 11:42:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 15 Apr 2014 11:41:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/I4ybLgmiydeNGAiEky27wQ4g9d4 Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 15:42:45 -0000 Nico: >> I am not arguing against the adoption of Edwards curves. However, I = am saying that there are many that will need FIPS 140 certification, and = we need to accommodate that community as well. This will be important = in the way that the curve being used is negotiated. >=20 > FIPS-140 may be in for some modernization. Of course. It has continued to evolve since it was created, and we = cannot expect it to happen on our timeline. Therefore, we should be = give a transition plan to those that need one. I think that means a way = to support the current curves as well as those that we select for the = future. We need a negotiation mechanism regardless. Russ From nobody Tue Apr 15 08:44:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF12B1A02D6 for ; Tue, 15 Apr 2014 08:44:34 -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 J0AFDt6aZlMd for ; Tue, 15 Apr 2014 08:44:30 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 92BF31A02CB for ; Tue, 15 Apr 2014 08:44:30 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id DF8B221DE6F for ; Tue, 15 Apr 2014 08:44:27 -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=aKFwJNnjcVDopsWdF94mh/2L0qA=; b=mN1NbcErxZz t2cFbKAzvR88fAp5JPW+RX17XUEciYbTrPG+2KeKzeCmYF3DUlK8w1h1wkfp3iAk a7tQX7epF+3w+vn25YE7yPIdZBllEyrNwGilPCzVq0+O8xYOOJZ7Ha+1qo8c3jn1 48JzlzUL/YimYTgfFlv9eWYJIQywXws8= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 7F26721DE6A for ; Tue, 15 Apr 2014 08:44:27 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so9595063wgh.11 for ; Tue, 15 Apr 2014 08:44:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.48.80 with SMTP id j16mr2282838wjn.44.1397576666238; Tue, 15 Apr 2014 08:44:26 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 15 Apr 2014 08:44:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 10:44:26 -0500 Message-ID: From: Nico Williams To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7tVVDcMSfv49cMpqJRC92E5eoLA Cc: IETF TLS Subject: Re: [TLS] Why Edwards? (was Re: TLS process thread) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 15:44:35 -0000 On Tue, Apr 15, 2014 at 10:41 AM, Russ Housley wrote= : >>> I am not arguing against the adoption of Edwards curves. However, I am= saying that there are many that will need FIPS 140 certification, and we n= eed to accommodate that community as well. This will be important in the w= ay that the curve being used is negotiated. >> >> FIPS-140 may be in for some modernization. > > Of course. It has continued to evolve since it was created, and we canno= t expect it to happen on our timeline. Therefore, we should be give a tran= sition plan to those that need one. I think that means a way to support th= e current curves as well as those that we select for the future. Of course. NIST curves might need to be RECOMMENDED for interop, but Edwards curves should be REQUIRED to implement because they are the future. > We need a negotiation mechanism regardless. No argument from me here! I'm all for algorithm agility. Nico -- From nobody Tue Apr 15 08: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 354861A06D9; Tue, 15 Apr 2014 08:56:05 -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_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JvGikBBmwwq; Tue, 15 Apr 2014 08:56:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6D1A0451; Tue, 15 Apr 2014 08:56:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140415155601.32616.45951.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 08:56:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pglXIdzZIam6YuS8o-misfEpErM Cc: tls@ietf.org Subject: [TLS] TLS Working Group Interim Meeting, May 15-16, 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 15:56:05 -0000 The TLS working group will hold a face-to-face interim in Denver on May 15-16. We realize that there are participants who will not be able to make this meeting, but there is a restricted set of dates due to the availability of chairs and authors in the upcoming months. We expect to have virtual interim meetings on specific topics before the next IETF. We are also considering having another face-to-face interim just before the next IETF meeting. Meeting Details: Dates/Times: 15 May 2014 (9:00 am - 5:00 pm MDT) 16 May 2014 (9:00 am - 2:00 pm MDT) Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA Registration: Send TLS chairs an email at tls-chairs@tools.ietf.org (only for capacity planning purposes as we have limited space) Remote Participation: via Webex Lodging: Individual responsibility. Cheers, TLS Chairs From nobody Tue Apr 15 09:07:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26A21A01BE for ; Tue, 15 Apr 2014 09:07: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 dKk0qwaxZCq6 for ; Tue, 15 Apr 2014 09:07:19 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id CC79E1A07C0 for ; Tue, 15 Apr 2014 09:07:09 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so6955835lbd.23 for ; Tue, 15 Apr 2014 09:07: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w/5y9CqH7EcNpqtKViudBpHEVxXx3omdNV9yuuNrAcU=; b=ZAzWXrsoY+CRbyGw5zbbO5MyTacJNzb6+8M4tje2UHRlEvNYSOTTThxKjM5x71ox+p q+cXZFmE2Hqf5MwVvyGUFzMa9w830o5Oy9aQdD1FDHL8JRXy73AdNKsfI9uRwubu8rlh typ7Ck7nQi7en1+4R4g+BvKZDhJVwSKIN4I7wzwh+oOjbPRG5NGZUU9QnsHjdS0dQn9B twcXK7+osO2yI+RqXQlJJ20s8Fmn0EI/saNUi/LkWh44h8VXYc6dqxPA3pdQrnrBymDP FG3iWJ4U0V1YGVE18G4Fg+IkNC1wKKkqkFOwe/+0f/HbKQkxLpL6jiwjtdxbHVXEC+87 0Azw== X-Gm-Message-State: ALoCoQm8SLgq0l5QF5ZsWs1Rv0KmxPRQlyjZ8AKjQCGm4LGqcuQMQkE61oBneecJTOcyRJMsQfOq X-Received: by 10.112.165.40 with SMTP id yv8mr40841lbb.83.1397578026085; Tue, 15 Apr 2014 09:07:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.115.2.36 with HTTP; Tue, 15 Apr 2014 09:06:25 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 15 Apr 2014 09:06:25 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11346900ca825004f716fdb1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7z-JBnHZLaLxcvMfNInfLCbMJfs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:07:25 -0000 --001a11346900ca825004f716fdb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 15, 2014 at 6:56 AM, Salz, Rich wrote: > > So if you're hosting like tumblr, you can do yoavnir.tumblr.com and > richsalz.tumblr.com and have a *.tumblr.com certificate. > > Yes, I know. It would mean that aaa.privacy.org and kkk.privacy.orgwould be under the same DNS name. You could mitigate that by having a > CNAME entry. > > My question is about the security, not the discoverability (or vanity, if > you will). Rich, I'm not sure I completely understand your proposal, so let me try to restate it: 1. Privacy.org would host aaa.privacy.org, bbb.privacy.org, ... zzz.privacy.org and have a cert for *.privacy.org 2. This allows the user to avoid revealing his target server as long as it is matches *.privacy.org *and* he has some mechanism for suppressing SNI. 3. If the user wants to have www.zzz.org virtually hosted, he needs a CNAME that points from www.zzz.org -> zzz.privacy.org. Do I have this right? -Ekr /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11346900ca825004f716fdb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 15, 2014 at 6:56 AM, Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com&g= t; wrote:
> So if you're hosting like tumb= lr, you can do yoav= nir.tumblr.com and richsalz.tumblr.com and have a *.tumblr.com certificate.

Yes, I know. =A0It would mean that aaa.privacy.org and kkk.privacy.org would be under the same DNS name. = =A0You could mitigate that by having a CNAME entry.

My question is about the security, not the discoverability (or vanity, if y= ou will).

Rich,

I&= #39;m not sure I completely understand your proposal, so let me try to rest= ate it:

1. Privacy.org would host aaa.privacy.org, bbb.privacy.o= rg, ... zzz.privacy.org
and have a cert for *.privacy.org
<= div>
2. This allows the user to avoid revealing his target se= rver as long as it is
matches *.pr= ivacy.org *and* he has some mechanism for suppressing SNI.

3. If the user wants to have www.zzz.org virtually hosted, he needs a CNAME
that poin= ts from www.zzz.org -> zzz.privacy.org.

Do I have this right?

-Ekr




=A0 =A0 =A0 =A0 /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

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

--001a11346900ca825004f716fdb1-- From nobody Tue Apr 15 09:22: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 77EE81A049C for ; Tue, 15 Apr 2014 09:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urwCNccoWl0P for ; Tue, 15 Apr 2014 09:22:20 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 85BFD1A047D for ; Tue, 15 Apr 2014 09:22:20 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Tue, 15 Apr 2014 17:22:10 +0100 To: tls@ietf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gKjqZCV3TaDUacdRjXV3rNS8E08 Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:22:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15 April 2014 17:06:25 BST, Eric Rescorla wrote: >3. If the user wants to have www.zzz.org virtually hosted, he needs a >CNAME >that points from www.zzz.org -> zzz.privacy.org. Not wishing to state the obvious about this idea, if that is indeed what the idea is and we've not misunderstood, but that CNAME had better be DNSSEC-signed: otherwise Mallory of the not-exactly-hypothetical Nation State Adversary just uses QUANTUM to inject a fake CNAME DNS response to redirect https://bob.example/ to https://bob.evil.nsa/ when Alice looks it up, and Mallory's CA-signed certificate for *.evil.nsa becomes worth its weight in gold as Alice's browser accepts the redirect. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTTVyxGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6SeYP/2FJ06fKFUPGAhVkcTrVvjquRxJADHR7Ju5MnQ3XDb6yBhsuLyZx SOH1PaH5XcW7E+GMfw3PeXqjbuYLb+FmfUZNW7JzwPc1oyEhUmr0h0z+l+kj1RD7 E6IWWdE2ARnHoNg9xMdM7E8us4oXujevH7Pc9kp9PWyme2Eo8wQxT2vl3bQjW2r1 75HP72F0IuP79ibhZjNQeMYTKBj5TVllioFf563y16H0rP1f0WMtpTzSdaxNt1Je KY9r2S/XcbqB0sTc64Vam7q03HkotbKxA9x8i8VIXWLv3w9S43iwJrn8dlTuIZDd i7vrTafEsd5wzMKG7HhBzWbJokxwMhIatRBRT/kyzdiLyix3WyNh274rZULcNIPP n9zMvtTSgAWYQLwzdEYdBel2tzQ68y0OO8fPKE6nJk9VI8ZNE2q7TSPJFVdoQHW3 TA28+3d+NKijQq0Ffo43nOACSAb8EQN17wLDxy++BssnyVhSnwIzKSkvkq277c9k LPzK7wFRQVxbRFl26Vi0c9FHusVHMII+v+KxWx4bgzm9LDn68l4SUeUdOcD7TRsG 4ZudoF/jnmBY4tCTjfgvckCq9UdUVSTjgOIG71PvcgMPX57ayb7VGwdw7upcKL6m RZvUuPhh1ZlH2DPKUz8RI9QZp8x4imfTVoB4aFmKxNPUzz0JwAs8tj2a =uFhf -----END PGP SIGNATURE----- From nobody Tue Apr 15 09:37: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 9291F1A0499 for ; Tue, 15 Apr 2014 09:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dD9UsY-BmpT for ; Tue, 15 Apr 2014 09:37:02 -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 D874F1A01BE for ; Tue, 15 Apr 2014 09:37:01 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D103C28642; Tue, 15 Apr 2014 16:36:58 +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 BC9BB28641; Tue, 15 Apr 2014 16:36:58 +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 B8A4A2035; Tue, 15 Apr 2014 16:36: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; Tue, 15 Apr 2014 12:36:58 -0400 From: "Salz, Rich" To: Eric Rescorla Date: Tue, 15 Apr 2014 12:36:57 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9YxMGttJKH1S5mQ3auG/awb964lwAAsldg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@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_2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QpRz-Ym2NaL1DE2veTYIonNrTtU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:37:03 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, you have it right. Alyssa's concerns about DNS are valid, but I do wo= nder if the CNAME security requirements are any different than the A/AAAA s= ecurity requirements; I need to think about it. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, you = have it right.  Alyssa’s concerns about DNS are valid, but I do = wonder if the CNAME security requirements are any different than the A/AAAA= security requirements; I need to think about it.

 

           &nbs= p;    /r$

<= o:p> 

--  =

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3USMBX1msgcorp_-- From nobody Tue Apr 15 09:38: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 603311A079F for ; Tue, 15 Apr 2014 09:38:10 -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 DQEN0E3NdOqc for ; Tue, 15 Apr 2014 09:38:08 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 418A01A0499 for ; Tue, 15 Apr 2014 09:38:08 -0700 (PDT) Received: from dhcp-171-68-20-40.cisco.com (unknown [171.68.20.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F35BA509B5 for ; Tue, 15 Apr 2014 12:38:04 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 15 Apr 2014 09:39:17 -0700 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/W-RonJDfw9bXZKYi5MN6czAaZ1k Subject: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 16:38:10 -0000 Not that this is relevant, since the WG has already been chartered and my reading of the charter is that we are to revise TLS, not to do a contest for something entirely new. However, long-time IETF experience with bake-offs is generally really bad. The IETF process is good at making decisions where one looks at a change, then decides if that changes will work or not from a technical point of view and how to tweak it so it will work in most cases. The IETF process is crappy at choosing between two proposals where both would work and a bunch of people would prefer A and a bunch of others would prefer B but everyone agrees both A and B both basically work. You can see the chairs of rtcweb flailing to try and find any way to resolve the H.264 vs. VP8 questions in that WG. I=91m one of the flailing co-chairs so I have spend some time looking at this. When we look back at the history of bake-offs that I have been involved with at IETF, the outcomes were not great. (BTW, that bake-off is TM and you aren=92t allowed to use it at IETF). Midcom took so long everyone that was building products gave up and used something else. LOST, a protocol primarily driven to help E911 work on phones, used a bake-off and I=92m unaware of any jurisdiction that has deployed LOST outside of trials. I=92m sure there are multiple theories why but one of them would be people just did other things having watched how much the bake-off process polarized the community. People were so upset at outcomes that they just did proprietary solutions. The P2PSIP community spent s long arguing about to converge that eventually the authors more than the WG decide how to merge the proposal down to one that had enough critical mass to get consensus in the WG. That was a painful and far from ideal way to move forward. The selection of who to encrypt RTP took years and in the end managed to get to strong consensus but even with that the factions that did not win have continually caused enough uncertainty in the market place to substantial reduce deployments. The basic issue is bake-offs take too long in the IETF process and don=92t have a deterministic way to complete in finite time. What happens is along the lines of you get 5 proposals - along with much hype about each of them. You then ask the WG to choose, the great surprise happens that the WG can not choose. So you decide to write use cases to drive requirements and then to analyze each of the 5 to see what happens. In the meantime the 5 merge to 3 and the all 3 evolve so they are functionally equivalent. Note that the merging and evolution, by definition, involves a fair amount of bloat and complexity added to at least 2 out of the 3 to ensure they are equally bloated. By the time the analysis is finished, all the proposal meet all the requirements and 4 years have gone past. Now the really sad thing happens - the WG still can=92t decide. Some times what happens next is eventually enough people decide the outcome is so irrelevant in the real world that they stop coming to the WG and after time you you have a small enough group to make a choice. So basically you can=92t make a decision until after the decision is irrelevant to deployments. I think the IETF needs some experiments to find a better way to make decisions like this, but I don't think TLS is the place for that. Cisco does quite a bit of TLS in our products and from that perspective, what I'd like to see is a TLS 1.3 that finishes quickly. I don't believe that a competition/bakeoff is that way to do that. Given that we already have a protocol widely deployed, we should focusing on improving that, not holding a contest for something totally new.= From nobody Tue Apr 15 09:43: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 C3F171A079F for ; Tue, 15 Apr 2014 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2MOeZjgspEG for ; Tue, 15 Apr 2014 09:43:28 -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 5C6601A04F1 for ; Tue, 15 Apr 2014 09:43:28 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 478B0474FF for ; Tue, 15 Apr 2014 16:43:25 +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 3C246474ED for ; Tue, 15 Apr 2014 16:43:25 +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 36EBD2035 for ; Tue, 15 Apr 2014 16:43:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 15 Apr 2014 12:43:23 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Tue, 15 Apr 2014 12:43:23 -0400 Thread-Topic: TLS Working Group Interim Meeting, May 15-16, 2014 Thread-Index: Ac9Ywz20mw+BA8oBTteU+AiXzfdeogABoRwA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903FD@USMBX1.msg.corp.akamai.com> References: <20140415155601.32616.45951.idtracker@ietfa.amsl.com> In-Reply-To: <20140415155601.32616.45951.idtracker@ietfa.amsl.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/jNzgxJbwwHxtghEBpA2ItWNbHJc Subject: Re: [TLS] TLS Working Group Interim Meeting, May 15-16, 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 16:43:31 -0000 Q2FuIGFueW9uZSBmcm9tIGNpc2NvIHByb3ZpZGUgYSBsaXN0IG9mIGhvdGVscz8NCg0KLS0gIA0K UHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdl LCBNQQ0KDQo= From nobody Tue Apr 15 09: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 A1E591A0552 for ; Tue, 15 Apr 2014 09:54:55 -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 laaWf0WoGK-J for ; Tue, 15 Apr 2014 09:54:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E0A831A02E0 for ; Tue, 15 Apr 2014 09:54:52 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3FGsjQC007889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Apr 2014 18:54:45 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Tue, 15 Apr 2014 18:54:45 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140415165445.637E91ACC7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-PjxQazLkSN-h30V1hfZVTQsMeY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:54:55 -0000 Salz, Rich wrote: > > Yes, you have it right. Alyssa's concerns about DNS are valid, > but I do wonder if the CNAME security requirements are any different > than the A/AAAA security requirements; I need to think about it. Both have no security requirements for HTTP-over-TLS. The way that HTTP-over-TLS was originally designed, it was without trust into DNS, i.e. *NONE* of the transformations that happen during DNS lookup (CNAME, A/AAAA) affect the processing of the server endpoint identification. (SMTP got it wrong) -Martin From nobody Tue Apr 15 09: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 670BC1A02E0 for ; Tue, 15 Apr 2014 09:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 O2PSCem_Gd0d for ; Tue, 15 Apr 2014 09:55:49 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5BA1A011A for ; Tue, 15 Apr 2014 09:55:49 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D7812F2C079; Tue, 15 Apr 2014 12:55:36 -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 Oi6T1zvRTuk6; Tue, 15 Apr 2014 12:55:15 -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 66DE2F3C003; Tue, 15 Apr 2014 12:55:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: Date: Tue, 15 Apr 2014 12:55:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0D72AF0B-4637-4292-9FF2-4D64ED6670C3@vigilsec.com> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QmgDwWhlTmflSTDBGmebh5UluG0 Cc: tls@ietf.org Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 16:55:51 -0000 Cullen: I would also like to see a TLS 1.3 process that goes quickly, focusing = on: - choosing mandatory to implement algorithms that have a lot of = community confidence, - throwing out little-used options, and - making incremental improvements. Bakeoffs are not good tools for making decisions. By contrast, I have = seen that getting a bunch of implementers in a room and working out = interoperability issues does lead to better specifications. The = problems that are encountered often identify the rough spots in the = text. Also, these sessions provide a lot of useful information to the = implementers themselves. Russ On Apr 15, 2014, at 12:39 PM, Cullen Jennings wrote: >=20 > Not that this is relevant, since the WG has already been chartered > and my reading of the charter is that we are to revise TLS, > not to do a contest for something entirely new. However, > long-time IETF experience with bake-offs is generally really > bad. >=20 > The IETF process is good at making decisions where one looks at a > change, then decides if that changes will work or not from a technical > point of view and how to tweak it so it will work in most cases. The > IETF process is crappy at choosing between two proposals where both > would work and a bunch of people would prefer A and a bunch of others > would prefer B but everyone agrees both A and B both basically > work. You can see the chairs of rtcweb flailing to try and find any > way to resolve the H.264 vs. VP8 questions in that WG. I=91m one of = the > flailing co-chairs so I have spend some time looking at this. >=20 > When we look back at the history of bake-offs that I have been > involved with at IETF, the outcomes were not great. (BTW, that > bake-off is TM and you aren=92t allowed to use it at IETF). Midcom = took > so long everyone that was building products gave up and used something > else. LOST, a protocol primarily driven to help E911 work on phones, > used a bake-off and I=92m unaware of any jurisdiction that has = deployed > LOST outside of trials. I=92m sure there are multiple theories why but > one of them would be people just did other things having watched how > much the bake-off process polarized the community. People were so > upset at outcomes that they just did proprietary solutions. The P2PSIP > community spent s long arguing about to converge that eventually the > authors more than the WG decide how to merge the proposal down to one > that had enough critical mass to get consensus in the WG. That was a > painful and far from ideal way to move forward. The selection of who > to encrypt RTP took years and in the end managed to get to strong > consensus but even with that the factions that did not win have > continually caused enough uncertainty in the market place to > substantial reduce deployments. >=20 > The basic issue is bake-offs take too long in the IETF process and > don=92t have a deterministic way to complete in finite time. What > happens is along the lines of you get 5 proposals - along with much > hype about each of them. You then ask the WG to choose, the great > surprise happens that the WG can not choose. So you decide to write > use cases to drive requirements and then to analyze each of the 5 to > see what happens. In the meantime the 5 merge to 3 and the all 3 > evolve so they are functionally equivalent. Note that the merging and > evolution, by definition, involves a fair amount of bloat and > complexity added to at least 2 out of the 3 to ensure they are equally > bloated. By the time the analysis is finished, all the proposal meet > all the requirements and 4 years have gone past. Now the really sad > thing happens - the WG still can=92t decide. Some times what happens > next is eventually enough people decide the outcome is so irrelevant > in the real world that they stop coming to the WG and after time you > you have a small enough group to make a choice. So basically you can=92t= > make a decision until after the decision is irrelevant to deployments. >=20 > I think the IETF needs some experiments to find a better way to make > decisions like this, but I don't think TLS is the place for that. >=20 > Cisco does quite a bit of TLS in our products and from that > perspective, what I'd like to see is a TLS 1.3 that finishes > quickly. I don't believe that a competition/bakeoff is that way to do > that. Given that we already have a protocol widely deployed, we > should focusing on improving that, not holding a contest for > something totally new. From nobody Tue Apr 15 10:00: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 473021A0499 for ; Tue, 15 Apr 2014 10:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cnHfH1_oxmsB for ; Tue, 15 Apr 2014 10:00:04 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id C16F91A011A for ; Tue, 15 Apr 2014 10:00:03 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 79so9004474ykr.23 for ; Tue, 15 Apr 2014 10: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 :content-type; bh=Lr+JuLENXMCCAHT0qDWGf3bC6yWfqhF8qdiHAOeqfks=; b=itgTC6HbciGw9V4AtaX7Abqwm6DDTH9C9mk/K6hwrALUolVsXuq5oRzvQCmQ7rVcg/ LbcsGSLVyNtHQl4UfO/8kr5c7abPqGtwXYtyZwrd0B0J4RCm4ylhx7UHDHuRcJO+uouK PxYj1m+iUk3lSYrdBwHkrhoYHP+UJK+x4cXMKRThcMHw6tNNmax3K9NywXgGI38bAA9m n0v4a5CLOfMJmdMgAUoNJxtlf2F1FMJTgCvqeyoOTByUgxzoa1OFTm4IusLo9dM1d8RN 0U51EFxReidkBSZBW9ArJtRWzqRptIk+UKshMHFl8rPspQBOvrLmgkUS4kO0Y97rhcj4 Vayw== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr4267304yhi.83.1397581200716; Tue, 15 Apr 2014 10:00:00 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 15 Apr 2014 10:00:00 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 15 Apr 2014 10:00:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 10:00:00 -0700 Message-ID: From: Watson Ladd To: Cullen Jennings , tls@ietf.org Content-Type: multipart/alternative; boundary=bcaec5468c5103941404f717bb88 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UkntOYBjClv0x84a3nuj6LLgnyU Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 17:00:08 -0000 --bcaec5468c5103941404f717bb88 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 15, 2014 9:38 AM, "Cullen Jennings" wrote: > > > Not that this is relevant, since the WG has already been chartered > and my reading of the charter is that we are to revise TLS, > not to do a contest for something entirely new. However, > long-time IETF experience with bake-offs is generally really > bad. > > The IETF process is good at making decisions where one looks at a > change, then decides if that changes will work or not from a technical > point of view and how to tweak it so it will work in most cases. The > IETF process is crappy at choosing between two proposals where both > would work and a bunch of people would prefer A and a bunch of others > would prefer B but everyone agrees both A and B both basically > work. You can see the chairs of rtcweb flailing to try and find any > way to resolve the H.264 vs. VP8 questions in that WG. I=E2=80=98m one of= the > flailing co-chairs so I have spend some time looking at this. > TLS right now doesn't work. We also have a problem with making implementations because of the complexity, which means OpenSSL is in the TCB. Bakeoffs are much easier for competent people to look at each option because they are static. They reward coherent, simple designs. > When we look back at the history of bake-offs that I have been > involved with at IETF, the outcomes were not great. (BTW, that > bake-off is TM and you aren=E2=80=99t allowed to use it at IETF). Midcom = took > so long everyone that was building products gave up and used something > else. LOST, a protocol primarily driven to help E911 work on phones, > used a bake-off and I=E2=80=99m unaware of any jurisdiction that has depl= oyed > LOST outside of trials. I=E2=80=99m sure there are multiple theories why = but > one of them would be people just did other things having watched how > much the bake-off process polarized the community. People were so > upset at outcomes that they just did proprietary solutions. The P2PSIP > community spent s long arguing about to converge that eventually the > authors more than the WG decide how to merge the proposal down to one > that had enough critical mass to get consensus in the WG. That was a > painful and far from ideal way to move forward. The selection of who > to encrypt RTP took years and in the end managed to get to strong > consensus but even with that the factions that did not win have > continually caused enough uncertainty in the market place to > substantial reduce deployments. > > The basic issue is bake-offs take too long in the IETF process and > don=E2=80=99t have a deterministic way to complete in finite time. What > happens is along the lines of you get 5 proposals - along with much > hype about each of them. You then ask the WG to choose, the great > surprise happens that the WG can not choose. So you decide to write > use cases to drive requirements and then to analyze each of the 5 to > see what happens. In the meantime the 5 merge to 3 and the all 3 > evolve so they are functionally equivalent. Note that the merging and > evolution, by definition, involves a fair amount of bloat and > complexity added to at least 2 out of the 3 to ensure they are equally > bloated. By the time the analysis is finished, all the proposal meet > all the requirements and 4 years have gone past. Now the really sad > thing happens - the WG still can=E2=80=99t decide. Some times what happen= s > next is eventually enough people decide the outcome is so irrelevant > in the real world that they stop coming to the WG and after time you > you have a small enough group to make a choice. So basically you can=E2= =80=99t > make a decision until after the decision is irrelevant to deployments. > > I think the IETF needs some experiments to find a better way to make > decisions like this, but I don't think TLS is the place for that. > TLS has usecase: authenticate Alice and Bob to each other, letting one side be anymous, via X509. That's it. > Cisco does quite a bit of TLS in our products and from that > perspective, what I'd like to see is a TLS 1.3 that finishes > quickly. I don't believe that a competition/bakeoff is that way to do > that. Given that we already have a protocol widely deployed, we > should focusing on improving that, not holding a contest for > something totally new. The quickest finishing process is no process: you don't do anything. What about the substance? > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --bcaec5468c5103941404f717bb88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 15, 2014 9:38 AM, "Cullen Jennings" <fluffy@iii.ca> wrote:
>
>
> Not that this is relevant, since the WG has already been chartered
> and my reading of the charter is that we are to revise TLS,
> not to do a contest for something entirely new. However,
> long-time IETF experience with bake-offs is generally really
> bad.
>
> The IETF process is good at making decisions where one looks at a
> change, then decides if that changes will work or not from a technical=
> point of view and how to tweak it so it will work in most cases. The > IETF process is crappy at choosing between two proposals where both > would work and a bunch of people would prefer A and a bunch of others<= br> > would prefer B but everyone agrees both A and B both basically
> work. You can see the chairs of rtcweb flailing to try and find any > way to resolve the H.264 vs. VP8 questions in that WG. I=E2=80=98m one= of the
> flailing co-chairs so I have spend some time looking at this.
>

TLS right now doesn't work. We also have a problem with = making implementations because of the complexity, which means OpenSSL is in= the TCB.

Bakeoffs are much easier for competent people to look at eac= h option because they are static. They reward coherent, simple designs.

> When we look back at the history of bake-offs that I ha= ve been
> involved with at IETF, the outcomes were not great. (BTW, that
> bake-off is TM and you aren=E2=80=99t allowed to use it at IETF). Midc= om took
> so long everyone that was building products gave up and used something=
> else. LOST, a protocol primarily driven to help E911 work on phones, > used a bake-off and I=E2=80=99m unaware of any jurisdiction that has d= eployed
> LOST outside of trials. I=E2=80=99m sure there are multiple theories w= hy but
> one of them would be people just did other things having watched how > much the bake-off process polarized the community. People were so
> upset at outcomes that they just did proprietary solutions. The P2PSIP=
> community spent s long arguing about to converge that eventually the > authors more than the WG decide how to merge the proposal down to one<= br> > that had enough critical mass to get consensus in the WG. That was a > painful and far from ideal way to move forward. The selection of who > to encrypt RTP took years and in the end managed to get to strong
> consensus but even with that the factions that did not win have
> continually caused enough uncertainty in the market place to
> substantial reduce deployments.
>
> The basic issue is bake-offs take too long in the IETF process and
> don=E2=80=99t have a deterministic way to complete in finite time. Wha= t
> happens is along the lines of you get 5 proposals - along with much > hype about each of them. You then ask the WG to choose, the great
> surprise happens that the WG can not choose. So you decide to write > use cases to drive requirements and then to analyze each of the 5 to > see what happens. In the meantime the 5 merge to 3 and the all 3
> evolve so they are functionally equivalent. Note that the merging and<= br> > evolution, by definition, involves a fair amount of bloat and
> complexity added to at least 2 out of the 3 to ensure they are equally=
> bloated. By the time the analysis is finished, all the proposal meet > all the requirements and 4 years have gone past. Now the really sad > thing happens - the WG still can=E2=80=99t decide. Some times what hap= pens
> next is eventually enough people decide the outcome is so irrelevant > in the real world that they stop coming to the WG and after time you > you have a small enough group to make a choice. So basically you can= =E2=80=99t
> make a decision until after the decision is irrelevant to deployments.=
>
> I think the IETF needs some experiments to find a better way to make > decisions like this, but I don't think TLS is the place for that.<= br> >

TLS has usecase: authenticate Alice and Bob to each other, l= etting one side be anymous, via X509. That's it.

> Cisco does quite a bit of TLS in our products and from = that
> perspective, what I'd like to see is a TLS 1.3 that finishes
> quickly. I don't believe that a competition/bakeoff is that way to= do
> that. Given that we already have a protocol widely deployed, we
> should focusing on improving that, not holding a contest for
> something totally new.

The quickest finishing process is no process: you don't = do anything. What about the substance?
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--bcaec5468c5103941404f717bb88-- From nobody Tue Apr 15 10: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 AA8F21A07D9 for ; Tue, 15 Apr 2014 10:01:50 -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 3UgulsjszbTf for ; Tue, 15 Apr 2014 10:01:46 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id B70581A011A for ; Tue, 15 Apr 2014 10:01:45 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so9918063wgh.22 for ; Tue, 15 Apr 2014 10:01: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=mDLfV4uWO6z8syS1XuEEsRdU7sI81e8i6mpMOr4KebQ=; b=Is5/Gcexy4UkAoE7JtMYFUykBhnA1T04BddAeahBWO9Nm0cNbCuW/lBDscHQGhKjTz Gy2FmFxn7xtmtsjGNyFe//KtHh112ARw8B4CbAywkp/GO+rxsZ/m6X6plyWeqRonpD75 Q4qrUaNftQddkiwJoQtHEHGEkc/N16bkxFJaMR1nUD4BS3nMIDTBRvDUu6rIqJ2HxrhW k0vFKl1sD9uKLQH8ymwYJpV+c4l0u45nVNJJQjIjE1WHxhBresq0dhxEFs0nkECjYtYA RukR/hbFBSYWntoRzakegpcj6fkMW+at+tYoOI2yz+WeCC2/sFECfBvg6aKN0u8F3lmM Npjw== X-Gm-Message-State: ALoCoQns0l6jg35n/KKkrG57eQQHtyQ3WgV64i5NmTDhsZsFGNmjCiinNLjwLLLMGPQ5WK771f14 X-Received: by 10.180.90.140 with SMTP id bw12mr3456002wib.18.1397581302317; Tue, 15 Apr 2014 10:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 15 Apr 2014 10:01:02 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 15 Apr 2014 10:01:02 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f46d043c811a11e40404f717c1ee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d2jDm0uaQVUF2HKc7jE4fQFVe64 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:01:51 -0000 --f46d043c811a11e40404f717c1ee Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 15, 2014 at 9:36 AM, Salz, Rich wrote: > Yes, you have it right. Alyssa's concerns about DNS are valid, but I do > wonder if the CNAME security requirements are any different than the A/AAAA > security requirements; I need to think about it. > My claim is that they are. Here's why I say that: The basic TLS model (and in fact the 3552 model) is that the attacker controls the network. This means that the attacker can detour the packets anywhere he wants, regardless of what IP addresses are in them. Thus, forging A/AAAA resolution just makes this easier. In order to defend against this, TLS verifies that the name in the certificate matches the name it is trying to connect to. In the current environment, that means that if the client tries to connect to https://aaa.example.org/ and this is CNAMEd to https://example.cdn.org/, the client checks for aaa.example.org, so it doesn't need to trust the DNS. If we want to have him instead check for example.cdn.org, then the CNAME needs to be verifiable (e.g., via DNSSEC). With that said, I don't think this is necessarily a dealbreaker: as has been discussed a number of times, encrypted SNI doesn't provide much in the way of concealing the target domain without encrypted DNS, which would presumably also be authenticated, at which point this attack wouldn't work. With that in mind, consider the following handwavy design: We have a secure delegation record with the following semantics: - It indicates that domain www.example.org is delegated to example.cdn.org - It indicates that .cdn.org does not require SNI. example.cdn.org would have two certificates: #1: A certificate for (*.cdn.org) #2: A certificate for www.example.org So, a legacy client would: 1. Get the CNAME but not know it could trust it, so it sends SNI for aaa.example.org 2. Because SNI is provided, the server provides certificate #2. 3. The client expects certificate for www.example.org, checks that name, and we are good to go (though without concealing SNI). [This is the way things are now. A new client would: 1. Get the CNAME and see that it's a secure delegation with a no SNI. 2. Because no SNI is provided, the server provides the default certificate (#1) 3. Because the client knows about secure delegation it checks for example.cdn.org instead of aaa.example.org and because the server has a wildcard cert for *.cdn.org, it all works. Obviously this requires messing with DNS to provide confidentiality and secure delegation, but we would need confidentiality in any case, and secure delegation is mostly a matter of working out the record semantics once you've solved the big problem of securing the DNS. [0] I only just wrote this down, so maybe it's totally messed up, but it seems like a natural extension of Rich's idea. What do people think? -Ekr [0] Note: I'm not saying this is solved since DNSSEC deployment isn't good right now, but if it's not solved then SNI encryption doesn't buy us much. > > > /r$ > > > > -- > > Principal Security Engineer > > Akamai Technology > > Cambridge, MA > > > --f46d043c811a11e40404f717c1ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Apr 15, 2014 at 9:36 AM, Salz, Rich <rsalz@akamai.com> wr= ote:

Yes, you have it right.  Alyssa’s= concerns about DNS are valid, but I do wonder if the CNAME security requir= ements are any different than the A/AAAA security requirements; I need to t= hink about it.


My claim is that they are. Her= e's why I say that:

The basic TLS model (and i= n fact the 3552 model) is that the attacker controls
the network.= This means that the attacker can detour the packets anywhere
he wants, regardless of what IP addresses are in them. Thus, forging
A/AAAA resolution just makes this easier. In order to defend again= st this,
TLS verifies that the name in the certificate matches th= e name it is
trying to connect to. In the current environment, that means that if
the client tries to connect to https://aaa.example.org/ and this is CNAMEd
to https://example.cdn.org/, the client checks fo= r aaa.example.org,
so it doesn't need to trust the DNS. If we want to have him instea= d check
DNSSEC).

With that said, I don't think this is necessarily a= dealbreaker: as has been
discussed a number of times, encrypted = SNI doesn't provide much in the
way of concealing the target = domain without encrypted DNS, which would
presumably also be authenticated, at which point this attack wouldn= 9;t work.


With that in mind, consid= er the following handwavy design:

We have a secure= delegation record with the following semantics:
    - It indicates that= .cdn.org does not require SNI.

example.cdn.org = would have two certificates:

#1: A certificate for=  (*.cdn.org)
#2: A certifica= te for www.example.org


So, a legacy client would:
1. = Get the CNAME but not know it could trust it, so it sends SNI for aaa.example.org
2. Because SNI is= provided, the server provides certificate #2.
3. The client expects certificate for www.example.org, checks that name, and we are
good to = go (though without concealing SNI).

[This is the w= ay things are now.


A new client would:
1. Get the= CNAME and see that it's a secure delegation with a no SNI.
2= . Because no SNI is provided, the server provides the default certificate (= #1)
3. Because the client knows about secure delegation it checks for example.cdn.org
    = instead of aaa.example.org and becau= se the server has a wildcard cert for
    *.cdn.org, it all works.<= /div>

Obviously this requires messing with DNS to provid= e confidentiality and secure
delegation, but we would need confid= entiality in any case, and secure delegation
is mostly a matter of working out the record semantics once you've= solved the
big problem of securing the DNS. [0]

I only just wrote this down, so maybe it's totally messed up, = but it seems like a
natural extension of Rich's idea. What do people think?
=
-Ekr



= [0] Note: I'm not saying this is solved since DNSSEC deployment isn'= ;t good
right now, but if it's not solved then SNI encryption doesn't = buy us much.






 

 

         &= nbsp;      /r$

 

--  =

Principal Security Engine= er

Cambridge, MA

 = ;


--f46d043c811a11e40404f717c1ee-- From nobody Tue Apr 15 11:01:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61441A0368 for ; Tue, 15 Apr 2014 11:01: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 qOp3W-lsHqet for ; Tue, 15 Apr 2014 11:01:41 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 957381A02E3 for ; Tue, 15 Apr 2014 11:01:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a1so10088025wgh.32 for ; Tue, 15 Apr 2014 11:01: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=JG5ZSRChi79mSFS7iYf7i3dRdTvVSo/4YUhZdMQLrS4=; b=beeAz7Rmxralm0QInnHiF+httRm+sVGHc3KPKhYo+CJM+hlRIb9/wvq308+kXmudcH IyuxRb9NuQuTikXz02eTzsR0nehxz4etpgdGZNIo/rkJL3F3yJguYSlmCxptstVWm5qe SGxOJw893aywKTeFmUv2IvthkUuAt99gZW56Szmzs0/53LIZpgpZpYwlekflHbpscSmR M+b0wOGJNCByIS29SiExZP+lrfBnG7tyTTCaHT5Q2O7wCL+zNDZ6+sHH5/zwMpAw+vS1 XNJCU4auCSizW2P/biMppExyRVPtll19L/P2xTWs9GUguV7LOLooghuA2oo1qg5O01oo fQQQ== MIME-Version: 1.0 X-Received: by 10.180.36.232 with SMTP id t8mr6332104wij.1.1397584898224; Tue, 15 Apr 2014 11:01:38 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 11:01:38 -0700 (PDT) In-Reply-To: <534C850B.1030505@pobox.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> Date: Tue, 15 Apr 2014 11:01:38 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KCEIkOyFiFnRJxKpxCY6oa9KuNM Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 18:01:47 -0000 On 14 April 2014 18:02, Michael D'Errico wrote: > But then some time later, someone registers "http/2 over HNTP" at code > point 139. The same TLS stack can not possibly know that protocol 139 > in ALPN means http/2 without an upgrade, leading to a failure. That's exactly the failure we're actually looking for here. Something changed. (BTW, it's strings: "h2" for HTTP/2 over TLS, "h2c" for HTTP/2 over TCP) From nobody Tue Apr 15 11: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 4DB501A0376 for ; Tue, 15 Apr 2014 11:15:36 -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 N45WqTN0RVIS for ; Tue, 15 Apr 2014 11:15:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 23AA01A03F5 for ; Tue, 15 Apr 2014 11:15:32 -0700 (PDT) Received: from [10.70.10.85] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id B3DB1F984; Tue, 15 Apr 2014 14:15:27 -0400 (EDT) Message-ID: <534D772F.5020908@fifthhorseman.net> Date: Tue, 15 Apr 2014 14:15:11 -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=?= , Yoav Nir References: <20140415153435.7f82b3a0@hboeck.de> <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> <20140415160327.7dd88945@hboeck.de> In-Reply-To: <20140415160327.7dd88945@hboeck.de> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6bMwEusNP2e1BWrco5t8j6U7sb2H77ag4" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5e0qbe89Nc1vKCOV1l1ld746EEw Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:15:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6bMwEusNP2e1BWrco5t8j6U7sb2H77ag4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/15/2014 10:03 AM, Hanno B=C3=B6ck wrote: > My opinion on that is that we should have multiple lines of defense. > Sure, if the RNG is bad we should fix it. But we all know good RNGs is > a nontrivial problem. So while fixing RNGs is a priority, we also shoul= d > have algorithms that don't completely break so badly that they spit out= > the public key if the RNG fails. https://tools.ietf.org/html/rfc6979 suggests a way to use DSA that doesn't break as catastrophically if the RNG fails. --dkg --6bMwEusNP2e1BWrco5t8j6U7sb2H77ag4 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/ iQJ8BAEBCgBmBQJTTXcvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc1FcP/3XA6MKZgDACcgzkrwEorH+x YxUGrYbVwWYgHO7Pow9Dsbarhrxkmnj9qII7ICir82lo7+8rarfoiJw1deRkoK8Y 64GjcYes4zBqT1K/DUZyHVdmI1yfZwnCqV20FxZ/E5nzCNt+iSDwucFOUMyPL5Ki 6Mna+X4+PKW5v2Yl12CLewEZgidP7iGoAOB1n+yvBVTTfmcFM3lhOSB+OE4sH4C4 19GOIuGlDr6RJANyNiIe+8IPd4W96ilcTvMxVNUMcDN9R3NUqN9ETHP0o3r+HS5m SJe0spU4gkJy1u30XqXE9QpONhq9mfjDQwFE0nq9rFma84MufLf+a5jwclANuBCd FscHehhktYMIpypQHbxFsAPbHIP1d/RDSrlzFEo4UvU2doks+A4A+CKJLuY57twh 1Lc6R/5wY0YYOnKk91SimOoDiWH6YzkZyCuji0EK3A2CJRu0H89BIZN7vz5fpLTA xKZL3z7MhVHBL99T9Gnw3lvgbCHXCC+ZYS5VC9qylaybD02yZ2F2E7xrCbG5tS5h sJJVWttiya5RQxZ42HsfyzgpjJc8GqQXaK/U03VtWvUHzhxUtETYb0zB6mYevcEg syGNRji/wUu3NPMQx+Cz07rhPsXJRvml0LiVTyc1BHp6DRhTr5Xr1P/j4RQJmlkh uFQQ4IfHE9PNYFn2RbrR =Ugm9 -----END PGP SIGNATURE----- --6bMwEusNP2e1BWrco5t8j6U7sb2H77ag4-- From nobody Tue Apr 15 11:28: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 0149A1A0330 for ; Tue, 15 Apr 2014 11:28:00 -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 qu6MHJffPsNL for ; Tue, 15 Apr 2014 11:27:55 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE61A0772 for ; Tue, 15 Apr 2014 11:27:55 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so202877wiv.13 for ; Tue, 15 Apr 2014 11:27: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fy6eU9/MuRTL/9HffBoHVslvMPXnJu0WoBroqKwqnxw=; b=GOwDjW1VljDcBNfLUuPckvhDCUzdyxdoSE6NHOjVps6VjT0fjdNKvJIze4nueqH/OP zWJaJU7KJlzzULu9zp8eFjV4rlKkvg6ph02Og4LafnO/8QBckJwww5lk0KEPQaaTvf4A 2K1hohnhX2/+zxZxLkpaeJHdgF95M1UcKLB+v6ht9aEdK2F09nBwPPkunSeIJHmNSdKI QNbGLKNMmR1EybWlktQUCRpLePKkeQQ1ZkWHOPYPAtY3ATXKuBk1ynJfVgztAhrLVeV0 vnpQfxO/0olM4wSXVCBQIEeZ1w6HIC9Ayg0GiD3OL15/lvQm7OGR2B3wSEG7Xh9sNWB4 ww0w== X-Gm-Message-State: ALoCoQmllnwO8F+0zaMVxm/nLolocxshSsmcaPsr3hID5hETQvDXT3hf3CM3bA7sbs6VYB7TKBPc X-Received: by 10.180.81.228 with SMTP id d4mr15525634wiy.49.1397586471939; Tue, 15 Apr 2014 11:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 15 Apr 2014 11:27:11 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490291@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4902B5@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4903F3@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 15 Apr 2014 11:27:11 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f46d043bdb0e3438fa04f718f57d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5HyZebrv0OhcydhssWOzy2hmWNk Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:28:00 -0000 --f46d043bdb0e3438fa04f718f57d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 15, 2014 at 10:01 AM, Eric Rescorla wrote: > > Obviously this requires messing with DNS to provide confidentiality and > secure > delegation, but we would need confidentiality in any case, and secure > delegation > is mostly a matter of working out the record semantics once you've solved > the > big problem of securing the DNS. [0] > Martin Thomson pointed out to me offline that this sort of conflates two forms of DNS security: 1. End-to-end resolution security (e.g., DNSSEC or something like DNSCurve where there is a chain of delegations all the way down to the leaf node). 2. Client-to resolver security (e.g., DNScrypt or where the attacker is not on-path to your resolver but is on-path to the server) where you hope that your activities are hidden by DNS caching. Clearly, this proposal will only work when integrity is provided down the entire chain, although it might work if there was DNSSEC + client-to-resolver confidentiality. However, note that: (a) IETF is just starting to look at standardizing DNS encryption (b) the existing DNS encryption systems have seen limited deployment (c) most of the problems with DNSSEC deployment have to do with intermediate elements which would either block DNS encryption or (alternately) could use DNS encryption to bypass the intermediary messing with the DNSSEC records Given these issues, it still seems like it's at least plausible to consider DNS integrity a prerequisite here. -Ekr I only just wrote this down, so maybe it's totally messed up, but it seems > like a > natural extension of Rich's idea. What do people think? > > -Ekr > > > > [0] Note: I'm not saying this is solved since DNSSEC deployment isn't good > right now, but if it's not solved then SNI encryption doesn't buy us much. > > > > > > > > >> >> >> /r$ >> >> >> >> -- >> >> Principal Security Engineer >> >> Akamai Technology >> >> Cambridge, MA >> >> >> > > --f46d043bdb0e3438fa04f718f57d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 15, 2014 at 10:01 AM, Eric Rescorla &= lt;ekr@rtfm.com> wrote:
Obviously this requires messing with DNS to provide confidentiality and se= cure
delegation, but we would need confidentiality in any case, a= nd secure delegation
is mostly a matter of working out the record semantics once you've= solved the
big problem of securing the DNS. [0]

Martin Thomson pointed out to me of= fline that this sort of conflates two
forms of DNS security:

1. End-to-end resoluti= on security (e.g., DNSSEC or something like DNSCurve
=A0 =A0 wher= e there is a chain of delegations all the way down to the leaf node).
2. Client-to resolver security (e.g., DNScrypt or where the attacker i= s
=A0 =A0 =A0not on-path to your resolver but is on-path to the s= erver) where you hope
=A0 =A0 =A0that your activities are hidden = by DNS caching.

Clearly, this proposal will only work when integrity is= provided down the entire
chain, although it might work if there = was DNSSEC + client-to-resolver
confidentiality. However, note th= at:

(a) IETF is just starting to look at standardizing DNS = encryption
(b) the existing DNS encryption systems have seen limi= ted deployment
(c) most of the problems with DNSSEC deployment ha= ve to do with
intermediate elements which would either block DNS encryption
or (alternately) could use DNS encryption to bypass the intermediary
messing with the DNSSEC records

Given these = issues, it still seems like it's at least plausible to consider DNS
integrity a prerequisite here.

-Ekr





I only just wrote this down, so maybe it's totally messed up, but it s= eems like a
natural extension of Rich's idea. What do people think?
=
-Ekr



= [0] Note: I'm not saying this is solved since DNSSEC deployment isn'= ;t good
right now, but if it's not solved then SNI encryption doesn't = buy us much.






=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

=A0<= /p>

--=A0

Principal Security Engine= er

Cambridge, MA

=A0



--f46d043bdb0e3438fa04f718f57d-- From nobody Tue Apr 15 11:58: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 6AA621A03D7 for ; Tue, 15 Apr 2014 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLMZZhdSXIs6 for ; Tue, 15 Apr 2014 11:58:38 -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 CF1F21A0322 for ; Tue, 15 Apr 2014 11:58:37 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 48D8A11864; Tue, 15 Apr 2014 14:58:34 -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=Th3udBa03BRc 4fBU6VDTyRRPDKo=; b=LijjLDMiJCzsfI9rcwgOJYirgL/omN9F7V5A+4KHabyz FANjxjKqv3hjsGKYiFxI6y655vsPZEMsIUvVgDZOhNtlFe27eWh5i+xDJoCjsgAu DNTup1rUVE6QtgFiKoKpwI+hkGsLLlwDDGPr0hQoM//1v5vtO4WVewPiwlhACU8= 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=TM4j/r BdO1gLz2K1ZpxDoI0XySpefgXt+FdVOUvIkYAYV/Dd6tseZLhjEe3H72D88u1YEz u1H4pYk/DwgGs3m9XymAzV99J5WTbpZZr6oMBWGRTydrWjIwng7qmaFTqCXmcVny Xaisfgds0mku+JG/S1qa30HAXCOFPrdid08Vw= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3DEA711863; Tue, 15 Apr 2014 14:58:34 -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 947DF11862; Tue, 15 Apr 2014 14:58:32 -0400 (EDT) Message-ID: <534D8157.5070200@pobox.com> Date: Tue, 15 Apr 2014 11:58:31 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Thomson References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F0D1F21C-C4CF-11E3-83CD-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8QCJwWs8XNlBPpyFtBeyZ7_mYqM Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 18:58:43 -0000 Martin Thomson wrote: > On 14 April 2014 18:02, Michael D'Errico wrote: >> But then some time later, someone registers "http/2 over HNTP" at code >> point 139. The same TLS stack can not possibly know that protocol 139 >> in ALPN means http/2 without an upgrade, leading to a failure. > > That's exactly the failure we're actually looking for here. Something changed. Can you please explain why you want things to fail and in what circumstances? > (BTW, it's strings: "h2" for HTTP/2 over TLS, "h2c" for HTTP/2 over TCP) Opaque strings are just (large) numbers. Hopefully you're not suggesting that the string be inspected for some structure, e.g. it matches a regular expression such as /^h2/. Mike From nobody Tue Apr 15 12:03: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 C2BFB1A055D for ; Tue, 15 Apr 2014 12:03:34 -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 XhU_VHxd2anR for ; Tue, 15 Apr 2014 12:03:30 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id AE0611A0642 for ; Tue, 15 Apr 2014 12:03:29 -0700 (PDT) Received: from localhost (91-66-81-2-dynip.superkabel.de [::ffff:91.66.81.2]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 15 Apr 2014 21:03:18 +0200 id 0000000000020004.00000000534D8278.000041F8 Date: Tue, 15 Apr 2014 21:02:55 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Daniel Kahn Gillmor Message-ID: <20140415210255.62e9fc65@hboeck.de> In-Reply-To: <534D772F.5020908@fifthhorseman.net> References: <20140415153435.7f82b3a0@hboeck.de> <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> <20140415160327.7dd88945@hboeck.de> <534D772F.5020908@fifthhorseman.net> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-16888-1397588606-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kKAU0d0SGoKvWqL657x361rxWn8 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 19:03:35 -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-16888-1397588606-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 15 Apr 2014 14:15:11 -0400 Daniel Kahn Gillmor wrote: > On 04/15/2014 10:03 AM, Hanno B=C3=B6ck wrote: > > My opinion on that is that we should have multiple lines of defense. > > Sure, if the RNG is bad we should fix it. But we all know good RNGs > > is a nontrivial problem. So while fixing RNGs is a priority, we > > also should have algorithms that don't completely break so badly > > that they spit out the public key if the RNG fails. >=20 > https://tools.ietf.org/html/rfc6979 suggests a way to use DSA that > doesn't break as catastrophically if the RNG fails. Interesting, didn't know that. But basically, the whole discussion about DSA's security is missing the point. It's probably possible to implement DSA in a secure way. But what I really want to achieve is getting TLS simpler. I think there's wide agreement that DSA if done correctly has a security comparable to RSA. However, in TLS everyone uses RSA, nobody uses DSA. And I think unused code is dangerous. Because nobody cares, nobody tests it, nobody looks at it but it still can bite you when it comes to security. That I think is a lesson we should've learned from Heartbleed. And therefore I think we should identify unused parts of the TLS spec and deprecate it. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-16888-1397588606-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) iQIcBAEBCgAGBQJTTYJfAAoJEKWIAHK7tR5Cb+IQAKMSERWtuQ0fPmbGoh+/7SS+ 24hx9c464hJ+AffIyZW7ToB5cavPGSIjaPS0/Y/o71ZSTA5AViONMtQvu1OiXu81 nugVHv0CesBqAk5LynAFjriPisVLmFaWLJ+5ABJCIhpH5MQ5CJgyQhajo7L9PjLj YrGg5AMopgMaOH5DV3GEbXQ+Y9KRN0NWujP77tX/DbifTnAtv5xlnRSF6Xp4IF35 K7E+WlUKhjXuBbKA0IOvqw6BVyq72fgT5u+LYhtC5z5sN/xQ7iw6FcQuM5wnQCpl /WP7jDwh8w77RwXyZbgEjYWoBUgTyQ1C6vOlI7HxXh35Ero0wyYkeytxDxKpadTC yV/rLa5oyP/kz2tvbpQ6mC9JYAwKQPoIqjDNSeu9tWFIp8z8cqIk+GYFwKvMsSaO G6SEYJLX0ogrLBXx668jKfEGsSGVdE6JOWvT1gJ3GsgmucsPzXwahhlWOf5wQqd/ QH13gfWvuKnOIJ0l1BIHWPXx3RjCjn1HFAAuAAe1QjOseeF2gXA4RWhLpwo1i9if mtOPtMCW4CelZcrmJZBIidErdNf/46RvI0TtLJrS0UUOnjGmE0In8ddS5dMJ1wDX +hTV2InBZ18+LtIY09iKAM6AnKg3CodgDF93zc7lYFCMIUT48SABbnsSbwSvvKPZ V+6kMB3kRLh4E99udLPs =z2Wp -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-16888-1397588606-0001-2-- From nobody Tue Apr 15 12:49: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 069071A07E5 for ; Tue, 15 Apr 2014 12:49:39 -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 GowmZnQ1Icuk for ; Tue, 15 Apr 2014 12:49:37 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 549931A0186 for ; Tue, 15 Apr 2014 12:49:37 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c13so7996282eek.23 for ; Tue, 15 Apr 2014 12:49:33 -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=lLo8RABeVuIjohPaeFv+OM+EnWmLDQLFNjpWNQQV8Ac=; b=yhIIp6GBOqNHP/sC17Txw/9cV2g0MNSBsAVWjGXjz67gqV/WFBcetkKxco82LP/nw4 uhYUC17yObLyxDR+NBoa+ZmIR/cQoc1dpnBJO2GCYsM4Md5onqVlYw9andKuJjaD9zNE mkh8EAIrb0PXuq9J9fueUHf0NnCP84ockLgkfah+t3ZYn0MXe2L+ML2TaV4ze026ZFQF 3H3KS6KrQJT7U0a0EMYocz8cR/tUjT0GRio3efGCJpi3PBj7GGrJaMACvwgXf2Y6AXkE KAopi+5A9eEqw0HmQj/Knv1QsR9/+brHEG8mtyaD2eOChcSBz0p43W+0gXCn+PRllRdR AuFQ== X-Received: by 10.14.219.137 with SMTP id m9mr4886341eep.77.1397591373808; Tue, 15 Apr 2014 12:49:33 -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 t44sm51508801eeo.6.2014.04.15.12.49.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 12:49:33 -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: Tue, 15 Apr 2014 22:49:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> References: To: Cullen Jennings X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gzG6VrATNQomhdSLvz1wMr2OeWU Cc: tls@ietf.org Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 19:49:39 -0000 Hi Cullen You have listed several cases of failed competitions, and IPsecME can = provide two others. OTOH we have the shining example of httpbis, = although I think the two things that made that effort a success was that = (a) the proposals were not all that different from each other, and (b) = everyone in the room and on the mailing list preferred getting to work = on some solution rather than debating endlessly. That last one was = missing from many of the other efforts. But anyway, the only proposal we have for TLS 1.3 is the diagrams in = Eric=92s draft. A lot of people say they want a competition. But this is = the IETF. Anyone can submit a draft if they want to. If any of these = people submitted a 5-page draft outlining what they think the next TLS = should look like, we would discuss and compare the two options = regardless of whether the chairs and ADs want to have a competition or = not. So far, nobody=92s come forward. So we=92re all talking about some = hypothetical alternate TLS protocol.=20 Yoav From nobody Tue Apr 15 12:58: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 C47BB1A0675 for ; Tue, 15 Apr 2014 12:58: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 UlmvYbVGKygC for ; Tue, 15 Apr 2014 12:58:17 -0700 (PDT) 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 85F8A1A07DA for ; Tue, 15 Apr 2014 12:58:16 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t60so9762598wes.5 for ; Tue, 15 Apr 2014 12:58: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=iy/vS+b5Z+LwJ/TUaLmxBu6aKyQUIKPqSKQC5jGj19k=; b=o+kJl+/ZxOXq89FTM79+3BUXKcnwJEVcbGlmS0Fdmej1QybRKtFpX5r79mPD+k5kVG 48K9ZJqRLe6l3qTK5CQpxJAzQD1zZTHtVb99/jxOm0MG6eU7krgwD4o0twtwX9CJ4I7k jWUgJJKak2b6Rzv96wxGlkIqBZc94XRPy8n4VVTEpob4WsQCu5QpfKvEyluS3l2nk7fb LvU5/pIeSXTghbqdbzqQGRX3ihru3o2zSyVM3kd7/R52MLHLXaC3SYMi8s7qOibhxRoE 6R9hGc2vAC3Hi5Ejh5c8UlzutiXHDS5HZQ2USWo0lA72Qa6iCyBlMp18W/X4GDpOuNe4 Sn+w== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr3978735wic.58.1397591893159; Tue, 15 Apr 2014 12:58:13 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 12:58:13 -0700 (PDT) In-Reply-To: <534D8157.5070200@pobox.com> References: <53456D1B.1010804@alum.mit.edu> <4bf0dffe7f4e475abf38f1e14e09388e@BL2PR03MB419.namprd03.prod.outlook.com> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> <534D8157.5070200@pobox.com> Date: Tue, 15 Apr 2014 12:58:13 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VkVcSDuTIA3Xq8J72glXq63KIcE Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 19:58:21 -0000 On 15 April 2014 11:58, Michael D'Errico wrote: >> That's exactly the failure we're actually looking for here. Something >> changed. > > > Can you please explain why you want things to fail and in what > circumstances? Does HNTP provide an exact replica of the protocol contract that TCP provides HTTP/2? If not, I want to know. If it is exact in all the ways that matter, might as well use "h2". >> (BTW, it's strings: "h2" for HTTP/2 over TLS, "h2c" for HTTP/2 over TCP) > > > Opaque strings are just (large) numbers. Hopefully you're not suggesting > that the string be inspected for some structure, e.g. it matches a regular > expression such as /^h2/. No way. People keep suggesting that the strings become less than opaque, and we've always fought that off. I was just providing the info. From nobody Tue Apr 15 13:11: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 0F53F1A022D for ; Tue, 15 Apr 2014 13:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iNHlA3vKUGw for ; Tue, 15 Apr 2014 13:11:20 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6A1A044B for ; Tue, 15 Apr 2014 13:11:20 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id q5so375718wiv.1 for ; Tue, 15 Apr 2014 13:11: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:content-transfer-encoding; bh=HwbFTznR55go+nHP4ZAp1Dh5tGtH4QiNGc+ygfUolnE=; b=znymPFyQUFZLiG3Q8W1SjPabKFm2f0E7kNRdgvVIwE+7hhDmAox4O0ZCx0AGUfVwkU e8omkJSQPyjwZtEcNl7nKoJptbsD01K/XmuBPykeTiF+Fr8agHtrrR66t3jyltmeP91F jPzWPwyAlTkc7xy5g/4L2DFDzr5UQN5XmpWXiN+vNAnctVZ1phGnW6GveJQ49XdUZYl/ 8XxnyPTtjoN0Jeh2D/i+7QrfGm2qey4w6m8f2LZpkdNftqrYzElsArL37MilGmxF5YxJ R40Ifqrr5QD75oOceNuC7blT06Fb8jBszItAbsUYqRFJYxzYpZFDLEQ6Hp9MPIGAQZ8V 1U6Q== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr4088865wiw.56.1397592677105; Tue, 15 Apr 2014 13:11:17 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 13:11:17 -0700 (PDT) In-Reply-To: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> Date: Tue, 15 Apr 2014 13:11:17 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iEaXBqNwyxDaMdY7BwNFnBCoC4s Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 20:11:23 -0000 On 15 April 2014 12:49, Yoav Nir wrote: > You have listed several cases of failed competitions, and IPsecME can pro= vide two others. OTOH we have the shining example of httpbis, although I th= ink the two things that made that effort a success was that (a) the proposa= ls were not all that different from each other, and (b) everyone in the roo= m and on the mailing list preferred getting to work on some solution rather= than debating endlessly. That last one was missing from many of the other = efforts. I don't think that HTTP/2 is a good example of a bake-off, because it didn't really work out that way. To put this as inelegantly as I can, HTTP/2 succeeded (or seems likely to) because it does exactly what the IETF does best: take something that works and ram it through the process with minimal changes. What might, to an outsider, have looked like a bake-off back when the effort started, wasn't really a competition between two or more equally well-formed proposals. There was SPDY, which we are using, then there were what amounted to statements of principle from a couple of other groups. What the process did was allow those principles to be expressed, and to have those tested and integrated as consensus permitted. I think that we've strong support for the idea that HTTP/2 is strictly better than SPDY as a result, but that doesn't mean that everyone is getting what they want either; what was clear from this is that all those involved were able to put aside viewpoints where they were outside consensus. A bake-off can reduce the chance of this happening by forcing different parties to become strongly aligned with certain ideas. I generally support Cullen's thesis here. There are few enough people willing to invest the time needed to get the work done in the first place. Forcing the group to divide their efforts and then providing incentives against working together doesn't seem like it's an experiment worth re-running. From nobody Tue Apr 15 13:28: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 55B231A06FE for ; Tue, 15 Apr 2014 13:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsIQtbsSLe-u for ; Tue, 15 Apr 2014 13:28:50 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8157D1A06FF for ; Tue, 15 Apr 2014 13:28:50 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3E9F2165663 for ; Tue, 15 Apr 2014 20:28:47 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 33CC4165662 for ; Tue, 15 Apr 2014 20:28:47 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 8CB9C47BF0 for ; Tue, 15 Apr 2014 20:28:46 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 15 Apr 2014 16:28:45 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Tue, 15 Apr 2014 16:28:44 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9YzD0f7aFfWn+8QIqEJzJaCHf0DwAAhFPA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WbnEx7iuk5yY7q_9Kw-BHfemzxI Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 20:28:52 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRMUyBkb2VzbuKAmXQgd29yay4NCg0KV2VsbCwgdGhhdOKAmXMgYSBiaXQgb2YgYW4gZXhhZ2dl cmF0aW9uLiAgS2luZGEgbGlrZSB3aGVuIEkgd291bGQgc2F5IHRvIHRoZSBraWRzIOKAnEnigJl2 ZSB0b2xkIHlvdSBhIG1pbGxpb24gdGltZXMgbm90IHRv4oCm4oCdDQoNCknigJltIG9wcG9zZWQg dG8gYSBiYWtlb2ZmLiAgSXQgZG9lc27igJl0IHNlZW0gbGlrZSBhIOKAnHN0YW5kYXJk4oCdIGJh a2VvZmYsIGluIHdoaWNoIHdlIGJyaW5nIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiBtb3N0 bHktZG9uZSBzcGVjcy4gIE90aGVycyBoYXZlIGNvbW1lbnRlZCBvbiB0aGUgaGlzdG9yeS4gVGhp cyBzZWVtcyBtb3JlIGxpa2UgYSBzcGVjIGJha2Utb2ZmLCB3aGljaCBpc27igJl0IHJlYWxseSBh IGJha2Utb2ZmIGJ1dCBtb3JlIG9mIGEgY29tcGV0aXRpb24uIEhvdyBkb2VzIHRoYXQgZ2V0IGJl dHRlciBjb2RlIG91dCB0aGVyZT8gIFJvdWdoIGNvbnNlbnN1cyBhbmQgcnVubmluZyBjb2RlIGlz IHRoZSBwaHJhc2UsIGFuZCBJIGRvbuKAmXQgc2VlIGEgY29tcGV0aXRpb24gdG8gY3JlYXRlIFRM UzIgYXMgYSB3YXkgdG8gZ2V0IGEg4oCcYmV0dGVy4oCdIFRMUyBpbiB0aGUgaGFuZHMgb2YgY29u c3VtZXJzIGR1cmluZyAyMDE0Lg0KDQpBbmQsIGlmIHdlIGdvdCByaWQgb2YgdGhlIFNOSSBlbmNy eXB0aW9uIDopIHRoZSBudW1iZXIgb2YgY2hhbmdlcyBiZWluZyBjb25zaWRlcmVkIGlzIHByZXR0 eSBzbWFsbCBpbiBib3RoIG51bWJlciBhbmQgc2NvcGUuDQoNCiAgICAgICAgICAgICAgICAvciQN Cg0KLS0NClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hub2xvZ3kNCkNh bWJyaWRnZSwgTUENCg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7 VExTIGRvZXNu4oCZdCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2VsbCwgdGhhdOKAmXMgYSBi aXQgb2YgYW4gZXhhZ2dlcmF0aW9uLsKgIEtpbmRhIGxpa2Ugd2hlbiBJIHdvdWxkIHNheSB0byB0 aGUga2lkcyDigJxJ4oCZdmUgdG9sZCB5b3UgYSBtaWxsaW9uIHRpbWVzIG5vdCB0b+KApuKAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+SeKAmW0gb3Bwb3NlZCB0byBhIGJha2VvZmYuwqAgSXQgZG9lc27i gJl0IHNlZW0gbGlrZSBhIOKAnHN0YW5kYXJk4oCdIGJha2VvZmYsIGluIHdoaWNoIHdlIGJyaW5n IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBvZiBtb3N0bHktZG9uZSBzcGVjcy7CoCBPdGhlcnMg aGF2ZSBjb21tZW50ZWQgb24gdGhlIGhpc3RvcnkuIFRoaXMgc2VlbXMgbW9yZSBsaWtlIGEgc3Bl YyBiYWtlLW9mZiwgd2hpY2ggaXNu4oCZdCByZWFsbHkgYSBiYWtlLW9mZiBidXQgbW9yZSBvZiBh IGNvbXBldGl0aW9uLiBIb3cgZG9lcyB0aGF0IGdldCBiZXR0ZXIgY29kZSBvdXQgdGhlcmU/wqAg Um91Z2ggY29uc2Vuc3VzIGFuZCBydW5uaW5nIGNvZGUgaXMgdGhlIHBocmFzZSwgYW5kIEkgZG9u 4oCZdCBzZWUgYSBjb21wZXRpdGlvbiB0byBjcmVhdGUgVExTMiBhcyBhIHdheSB0byBnZXQgYSDi gJxiZXR0ZXLigJ0gVExTIGluIHRoZSBoYW5kcyBvZiBjb25zdW1lcnMgZHVyaW5nIDIwMTQuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5BbmQsIGlmIHdlIGdvdCByaWQgb2YgdGhlIFNOSSBlbmNyeXB0aW9u IDopIHRoZSBudW1iZXIgb2YgY2hhbmdlcyBiZWluZyBjb25zaWRlcmVkIGlzIHByZXR0eSBzbWFs bCBpbiBib3RoIG51bWJlciBhbmQgc2NvcGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgL3IkPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLcKgIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Q cmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWthbWFpIFRlY2hub2xvZ3k8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ Q2FtYnJpZGdlLCBNQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5USMBX1msgcorp_-- From nobody Tue Apr 15 14:25: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 BFB8F1A0499 for ; Tue, 15 Apr 2014 14:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX0OYTHmbFGW for ; Tue, 15 Apr 2014 14:25:13 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 463B21A0488 for ; Tue, 15 Apr 2014 14:25:13 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id uo5so10007315pbc.18 for ; Tue, 15 Apr 2014 14:25:10 -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:content-transfer-encoding; bh=msR2qCyM12jTbjMxNUyYbeXRtW4ZTtTN+NK724rp26E=; b=Y/cnJEzSLXVqtYG8rkoTaNhGIAii8BkE92jq5KChu/S0FnpqoDYWTXo49AXRCwVlme VxAY9ko1pu0gwSlmyz0g98uIAHXDKIN6RquR26GJhJiRdsTjVgC5RYno75274ds+ALD9 9eme15+ZKMkLpUYw2h8mxcUfG6AyZuEKAvlF4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=msR2qCyM12jTbjMxNUyYbeXRtW4ZTtTN+NK724rp26E=; b=aceq5JFuw0wNKujf4hGAtYxSI/K8aKCZAhHxiTSOkr2YuUm3z5bH4r8+8eYQrIIUG7 fyF5NoST/GcefFqWSK2n4n5PIL4gs4xqCN759Abnwm9A+YoZm5NXGT1q19AoNcaG0t6y Srp9eIY8S7h11MYTVY6ApwO65XcdP6E1YRWw8k9uqph8rwy2jwfSkgafWQ5NHlJTrWBF 2TvACzohPcKvea2nY3BpvHhHCzK3V//K2oiG3weHkq4fJnUr8IXrwHa+Ygk15Qotj0Sn g0LBj9TEnLSz6iCJfsf7wdvkmHlAPamdnkcc1s+bpDPnkJ2/RXKb/oO/FkCQjRo4gMcy KO+A== X-Gm-Message-State: ALoCoQmAvK+eYVD0YqSINZAAVSYQa00vrcsIalZ7+Tpbn9xBXjNiWcOJH5fDKOgB2qOokVkkVmMB X-Received: by 10.68.132.68 with SMTP id os4mr4348309pbb.129.1397597110364; Tue, 15 Apr 2014 14:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Tue, 15 Apr 2014 14:24:50 -0700 (PDT) In-Reply-To: <20140415210255.62e9fc65@hboeck.de> References: <20140415153435.7f82b3a0@hboeck.de> <500CA3F0-86D2-4C60-8762-4481C1400479@gmail.com> <20140415160327.7dd88945@hboeck.de> <534D772F.5020908@fifthhorseman.net> <20140415210255.62e9fc65@hboeck.de> From: Tom Ritter Date: Tue, 15 Apr 2014 17:24:50 -0400 Message-ID: To: =?ISO-8859-1?Q?Hanno_B=F6ck?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GNEMZYQdNGbWWXOuCJQYKP-cPOA Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating more (DSA?) (was Re: Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 21:25:17 -0000 On 15 April 2014 15:02, Hanno B=F6ck wrote: > But basically, the whole discussion about DSA's security is missing the > point. It's probably possible to implement DSA in a secure way. But > what I really want to achieve is getting TLS simpler. > I think there's wide agreement that DSA if done correctly has a > security comparable to RSA. However, in TLS everyone uses RSA, nobody > uses DSA. > And I think unused code is dangerous. Because nobody cares, nobody > tests it, nobody looks at it but it still can bite you when it comes to > security. That I think is a lesson we should've learned from > Heartbleed. And therefore I think we should identify unused parts of > the TLS spec and deprecate it. I think that's a reasonable approach. I have no problems with removing DSA (but keeping ECDSA around). I also have a strong preference to saying that any implementation of DSA/ECDSA MUST use deterministic DSA. I would love to get NIST* or whatever other standard body we need to bless it so that people will accept that recommendation. (And to be clear, I don't want them to just bless it, I want them to poke and prod at it and try and figure out if they can come up with any attacks, and then bless it.) -tom * I hope that people's distrust of NIST would not go so far as to say that an algorithm developed by a community contributor and blessed by NIST is no longer trustworthy. If so, the new tool of the NSA would be to have NIST bless all the secure algorithms leaving us with just insecure ones ;) From nobody Tue Apr 15 15:18: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 680F31A04A6 for ; Tue, 15 Apr 2014 15:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neWwsj0fL4bJ for ; Tue, 15 Apr 2014 15:17:58 -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 EE3751A04A1 for ; Tue, 15 Apr 2014 15:17:57 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8D7E711372; Tue, 15 Apr 2014 18:17:54 -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=7Ra52gba72Jp CUGtu4NFa2tXzdw=; b=cKKd6V297ftjXhX0g5OrFAOGp8MtYOqFPQ2cwXJpH79N izC6R8mH05G79vqLFSt9R0w0xcEFnH1X3j/utwUxmvhk/AWdeZDm+cLpBKYROpRg wnsnI9WJN5h41rqEIvlvAldLXx17qbNb3tqKCl1Nk5qEkINammGHn5ATVkIGhaE= 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=MS/Rbh sGoyApnKitjTb5W2E0/VP7Rtfm1iuoO2+kJ/7QRDsPqXw5SdD+freN8c6CegYZhv PHPlkz5s7tD00PkEQpLQ5hvd5x+OZ1y4qkRkt7iwWpq7PRdk+kLFSD30SncPENv+ k3XVw8w2inB2ZTKBgHMsnMAOF4Fub0P/u/i7A= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8650D11371; Tue, 15 Apr 2014 18:17:54 -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 2505F11370; Tue, 15 Apr 2014 18:17:53 -0400 (EDT) Message-ID: <534DB00F.5050105@pobox.com> Date: Tue, 15 Apr 2014 15:17:51 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Thomson References: <53456D1B.1010804@alum.mit.edu> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> <534D8157.5070200@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C9DC0CE4-C4EB-11E3-A118-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AJdKMcqRUJ5j-4rAo3wdA_C3uwE Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Apr 2014 22:18:02 -0000 Martin Thomson wrote: > On 15 April 2014 11:58, Michael D'Errico wrote: >> >> Can you please explain why you want things to fail and in what >> circumstances? > > Does HNTP provide an exact replica of the protocol contract that TCP > provides HTTP/2? If not, I want to know. If it is exact in all the > ways that matter, might as well use "h2". If you foresee only ever defining "h2" (meaning secure HTTP2 over TLS) and "h2c" (meaning unsecured HTTP2), then why even mention TCP at all? I'm fine with the proposal if there will only be two different strings that lead to HTTP2 and most protocols need only one identifier. Mike From nobody Tue Apr 15 15:24:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89DD1A0186 for ; Tue, 15 Apr 2014 15:24:17 -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 RW5g3bUZ9YIF for ; Tue, 15 Apr 2014 15:24:16 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 169FC1A011A for ; Tue, 15 Apr 2014 15:24:16 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so10154956pab.13 for ; Tue, 15 Apr 2014 15:24:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yHFvFU8ZyXE4czUdjBKQjZrLiVTphApY5USyBFOAZbs=; b=DU44vka/h7TSMQSngjBaPOLKY5J0DCSMMLTBizC2h50LElGg3ecbCtD/1obXQwamN2 gsxRvZOEZ8CwxQT4+p3f50TYtccBzgrN3TvW5lw4VSeNUbfAIbWmI1NBMhtQtJTTJUQv nJv7N7jVQi+mZ1LXoI7JT0V33cLutLLqd3aNqGzp7EiWRlKTHbMDARbBpmDp56rlc8Yp xRkMZMgMK2gLoUS7jrUYDcaKdQ6mQTmu7uOWCrki4i8/EJqWrOjMDFDuNyF9K7UL08rs qG8nN/6WbY5PH2oyHBg3FUAOXYmismewieo6gdY4dlEMRVlBbX7pnv6lPOYFFJ72Qn8o +a1A== X-Gm-Message-State: ALoCoQmc92md8PpqNp3IE4fnyF4rmj482JgVLknMoDdRy6376OgK09PBuvo1kZfrZsU/goUyRa8G X-Received: by 10.68.135.137 with SMTP id ps9mr4697816pbb.160.1397600653214; Tue, 15 Apr 2014 15:24:13 -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 sv10sm42532985pbc.74.2014.04.15.15.24.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 15:24:12 -0700 (PDT) Message-ID: <534DB18A.4060408@mit.edu> Date: Tue, 15 Apr 2014 15:24:10 -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: Watson Ladd , "Salz, Rich" References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.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/L8Odbh7YHD-RMRK9v9oDLKDH0bw Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 22:24:17 -0000 On 04/14/2014 10:21 PM, Watson Ladd wrote: > Now, the best mechanism I can think off would be to use DNS to preload > a per-IP SNI encryption key, or have the handshake optionally involve > getting one. But I still can't figure out how to authenticate the > gotten key without a lot of complexity. The best solution is for the > client and server to do a DH, then pass the desired website (which > might get you investigated when the initial handshake is intercepted), > and have that cert sign the handled DH, then go back and do a TLS > connection. Ugh. What if it were an opt-in thing? A hypothetical DANE extension could associate with each domain a tuple (ClientHello-protection public key, TLS version guaranteed to be supported). Clients could resolve that essentially for free as long as they're already querying DNS, and this could prevent downgrade attacks and give an efficient way to encrypt the entire ClientHello. Note that there's no reason that the public key in here should have anything to do with the eventual TLS handshake. In fact, I would argue that it should be completely independent, so that large-scale load balancers could strip the encryption off the ClientHello and hand the connection off to something else that knows the real key. As a concrete algorithm, the extra DNS information could be 36 bytes: 34 for ("Curve25519/ElGamal + AES-128-GCM" || "B = b*G") and 2 for "TLS 1.3" in some suitable format. If such a record exists, then the client starts the connection with something like "Encrypted Hello" || a*G || IV || AES-128-GCM(a*B, IV, ClientHello). Arguably, the rest of the handshake should be encrypted with the same key. The only reason I suggested this particular public-key cryptosystem is because it makes it easy to encrypt the reply. There's a weak argument to be made for arranging for the actual encrypted ClientHello to be indistinguishable from random by anyone who doesn't know the private key. This ought to be straightforward using Elligator. Off the top of my head, it sounds cute, but I don't really see a benefit. The TLS version is to prevent this thing from being downgraded away: if the server tries to claim that it only speaks TLS 1.2, but the DNS record said that the server supports TLS 1.3, then the client aborts. This isn't directly per-IP, but a sensible server deployment should use the same exact data in DNS for everything it hosts on the same IP. This adds no round-trips. It costs a few random bytes, two multiplications, and an AEAD invocation on the client, and it costs one multiplication and an AEAD invocation on the server. It adds very little protocol complexity: the encrypted ClientHello is exactly the same thing as a regular ClientHello but with an extra layer of encryption on top. --Andy From nobody Tue Apr 15 17:22: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 D3C761A0065 for ; Tue, 15 Apr 2014 17:22: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 Mu5Aa1QcRsgE for ; Tue, 15 Apr 2014 17:22:08 -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 96F831A0015 for ; Tue, 15 Apr 2014 17:22:08 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so10120628wgg.26 for ; Tue, 15 Apr 2014 17:22: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=TMUVnh5u0x92bOnb5OC9H3Hsr5f+W4y3Jc9+0fZC1Mk=; b=RnVIcErQ36Y1TYgdlumdoqnnp8HIPnYWWp+sIqGC61q36wWholyzug7rhh4GGgG842 ZVaZ7cKM90fn7FAGr9ut4D/0rERm3eptTwM6nSp9wFWnVDQ+4Z6mNkKOxfVwgmvPqqcd liXNaNFenEls0hZPCB/fw3Sr9KC8QEwsADqsI8i61+wxFBMogLDBJ4Svgod9JwNE+yez 1tb2W6E0Y3AwGa+/Ka28h27nDwMU2OIg0xmIw3VjudlaPRBEN7vK3a3xf4lv8Nd4cyOE FIpzQ6leRteBMjV9FqUPA0x6gJxK+QBrhWJBXI50PLAploERi3AjVAz1ij/R5bMXUmO5 kbRg== MIME-Version: 1.0 X-Received: by 10.180.106.198 with SMTP id gw6mr4791430wib.50.1397607725127; Tue, 15 Apr 2014 17:22:05 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 17:22:05 -0700 (PDT) In-Reply-To: <534DB00F.5050105@pobox.com> References: <53456D1B.1010804@alum.mit.edu> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> <534D8157.5070200@pobox.com> <534DB00F.5050105@pobox.com> Date: Tue, 15 Apr 2014 17:22:05 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eJxdIuWEkbsmgoaaPWATUdlyLmw Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 00:22:14 -0000 On 15 April 2014 15:17, Michael D'Errico wrote: > If you foresee only ever defining "h2" (meaning secure HTTP2 over TLS) > and "h2c" (meaning unsecured HTTP2), then why even mention TCP at all? I have no prescient abilities. We do know that TCP is what HTTP/2 uses though. From nobody Tue Apr 15 17:42: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 4DCB91A007F for ; Tue, 15 Apr 2014 17:42:08 -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 2CWX9C15VQ_A for ; Tue, 15 Apr 2014 17:42:07 -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 687911A0088 for ; Tue, 15 Apr 2014 17:42:06 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so10095459wes.18 for ; Tue, 15 Apr 2014 17:42:03 -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=ohuy3o7SeDfb9TN+OOJrY+kDR2xQcxbiBX2V4r6YfJA=; b=DnZU3znA+1BgCic+aVYSkjPHf3WKmAPR3P+vIAV52vknOdGsVsTSiSaPrcqvjSdDdz WXUmwxAkLdJqJvkyr1o+FBQ3LrOdjI1FbyS/ywzAlzb+xxDa5jv+GzUtPwN+wLAemsai dP6WzaqBbOpYQ/NBoIxFAQE+loRRitBBWRf3OWA5XXV/LkkUPVJV/dsPYwfrkMS7xc9d /b7jeRekYTBU2nVHibkyPdIk3iv69ZthDfix4rCMKEql6l+5m/yalP6Q7qzL6+rFDPlW cyt9thYpntuwlXnspXjqJonxuoDtiB+80LnZFtkRRBw7+X1KCJIQLx30lDA4qwJnSH6J rluA== X-Gm-Message-State: ALoCoQl3p7BV1mbM0alOUYuVO0mezlfa6v4sGIL9BIrG371HO4wHPg8PgKHq8rKZQ4MVw9uOoqn2 MIME-Version: 1.0 X-Received: by 10.180.24.72 with SMTP id s8mr16675534wif.20.1397608923014; Tue, 15 Apr 2014 17:42:03 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Tue, 15 Apr 2014 17:42:02 -0700 (PDT) X-Originating-IP: [166.137.177.116] In-Reply-To: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> Date: Tue, 15 Apr 2014 17:42:02 -0700 Message-ID: From: Trevor Perrin To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ez0qfU74LXqbIYWnzEXYoXCz_pg Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 00:42:08 -0000 On Tue, Apr 15, 2014 at 12:49 PM, Yoav Nir wrote: > You have listed several cases of failed competitions, and IPsecME can provide two others. Hi Cullen and Yoav - most of your examples seem like evidence that: (a) performing major protocol design in the IETF is very hard, and often fails (b) WGs sometimes reach irreconciliable differences Having multiple competing proposals seems like a symptom of these problems much more than a cause. Trevor From nobody Tue Apr 15 17:46: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 5ABB21A0090 for ; Tue, 15 Apr 2014 17:46:28 -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 a4Q0ApMK5aDT for ; Tue, 15 Apr 2014 17:46:24 -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 2D48B1A008F for ; Tue, 15 Apr 2014 17:46:21 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so613763wib.11 for ; Tue, 15 Apr 2014 17:46: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=JM+BKM/KrKX9MHqYRvVZIL5cd78YiUsTD8GDUiL7AUM=; b=bkjNn4ls0Jc2LavIZUNZE9J5DqbJaqK2WEC90rb7fd7G5MyPOmI892WS5We4+uScYu QHq86ltH/R03Jl6F/iXEPoxC6WNZFgOxK5VRSWQ/vgIx5axdP9g5l/8bP/mmJfWO1C53 aCH543WQZusYFxjIWka+EAaoXPhCl+e/hsvFAcTBj2X7wP8F3fTZhsIwy55jGPzOZIFq 0+70NRwAg68JjEwlDNXJVcFC+vHSxugO0tpr2ccMnUb62olLCylnPESLvt3dqrJ8rDQN OBR+keUv28kjXGAsERNoKBFqbdBB4YPnAdWeK6XFjOU9Z0ItRIaGBWRwFEJ3+iioP+we 0NQw== X-Gm-Message-State: ALoCoQkVoRBOr5ipCkvR2S9O4P4IOVe2I7INNs6HRZWmhmE+kS+iJjQrJXRSekkoyKhIXyceIH2E MIME-Version: 1.0 X-Received: by 10.194.185.148 with SMTP id fc20mr4123306wjc.27.1397609177823; Tue, 15 Apr 2014 17:46:17 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Tue, 15 Apr 2014 17:46:17 -0700 (PDT) X-Originating-IP: [166.137.177.116] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> Date: Tue, 15 Apr 2014 17:46:17 -0700 Message-ID: From: Trevor Perrin To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qlyXfwd8YXhzkn81IrFiLNe4BJc Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 00:46:28 -0000 On Tue, Apr 15, 2014 at 1:28 PM, Salz, Rich wrote: > > I'm opposed to a bakeoff. It doesn't seem like a "standard" bakeoff, in > which we bring existing implementations of mostly-done specs. Others have > commented on the history. This seems more like a spec bake-off, which isn't > really a bake-off but more of a competition. How does that get better code > out there? Rough consensus and running code is the phrase, and I don't see > a competition to create TLS2 as a way to get a "better" TLS in the hands of > consumers during 2014. > > And, if we got rid of the SNI encryption :) the number of changes being > considered is pretty small in both number and scope. So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3 that completes quickly and with small changes to TLS 1.2. Maybe this argues for Adam Langley's earlier suggestion (also endorsed by a few others) that we focus on a TLS 1.3 that is a "tidying up" of 1.2, and push the larger goals (e.g. redesigning handshake for lower-latency or more encryption) to a TLS 2.0? Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg11691.html From nobody Tue Apr 15 18:11: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 CEE8B1A00AF for ; Tue, 15 Apr 2014 18:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtKAMszB_2TD for ; Tue, 15 Apr 2014 18:11:07 -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 346231A00AE for ; Tue, 15 Apr 2014 18:11:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 99154119E5; Tue, 15 Apr 2014 21:11:03 -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=NDAhNGdQy7Ub jmugNFE8dO5nK/0=; b=BDed7hw0WRe7R3kgnAXnRp5geDm1k+2eWTB2NBkRDBZp VbUKxOehKm4PSgyvZNGj3uhvpIvctfXypuHdA6GeKKBolCeU8HyWvBhaI4eP72sf j5Z3D/FqcmnUHcQgb9oY2joZRNoowhkOa3GX79GdrcWqpdif2RJXDjyVRiQW12U= 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=ZFhJ23 KhsZILT7sb8dRr3mn27RFtRzOUkeXZ6RJdiAoa6Oun5guZDLqWulP0tMclyOvgtv CRFSP3mPABEzLHrWPmqpuMjAqkbuqxD0ba30B/HWNXiijWwjvCXhbkC4FP8+T6Q5 jAOyihqNZmMXDDirXoi4NEHv13cmiDESwQww4= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 92240119E4; Tue, 15 Apr 2014 21:11:03 -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 1DC86119E3; Tue, 15 Apr 2014 21:11:02 -0400 (EDT) Message-ID: <534DD8A5.8050202@pobox.com> Date: Tue, 15 Apr 2014 18:11:01 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Thomson References: <53456D1B.1010804@alum.mit.edu> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> <534D8157.5070200@pobox.com> <534DB00F.5050105@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FA1B71AC-C503-11E3-A1D2-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bmPW1bXfPNodU0DmKScwqyNR_RY Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 01:11:14 -0000 Martin Thomson wrote: > On 15 April 2014 15:17, Michael D'Errico wrote: >> If you foresee only ever defining "h2" (meaning secure HTTP2 over TLS) >> and "h2c" (meaning unsecured HTTP2), then why even mention TCP at all? > > I have no prescient abilities. We do know that TCP is what HTTP/2 uses though. What I'm trying to understand is the need to mention TCP at all since there is nothing about HTTP (that I'm aware of) which requires TCP specifically, other than its guarantees of reliability and in-order delivery, a.k.a. a stream. Can't we just have "HTTP/2 with TLS" and "HTTP/2 without TLS" and know that the underlying transport is a stream in both cases (possibly TCP, possibly something else)? Mike From nobody Tue Apr 15 18:19: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 55DA61A0034 for ; Tue, 15 Apr 2014 18:19:11 -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_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_17=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 svXbJv2sqRK7 for ; Tue, 15 Apr 2014 18:19:09 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 96D191A000F for ; Tue, 15 Apr 2014 18:19:09 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id z6so10120992yhz.21 for ; Tue, 15 Apr 2014 18: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:content-transfer-encoding; bh=HyDZTmQ63lBqQWmrqCjzdZ079N4hk0DRkLQGXF8J0nY=; b=WjP5jOJdmSCL4skthNPvjfT7dcgLGdyGDkgFJT3dIvjKgWgs08iFTpdOEs4m6bxU7B XdQG7ZRGQczpUkIZ1H7ArgnTGQD8O+tbLxjbpow/mxmqK8FnHVxk4mLK9jXmjqZKVE7Z rDOFDspiT98nd2yymxDY8F/0B5BYmdc5u+7Fr4cWpHB3/sQ+DaFWbwAArGA8VtUoJsX+ Kl04bWMm2WOQ7o6V/K8OJzRX1peI1k2RSMx9LFg8oWmfS11WxLljIBaUyCLmABJfUoB6 B9IfMLP+XtIa6jkLHIcIolhXeljCJN7UOA0cY1ybxYspuVNyxJyN9mjM0Bg0FhwVt42+ M2KQ== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr7870736yhn.87.1397611146425; Tue, 15 Apr 2014 18:19:06 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 15 Apr 2014 18:19:06 -0700 (PDT) In-Reply-To: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> Date: Tue, 15 Apr 2014 18:19:06 -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/EbE95Z8CuHhKF7m9JsQhrdGV8bo Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 01:19:11 -0000 On Tue, Apr 15, 2014 at 12:49 PM, Yoav Nir wrote: > Hi Cullen > > You have listed several cases of failed competitions, and IPsecME can pro= vide two others. OTOH we have the shining example of httpbis, although I th= ink the two things that made that effort a success was that (a) the proposa= ls were not all that different from each other, and (b) everyone in the roo= m and on the mailing list preferred getting to work on some solution rather= than debating endlessly. That last one was missing from many of the other = efforts. > > But anyway, the only proposal we have for TLS 1.3 is the diagrams in Eric= =E2=80=99s draft. A lot of people say they want a competition. But this is = the IETF. Anyone can submit a draft if they want to. If any of these people= submitted a 5-page draft outlining what they think the next TLS should loo= k like, we would discuss and compare the two options regardless of whether = the chairs and ADs want to have a competition or not. So far, nobody=E2=80= =99s come forward. So we=E2=80=99re all talking about some hypothetical alt= ernate TLS protocol. AGL submitted at one-sentence description: "TLS 1.2 cleaned up with necessary extensions". Enumerate the RFCs that describe what chrome does, and you have running code as well. Peter Gutmann "Take a key exchange, serialize the messages, be done with it= ". As an application of this principle, I suggest the following: Pick a group and hash function and AEAD scheme A->B: ver_cur, ver_high_a, g^a, g^x, {optional sig g^a and cert a} B->A: ver_cur, ver_high_b, g^b, g^y, sig g^b and cert a Abort if ver_cur is not min{ver_high_a, ver_high_b}. This provides extensibility as cryptanalysis proceeds. Compute a key as H(message 1 || message 2|| g^{xy} || g^{ay} || g^{bx}). Then use the AEAD scheme with A taking nonces ending in 1 and B with nonces ending in 0. use the associated data to indicate message ending. Dan Brown suggested the above with HMQV, which Hugo Kraczyk recommends. (But sadly HMQV is patented by IBM) Any of these could be turned into a 5 page ID completely describing the desired effect. But this isn't the question motivating the desire for a competition. Fundamentally the question is this: Why will Eric Rescorla do correctly this time what he failed to do correctly twice before? When did the same leadership that permitted the phrase "but this timing difference is not believed to be exploitable" to appear in a standards document suddenly develop the ability and the will to ensure secure protocols are actually secure? Oh, and RC4 was broken in 2001 by the current head of the CFRG. The desire from a competition stems from wanting authors who don't have this history of failure to be the ones who write the next TLS. Behind all of the debate over the TLS process is a theological dispute: Calvinism vs. Catholicism. On the Calvinist side are those who believe that man's efforts are inherently flawed and worthless, that one's best intentions and conduct can be utterly disregarded by the universe, that will determine if your protocol is secure or not. Nothing can change what is or is not secure: one can only hope, through the science of mathematics, that one has eliminated every known flaw and reduced the problem to one that has never been attacked. When Claus Diem publishes a paper, he has revealed what has always existed, and merely escaped our notice. On the Catholic side are those who believe that the universe smiles upon cryptographers, that there is a redemptive power that can make a flawed protocol whole again, that the flaws in protocols are an inherent fact of human activity that can be fixed by simply redoing it as the last one was, and hoping for a different outcome. One should not be overly concerned by weaknesses or the need for analysis: we simply have never been exploited this way, and so have ample time to change should it be necessary. Minor flaws are after all minor, and all will be forgiven. Sadly the lives and property lost in this holy war are not those of zealots, but of ordinary users whose simple demand: "ensure that my communications are not intercepted" has gone unmet. What should be a sine qua non of this group appears only as an afterthought to a single point "The aim is also to maintain current security features." One can only hope for a mass baptism in Denver. Sincerely, Watson Ladd > 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 Tue Apr 15 19:15: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 F170B1A00BF for ; Tue, 15 Apr 2014 19:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQQX3ol7BaDg for ; Tue, 15 Apr 2014 19:15:33 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB7F1A0034 for ; Tue, 15 Apr 2014 19:15:33 -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 s3G2FTuP029063; Tue, 15 Apr 2014 19:15:29 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1k8s29wa29-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 19:15:29 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 15 Apr 2014 19:15:27 -0700 From: Paul Lambert To: Douglas Stebila , Trevor Perrin Date: Tue, 15 Apr 2014 19:15:50 -0700 Thread-Topic: [TLS] TLS process thread Thread-Index: Ac9ZGbsQEeTyPKxbQKGHgF3LrDjG/g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-15_04:2014-04-15,2014-04-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404160035 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-9-RLoNNhr_4u6mqgmgrZGO3PIk Cc: "tls@ietf.org" Subject: Re: [TLS] TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 02:15:38 -0000 On 4/15/14, 1:06 AM, "Douglas Stebila" wrote: >On 2014/04/15, at 17:55, Trevor Perrin wrote: > >> * Nikos, myself, Peter Gutmann, Watson, and Daniel Kahn Gillmor >> expressed interest in soliciting multiple proposals [10,11,12,13]. > >+1 +1 Multiple proposals would be valuable. It would also be important to have proposals briefly describe unique use cases and requirements. =20 There seem to be some conflicting use cases that need clarification as part of the process. Paul >=20 > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 15 20:51: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 D1BBA1A006F for ; Tue, 15 Apr 2014 20:51:14 -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 AV_3WtzSiHOr for ; Tue, 15 Apr 2014 20:51:10 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92B1A0022 for ; Tue, 15 Apr 2014 20:51:10 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so10129032wes.25 for ; Tue, 15 Apr 2014 20:51: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Kc+JJQxif7bg+xVkB3hnd8vHufa8wtt9NYl5EMrd0yg=; b=fCZcpkwVyH+lwzRS7zZl7s7OgMzwNgi7IFs9sVhbS+nwo+jJzvzIHzY/O83Edeghtm tNtW8KKKcuMfx1NS5pFUySlbXy61B3OD+WketwBb2x1/UeF8IlQ+hfQ9eIiXnikM98CH 8IDTdsVk5CnypNslt50pvLdWIqRtn4Um60QyKyttP8M1P+ZUAmv/4u/k8uanroTqXwS/ tfFRy580Oaoh3syx779fSmuFxC4x0uuvqpyyYYWOdSu3ETdb4uiN+p/zwBVVUAA48TTf 9xfQhmDKETtRFXt6XZHJo3SB4v5eIIwPZAt+2HOTVUKj+wgKASjnOuiC1jFVGSXKmPhz 4uLw== X-Gm-Message-State: ALoCoQk9WTU7MNeTPEyr8lDA27goRoqdMutU/HGAkPBdTSm7IlF5Va8GXdTbmKtajnUpoKsu6KpN X-Received: by 10.180.90.140 with SMTP id bw12mr5399126wib.18.1397620266783; Tue, 15 Apr 2014 20:51:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 15 Apr 2014 20:50:26 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <534DB18A.4060408@mit.edu> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Eric Rescorla Date: Tue, 15 Apr 2014 20:50:26 -0700 Message-ID: To: Andy Lutomirski Content-Type: multipart/alternative; boundary=f46d043c811a88717904f720d342 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/b-9xzdtSI6kkQS2xd_y3Gs2OKHg Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 03:51:15 -0000 --f46d043c811a88717904f720d342 Content-Type: text/plain; charset=ISO-8859-1 Andy, This is an interesting idea and as you say, it has the virtue that it doesn't require messing with the state machine at all. I have a few comments: 1. You probably have to frame this as a ClientHello with some opaque extensions which happen to be encrypted. The reason for this is that there are stateful inspection devices which examine data on port 443 and enforce that it looks like TLS. As these devices are associated with the client not the server, the server's TLS 1.3 compatibility does not guarantee that the client will in fact be able to send a non-TLS framed ClientHello. 2. It might (or might not) be easier to frame the advertised information as a TLS cipher suite. 3. This only prevents downgrade attacks if the information is secured via DNSSEC. There are intermediate elements which damage enough of the DNS resolution process that they will cause DNS signature failures even when the client knows that the records are supposed to be signed. Hard-failing in these cases will likely result in unacceptably high failure rates, but if you don't hard fail, then a network-based downgrade to unencrypted SNI is possible. More generally, I note that a number of the suggestions that people have provided here (yours, Watson's Rich's, my modification of Rich's) have the common factor that they require the server to opt-in in some way. This has the major advantage that it allows us to design a mechanism which might be inconvenient for some network environments because they can just not opt-in, as well as allowing out-of-band delivery of some data in the DNS. The disadvantage seems to be that a smaller fraction of sites will offer encrypted SNI, which slightly paints a target on them. I think that's probably OK, since no matter what mechanism we use for encrypted SNI, it seems likely that an attacker will be able to get a good handle on the virtual hosts served by a given site, and so can use that to identify which sites he is interested in tracking even if everyone were to use encrypted SNI. However, it's worth considering and I'd love to hear from people who want encrypted SNI what they think of this tradeoff. -Ekr On Tue, Apr 15, 2014 at 3:24 PM, Andy Lutomirski wrote: > On 04/14/2014 10:21 PM, Watson Ladd wrote: > > Now, the best mechanism I can think off would be to use DNS to preload > > a per-IP SNI encryption key, or have the handshake optionally involve > > getting one. But I still can't figure out how to authenticate the > > gotten key without a lot of complexity. The best solution is for the > > client and server to do a DH, then pass the desired website (which > > might get you investigated when the initial handshake is intercepted), > > and have that cert sign the handled DH, then go back and do a TLS > > connection. Ugh. > > What if it were an opt-in thing? A hypothetical DANE extension could > associate with each domain a tuple (ClientHello-protection public key, > TLS version guaranteed to be supported). Clients could resolve that > essentially for free as long as they're already querying DNS, and this > could prevent downgrade attacks and give an efficient way to encrypt the > entire ClientHello. > > Note that there's no reason that the public key in here should have > anything to do with the eventual TLS handshake. In fact, I would argue > that it should be completely independent, so that large-scale load > balancers could strip the encryption off the ClientHello and hand the > connection off to something else that knows the real key. > > As a concrete algorithm, the extra DNS information could be 36 bytes: 34 > for ("Curve25519/ElGamal + AES-128-GCM" || "B = b*G") and 2 for "TLS > 1.3" in some suitable format. If such a record exists, then the client > starts the connection with something like "Encrypted Hello" || a*G || IV > || AES-128-GCM(a*B, IV, ClientHello). > > Arguably, the rest of the handshake should be encrypted with the same > key. The only reason I suggested this particular public-key > cryptosystem is because it makes it easy to encrypt the reply. > > There's a weak argument to be made for arranging for the actual > encrypted ClientHello to be indistinguishable from random by anyone who > doesn't know the private key. This ought to be straightforward using > Elligator. Off the top of my head, it sounds cute, but I don't really > see a benefit. > > The TLS version is to prevent this thing from being downgraded away: if > the server tries to claim that it only speaks TLS 1.2, but the DNS > record said that the server supports TLS 1.3, then the client aborts. > > This isn't directly per-IP, but a sensible server deployment should use > the same exact data in DNS for everything it hosts on the same IP. > > This adds no round-trips. It costs a few random bytes, two > multiplications, and an AEAD invocation on the client, and it costs one > multiplication and an AEAD invocation on the server. > > It adds very little protocol complexity: the encrypted ClientHello is > exactly the same thing as a regular ClientHello but with an extra layer > of encryption on top. > > --Andy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c811a88717904f720d342 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy,

This is an interesting idea and a= s you say, it has the virtue that it
doesn't require messing = with the state machine at all. I have a few
comments:

1. You probably have to frame this as a ClientHello with som= e
opaque extensions which happen to be encrypted. The reason for
this is that there are stateful inspection devices which examine
data on port 443 and enforce that it looks like TLS. As these
devices are associated with the client not the server, the server's
TLS 1.3 compatibility does not guarantee that the client will
<= div>in fact be able to send a non-TLS framed ClientHello.

2. It might (or might not) be easier to frame the advertised inf= ormation
as a TLS cipher suite.

3. T= his only prevents downgrade attacks if the information
is secured= via DNSSEC. There are intermediate elements which
damage enough of the DNS resolution process that they will
c= ause DNS signature failures even when the client knows that
the r= ecords are supposed to be signed. Hard-failing in these
cases wil= l likely result in unacceptably high failure rates, but
if you don't hard fail, then a network-based downgrade to
unencrypted SNI is possible.


More= generally, I note that a number of the suggestions that people
have provided here (yours, Watson's Rich's, my modification of Rich= 's)
have the common factor that they require the server to op= t-in in some
way. This has the major advantage that it allows us = to design a
mechanism which might be inconvenient for some network environments
because they can just not opt-in, as well as allowing out-of-band
delivery of some data in the DNS.

The dis= advantage seems to be that a smaller fraction of sites will offer encrypted= SNI, which slightly paints
a target on them. I think that's probably OK, since no matter what= mechanism
we use for encrypted SNI, it seems likely that an atta= cker will be able to
get a good handle on the virtual hosts serve= d by a given site, and so
can use that to identify which sites he is interested in tracking even= if
everyone were to use encrypted SNI. However, it's worth c= onsidering
and I'd love to hear from people who want encrypte= d SNI what they
think of this tradeoff.

-Ekr









On Tue,= Apr 15, 2014 at 3:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
On 04/14/2014 10:21 PM, Wats= on Ladd wrote:
> Now, the best mechanism I can think off would be to use DNS to preload=
> a per-IP SNI encryption key, or have the handshake optionally involve<= br> > getting one. But I still can't figure out how to authenticate the<= br> > gotten key without a lot of complexity. The best solution is for the > client and server to do a DH, then pass the desired website (which
> might get you investigated when the initial handshake is intercepted),=
> and have that cert sign the handled DH, then go back and do a TLS
> connection. Ugh.

What if it were an opt-in thing? =A0A hypothetical DANE extension cou= ld
associate with each domain a tuple (ClientHello-protection public key,
TLS version guaranteed to be supported). =A0Clients could resolve that
essentially for free as long as they're already querying DNS, and this<= br> could prevent downgrade attacks and give an efficient way to encrypt the entire ClientHello.

Note that there's no reason that the public key in here should have
anything to do with the eventual TLS handshake. =A0In fact, I would argue that it should be completely independent, so that large-scale load
balancers could strip the encryption off the ClientHello and hand the
connection off to something else that knows the real key.

As a concrete algorithm, the extra DNS information could be 36 bytes: 34 for ("Curve25519/ElGamal + AES-128-GCM" || "B =3D b*G")= and 2 for "TLS
1.3" in some suitable format. =A0If such a record exists, then the cli= ent
starts the connection with something like "Encrypted Hello" || a*= G || IV
|| AES-128-GCM(a*B, IV, ClientHello).

Arguably, the rest of the handshake should be encrypted with the same
key. =A0The only reason I suggested this particular public-key
cryptosystem is because it makes it easy to encrypt the reply.

There's a weak argument to be made for arranging for the actual
encrypted ClientHello to be indistinguishable from random by anyone who
doesn't know the private key. =A0This ought to be straightforward using=
Elligator. =A0Off the top of my head, it sounds cute, but I don't reall= y
see a benefit.

The TLS version is to prevent this thing from being downgraded away: if
the server tries to claim that it only speaks TLS 1.2, but the DNS
record said that the server supports TLS 1.3, then the client aborts.

This isn't directly per-IP, but a sensible server deployment should use=
the same exact data in DNS for everything it hosts on the same IP.

This adds no round-trips. =A0It costs a few random bytes, two
multiplications, and an AEAD invocation on the client, and it costs one
multiplication and an AEAD invocation on the server.

It adds very little protocol complexity: the encrypted ClientHello is
exactly the same thing as a regular ClientHello but with an extra layer
of encryption on top.

--Andy

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

--f46d043c811a88717904f720d342-- From nobody Tue Apr 15 22:32: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 37FFF1A001C for ; Tue, 15 Apr 2014 22:32: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 OL4IsZbYGlgM for ; Tue, 15 Apr 2014 22:32:24 -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 2A13B1A003A for ; Tue, 15 Apr 2014 22:32:17 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so10191500wes.25 for ; Tue, 15 Apr 2014 22:32: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=Ob1JwoCAwrYiMqL/YF7R0NxoIMd2DDgNmYqucpPO7sM=; b=qYZtIJDAhbeu2NNTBppby9CQLBqiq+daCXhJYYWfh5ttIn4wL+ugeKU1cMKaulVbOP wceEe9RvcVn4dOSazyU2BYsULYRBJsNhIaghJ6RF+EpNvmZrX9fxa1ExNyko+cRa5TsB VEt8LHEMHe3tNyGPKtBUx+wkGcgfy8lfOhrySPK3JF2jVXSQjcTbCxeYzE+AJjks5QTv KHvW4+VMzK64N4BYmRUY/u/5mfPC4mz3+BhjMVUuYQPzPvBC9HyNNdDg/gBFpxBEAlqz A9kD7d/jjV7p7XQ32yxS6Unpy+85OXyPyG5FlQhV1cPT3xZTKTV9qJwnDD8unTgHf3wv 3pLQ== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr5611022wic.58.1397626334582; Tue, 15 Apr 2014 22:32:14 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Tue, 15 Apr 2014 22:32:14 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> Date: Tue, 15 Apr 2014 22:32:14 -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/9X1UdMzgZ4BWeO4z8k8WCt7w54U Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 05:32:26 -0000 On 15 April 2014 17:46, Trevor Perrin wrote: > > So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3 > that completes quickly and with small changes to TLS 1.2. That's a not quite accurate reinterpretation of my statements. My position is that TLS 1.3 should meet its chartered goals as expediently as possible. Depending on the answers to certain questions (like the SNI question), that might involve small changes to 1.2 or it might be big. Arguably, completely changing the record layer as we've essentially agreed is a big change, so we're already there. Mostly, I don't care about the size of the changes, but more that they are all justified and justifiable. From nobody Tue Apr 15 22: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 9BE831A003A for ; Tue, 15 Apr 2014 22:35:06 -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 6U2_QNHuBeU1 for ; Tue, 15 Apr 2014 22:35:05 -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 A83321A001C for ; Tue, 15 Apr 2014 22:35:04 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c13so8376575eek.38 for ; Tue, 15 Apr 2014 22:35:00 -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=pT4QoxCO11HoKR8IzUqH9bQS5TA/5kXmhlR6SUdjqgc=; b=RNUwkmAaZu0BuFGgB1bMI9jTKrY+BqJq/wU1H8cbERMxr3LvX9oJjImShzS1zUXnss yAm/tsc6lTZuEggeqaykjAYkH76C+MQpk/cbTMwPSZcRmf4fCZTiRYb2iURpBLYgLTZi NVxLcRGBB0p8U5Wi2UlVhW2UJKtkER3zDi+KOXMeLxve80jmPNdEOZOfmcU8IfnVorjr DT8S7RTC5hFUyEr/haNdiU9/jUOyMHt/6b4i64pTY0kn4buySBl6jTqcLCGCwiRvfuBC UT4FdQkkJEuqFIRyhkLiB9olm2wt8dHTGmAvWYUbKBMO0D+Ui9hepVGwo7y5dyxDETcy nDjg== X-Received: by 10.15.35.66 with SMTP id f42mr2250203eev.93.1397626500879; Tue, 15 Apr 2014 22:35:00 -0700 (PDT) Received: from [10.4.20.26] ([80.179.9.115]) by mx.google.com with ESMTPSA id 44sm54657099eek.30.2014.04.15.22.34.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Apr 2014 22:35: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: Date: Wed, 16 Apr 2014 08:29:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <04AAC0B4-58E9-4EC7-8B57-F952438DE0A7@gmail.com> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NM_O5KDsjwvWl3YwnEhgRdaAzxc Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 05:35:06 -0000 On Apr 16, 2014, at 3:42 AM, Trevor Perrin wrote: > On Tue, Apr 15, 2014 at 12:49 PM, Yoav Nir = wrote: >> You have listed several cases of failed competitions, and IPsecME can = provide two others. >=20 > Hi Cullen and Yoav - most of your examples seem like evidence that: > (a) performing major protocol design in the IETF is very hard, and = often fails > (b) WGs sometimes reach irreconciliable differences The normal process is a 2-hour meeting three times a year, plus long = debates on the mailing list. This lends itself to someone (or a small = group) coming up with a design, and then lots of people analyzing, = criticizing, and suggesting changes. This works OK if the design is = acceptable to almost everybody and if the editors have the energy and = attention to keep the thing going. That works well for HTTP/2 because we = have an energized and responsive team of authors, and the changes being = suggested are not that profound anymore. If the authors have less time = and energy and are less responsive, you get HPKP. With more profound differences, making decisions over email is pretty = hard. Face-2-face meetings may help, as TLS is going to have next month, = in that there are many more hours for discussion.=20 > Having multiple competing proposals seems like a symptom of these > problems much more than a cause. Or at least an unwillingness or inability for the designers to reach a = common agreement. If there are multiple competing proposals, and the = authors won=92t choose or combine, it is folly to expect a mailing list = to make that decision or combination for them. It is also instructive that when NIST has an algorithm competition, it = takes them six years. The IETF doesn=92t have that kind of attention = span. If TLS 1.3 gets published in 2020, we will consider this a failure = regardless of how great it is. Yoav From nobody Tue Apr 15 22:36: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 05D211A0049 for ; Tue, 15 Apr 2014 22:36:51 -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 zbb3_8GcdZra for ; Tue, 15 Apr 2014 22:36:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A31A003D for ; Tue, 15 Apr 2014 22:36:48 -0700 (PDT) Received: from sjc-vpn5-1633.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E878A22E1F4; Wed, 16 Apr 2014 01:36:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: Date: Tue, 15 Apr 2014 22:37:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60D684B8-80C5-411A-B059-26C60EA6C37B@iii.ca> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/reVDwtikcXOY_dCZdE-GMvb2m1A Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 05:36:51 -0000 On Apr 15, 2014, at 5:46 PM, Trevor Perrin wrote: >=20 > So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3 > that completes quickly and with small changes to TLS 1.2. I thinking I was suggesting that this WG should incrementally evolve TLS = and if someone wants to make a clean slate design that is more of a = revolution than an evolution, they are welcome to do that by forming = some other WG.=20 From nobody Tue Apr 15 22:36: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 9EC911A0049 for ; Tue, 15 Apr 2014 22:36: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_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 hzmR9cAwyKO2 for ; Tue, 15 Apr 2014 22:36:51 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 61F381A003D for ; Tue, 15 Apr 2014 22:36:51 -0700 (PDT) Received: from sjc-vpn5-1633.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6ADBB22E1FA; Wed, 16 Apr 2014 01:36:47 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: Date: Tue, 15 Apr 2014 22:37:57 -0700 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/70ziCi6jTJ7Jw05j7n3L_NMhIGc Cc: tls@ietf.org Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 05:36:52 -0000 On Apr 15, 2014, at 10:00 AM, Watson Ladd wrote: > TLS right now doesn't work. Wow - we have some different points of view that I doubt I will ever = really agree on similar solutions. I view TLS as probably the most = successful security protocol ever and incredibly important. It is what = works today for a huge number of deployed products, services and users. = You are wrong that bake-offs lead to simple design but our points of = views are so different I am not really interested in discussing that.=20 I suspect the folks that want to design something new should just grab = an email list that is not the TLS email list and go design something new = and propose it to the IETF. The charter of TLS does *not* say that other = WG can=92t go and do a different protocols that solve a similar set of = problem.= From nobody Tue Apr 15 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 981E21A005F for ; Tue, 15 Apr 2014 23:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6HmC4UGGEAt for ; Tue, 15 Apr 2014 23:14:01 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id C35A31A0012 for ; Tue, 15 Apr 2014 23:13:47 -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 s3G6DhKW027955; Tue, 15 Apr 2014 23:13:43 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1k9hw0r921-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Apr 2014 23:13:42 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Tue, 15 Apr 2014 23:13:42 -0700 From: Paul Lambert To: Yoav Nir , Trevor Perrin Date: Tue, 15 Apr 2014 23:14:06 -0700 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9ZOwQdFCcPF8pNTDudmFeq+PGeOw== Message-ID: References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> <04AAC0B4-58E9-4EC7-8B57-F952438DE0A7@gmail.com> In-Reply-To: <04AAC0B4-58E9-4EC7-8B57-F952438DE0A7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-16_01:2014-04-15,2014-04-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404160080 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oAunw4U8qmQi3c2beXOwrN2sixw Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 06:14:05 -0000 On 4/15/14, 10:29 PM, "Yoav Nir" wrote: > >On Apr 16, 2014, at 3:42 AM, Trevor Perrin wrote: > >> On Tue, Apr 15, 2014 at 12:49 PM, Yoav Nir wrote: >>> You have listed several cases of failed competitions, and IPsecME can >>>provide two others. >>=20 >> Hi Cullen and Yoav - most of your examples seem like evidence that: >> (a) performing major protocol design in the IETF is very hard, and >>often fails >> (b) WGs sometimes reach irreconciliable differences Having worked in many different forums creating protocols =8A I do agree that the IETF process is often dysfunctional. However, I do not see why we consider the supposed process on this list as a limitation. A good design is never by a committee or mailing list, but instead by a small design team that works closely together to create a quality specification. Creating a specification should not be by the random walk of the full mailing list. > >The normal process is a 2-hour meeting three times a year, plus long >debates on the mailing list. This lends itself to someone (or a small >group) coming up with a design, and then lots of people analyzing, >criticizing, and suggesting changes. This works OK if the design is >acceptable to almost everybody and if the editors have the energy and >attention to keep the thing going. That works well for HTTP/2 because we >have an energized and responsive team of authors, and the changes being >suggested are not that profound anymore. If the authors have less time >and energy and are less responsive, you get HPKP. > >With more profound differences, making decisions over email is pretty >hard. Face-2-face meetings may help, as TLS is going to have next month, >in that there are many more hours for discussion. > >> Having multiple competing proposals seems like a symptom of these >> problems much more than a cause. > >Or at least an unwillingness or inability for the designers to reach a >common agreement. If there are multiple competing proposals, and the >authors won=B9t choose or combine, it is folly to expect a mailing list to >make that decision or combination for them. A group document produced by an editor is not the same as a contribution from an =B3author=B2 (e.g ugly history of ISAKMP versus IKE). Clarity of goals and guidelines for cooperation of bake-off participants is essential. Much of the problem in the IETF is vanity ownership - getting your name on the RFC versus having a quality group document. > >It is also instructive that when NIST has an algorithm competition, it >takes them six years. The IETF doesn=B9t have that kind of attention span. >If TLS 1.3 gets published in 2020, we will consider this a failure >regardless of how great it is. NIST has no motivation or charter to move rapidly to deliver stronger cryptographic algorithms to industry. The =B3bake-offs=B2 I=B9m exposed to in other standards groups are complete= d in less than 6 months. It helps to start with a clear common set of requirements. =20 Paul > >Yoav > > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 15 23:31: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 481171A006B for ; Tue, 15 Apr 2014 23:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2URHQN_ex3bj for ; Tue, 15 Apr 2014 23:31:03 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54E1A008A for ; Tue, 15 Apr 2014 23:31:03 -0700 (PDT) Received: from [10.182.153.233] (85-76-69-207-nat.elisa-mobile.fi [85.76.69.207]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id E509F2007B; Wed, 16 Apr 2014 09:30:54 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Wed, 16 Apr 2014 09:30:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> To: Watson Ladd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gcz9752v5DtX679dSehDduwjpTs Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 06:31:05 -0000 > On 16.4.2014, at 4.19, Watson Ladd wrote: >=20 > Fundamentally the question is this: Why will Eric Rescorla do > correctly this time what he failed to do correctly twice before? When I don't think these personal attacks really lead anywhere, it might be bette= r to tone it down. I'm saying this because I've criticised this WG as well, b= ut from my point of view the WG works really well now and everyone takes par= t in the discussion equally. There's been a huge improvement already. > current head of the CFRG. The desire from a competition stems from > wanting authors who don't have this history of failure to be the ones > who write the next TLS. I like the idea of a TLS-like protocol designed from scratch. However, as ha= s already been said, you don't need a competition for that. Anyone can send t= heir proposal for TLS 2.0 today if they wish. I'd be interested to see some,= but so far there has been no proposals. > Sadly the lives and property lost in this holy war are not those of > zealots, but of ordinary users whose simple demand: "ensure that my > communications are not intercepted" has gone unmet. As I see it, most people on this list are ordinary users with that simple de= mand. I simply don't see this holy war you speak of, and I hope it's not jus= t me who doesn't. > One can only hope for a mass baptism in Denver. Personally, I would keep baptism and security protocols quite far from each o= ther, even on a metaphorical level. Juho From nobody Wed Apr 16 00:56: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 BD0E71A0087 for ; Wed, 16 Apr 2014 00:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.174 X-Spam-Level: X-Spam-Status: No, score=-4.174 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 KqLlt3Ux3eAy for ; Wed, 16 Apr 2014 00:55:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id B40191A00E4 for ; Wed, 16 Apr 2014 00:55:49 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3G7tkkB014035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Apr 2014 03:55:46 -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 s3G7ti7l028309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Apr 2014 03:55:45 -0400 Message-ID: <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Juho =?ISO-8859-1?Q?V=E4h=E4-Herttua?= Date: Wed, 16 Apr 2014 09:55:43 +0200 In-Reply-To: References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.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/BO7NNf4e4a0qgwFh6RLZO1Cfc-A Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 07:55:52 -0000 On Wed, 2014-04-16 at 09:30 +0300, Juho Vähä-Herttua wrote: > > current head of the CFRG. The desire from a competition stems from > > wanting authors who don't have this history of failure to be the ones > > who write the next TLS. I like the idea of a TLS-like protocol designed > from scratch. However, as has already been said, you don't need a > competition for that. Anyone can send their proposal for TLS 2.0 today > if they wish. I'd be interested to see some, but so far there has been > no proposals. And there will be none unless there is call for proposals. Do you really expect any university or industry group to spend significant time and money to prepare a proposal for a TLS update, that will be submitted "just in case someone may check it?". Especially when the chairs have openly opposed any such approach. This is a significant investment, that would require e.g., universities to justify to their funding agencies the reasons of their spending. Very few people will accept reasoning like "we spent a year designing a TLS update just in case". Comments like that, that anyone can submit a TLS 2.0 protocol design are really misleading. regards, Nikos From nobody Wed Apr 16 03:09: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 141D21A0116 for ; Wed, 16 Apr 2014 03:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByouCyu3a6U3 for ; Wed, 16 Apr 2014 03:09:39 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id E47A51A010E for ; Wed, 16 Apr 2014 03:09:16 -0700 (PDT) Received: from [10.182.31.96] (85-76-81-43-nat.elisa-mobile.fi [85.76.81.43]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 9A5642002C; Wed, 16 Apr 2014 13:09:06 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D167) In-Reply-To: <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> Date: Wed, 16 Apr 2014 13:09:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <58DDAD35-E8F4-4446-A228-A15F9CDB0D29@iki.fi> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vm6GIiKI-DsblY87G8fFKwBIVv8 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 10:09:41 -0000 > On 16.4.2014, at 10.55, Nikos Mavrogiannopoulos wrote: >=20 > This is a significant investment, that would require e.g., universities > to justify to their funding agencies the reasons of their spending. Very > few people will accept reasoning like "we spent a year designing a TLS > update just in case". >=20 > Comments like that, that anyone can submit a TLS 2.0 protocol design are > really misleading. I understand the funding is a problem. Heck, I would probably start working o= n it myself if I had enough funding and a good team ready to go. However, I b= elieve TLS originally succeeded not because it was the best design, but beca= use it was done, worked and most importantly was the only reasonable candida= te for its use case that could be improved together. All a competition would do is to result in a several implementations working= differently. And because each of the teams have gotten significant investme= nts from their backers, they would have a strong agenda to push it through o= ne way or another, and this is where it might get ugly. Because, as you just= said yourself, no one wants to fund an expensive project that is just throw= n away. Wouldn't it be better to make a design and a rough implementation of a proto= col not because of a competition, but because you truly believe there's a ne= ed for it? I know I may sound idealistic, sorry for that, but it's something= I'm trying to hold on to. If someone is trying to get funding for TLS 2.0 and cannot get it because of= the consensus in this WG, they should definitely bring it to discussion on t= his mailing list. Otherwise I think the topic is slightly speculative. Juho From nobody Wed Apr 16 03:42: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 710731A0118 for ; Wed, 16 Apr 2014 03:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.722 X-Spam-Level: * X-Spam-Status: No, score=1.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 IHr4YmrbJ3ms for ; Wed, 16 Apr 2014 03:42:06 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 437741A0022 for ; Wed, 16 Apr 2014 03:42:05 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wn1so4689151obc.32 for ; Wed, 16 Apr 2014 03:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4rw9DHHE5AMDUILJkDfzcilZVrLEthTPn6owJ40ci68=; b=FitTVD6qEX4Tc5mN1IsbObVURtgOrt/joRVNelW4CnTpNQ+zKFANt5TijCtRWmOPkK 20SBQNFzlii2mfxJWECC9VW7t1lcQXTTcUKqO4Saor+d6HdHWaQWlg5UuHzrpSvzc5TD xbWWWcEWuBr/yDBGWfasFI6LXKm/xj+k+r38k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4rw9DHHE5AMDUILJkDfzcilZVrLEthTPn6owJ40ci68=; b=J/Q4D+XIu69t4U045c4t9LVob0c/RuMuuWnGDCEaIVFX3335iGo3vs7RIlqjPcuDgQ gvBHagzWMECXGORQ3izLZwGtBc3UEHJHVmjJKQXYtl6CDL2FBRmAyBY63T+9ELxbS8bC aC9J5/jOCgvIA2tTcj4oz7TjQ67WtH4tPKiCb/5T7WUoZUGAB1icyVVyxeNarF5N32dn jrJoEVZtZOmVw4OBipEqQxM8CNGo5ERE4KelbnKAFEQLPsI0FgwQf9T0dPGrp2Ke3qow CCt6uO0cX47R71LXuVxsJjYDHmrUYmGD6Fvd1gg+YMMLJnai59I+Md/inU8sKO3NVYFj WTXQ== X-Gm-Message-State: ALoCoQkrT9QrBSh8MMOegkWVYr8VO7FFTh2E+9yiO8IQb4lPiAwrsU6A+Q3/n4pN6LgSWPZf8Rye MIME-Version: 1.0 X-Received: by 10.60.37.199 with SMTP id a7mr1428700oek.41.1397644922830; Wed, 16 Apr 2014 03:42:02 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.24.168 with HTTP; Wed, 16 Apr 2014 03:42:02 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: <58DDAD35-E8F4-4446-A228-A15F9CDB0D29@iki.fi> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> <58DDAD35-E8F4-4446-A228-A15F9CDB0D29@iki.fi> Date: Wed, 16 Apr 2014 12:42:02 +0200 X-Google-Sender-Auth: NGkApmp_32Uoh0h5cdEjngx2xTA Message-ID: From: Alfredo Pironti To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: multipart/alternative; boundary=089e011769d125e80d04f7269158 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w9nQGTYey0_fi8HKo2mZvJSJUdo Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 10:42:10 -0000 --089e011769d125e80d04f7269158 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 16, 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > > > On 16.4.2014, at 10.55, Nikos Mavrogiannopoulos wrote= : > > > > This is a significant investment, that would require e.g., universities > > to justify to their funding agencies the reasons of their spending. Ver= y > > few people will accept reasoning like "we spent a year designing a TLS > > update just in case". > > > > Comments like that, that anyone can submit a TLS 2.0 protocol design ar= e > > really misleading. > > I understand the funding is a problem. Heck, I would probably start > working on it myself if I had enough funding and a good team ready to go. > However, I believe TLS originally succeeded not because it was the best > design, but because it was done, worked and most importantly was the only > reasonable candidate for its use case that could be improved together. > > All a competition would do is to result in a several implementations > working differently. And because each of the teams have gotten significan= t > investments from their backers, they would have a strong agenda to push i= t > through one way or another, and this is where it might get ugly. Because, > as you just said yourself, no one wants to fund an expensive project that > is just thrown away. > > Wouldn't it be better to make a design and a rough implementation of a > protocol not because of a competition, but because you truly believe > there's a need for it? I know I may sound idealistic, sorry for that, but > it's something I'm trying to hold on to. > > If someone is trying to get funding for TLS 2.0 and cannot get it because > of the consensus in this WG, they should definitely bring it to discussio= n > on this mailing list. Otherwise I think the topic is slightly speculative= . > This is not speculative. I work in the academia, and right now I'm refraining to invest my time (let alone funds) into a TLS proposal because, in the absence of a call for proposals, I deem my time is better invested in other activities. I agree with you that, after such investment, all authors would strenuously try to defend their proposal, and this is why selection should not come exclusively form the authors. I also agree several proposals may eventually merge; but, assuming the merge is better than the originals, I see this as a positive byproduct of the call process. That said, I'll admit that, as long as we have to stick with the current Client/ServerHello negotiation and client speaks first, I see much of the progress one can make being incremental, rather than radically new. Alfredo > > > Juho > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e011769d125e80d04f7269158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 16, 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua <juhovh@= iki.fi> wrote:

> On 16.4.2014, at 10.55, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>
> This is a significant investment, that would require e.g., universitie= s
> to justify to their funding agencies the reasons of their spending. Ve= ry
> few people will accept reasoning like "we spent a year designing = a TLS
> update just in case".
>
> Comments like that, that anyone can submit a TLS 2.0 protocol design a= re
> really misleading.

I understand the funding is a problem. Heck, I would probably start w= orking on it myself if I had enough funding and a good team ready to go. Ho= wever, I believe TLS originally succeeded not because it was the best desig= n, but because it was done, worked and most importantly was the only reason= able candidate for its use case that could be improved together.

All a competition would do is to result in a several implementations workin= g differently. And because each of the teams have gotten significant invest= ments from their backers, they would have a strong agenda to push it throug= h one way or another, and this is where it might get ugly. Because, as you = just said yourself, no one wants to fund an expensive project that is just = thrown away.

Wouldn't it be better to make a design and a rough implementation of a = protocol not because of a competition, but because you truly believe there&= #39;s a need for it? I know I may sound idealistic, sorry for that, but it&= #39;s something I'm trying to hold on to.

If someone is trying to get funding for TLS 2.0 and cannot get it because o= f the consensus in this WG, they should definitely bring it to discussion o= n this mailing list. Otherwise I think the topic is slightly speculative.

This is not speculative. I work in the aca= demia, and right now I'm refraining to invest my time (let alone funds)= into a TLS proposal because, in the absence of a call for proposals, I dee= m my time is better invested in other activities.

I agree with you that, after such investment, all authors wo= uld strenuously try to defend their proposal, and this is why selection sho= uld not come exclusively form the authors. I also agree several proposals m= ay eventually merge; but, assuming the merge is better than the originals, = I see this as a positive byproduct of the call process.

That said, I'll admit that, as long as we have to stick = with the current Client/ServerHello negotiation and client speaks first, I = see much of the progress one can make being incremental, rather than radica= lly new.

Alfredo
=C2=A0


Juho

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

--089e011769d125e80d04f7269158-- From nobody Wed Apr 16 04: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 460E91A012A for ; Wed, 16 Apr 2014 04:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrP1SC1_wVBo for ; Wed, 16 Apr 2014 04:28:29 -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 19BE11A010B for ; Wed, 16 Apr 2014 04:28:29 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BFFA44755C; Wed, 16 Apr 2014 11:28:25 +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 A5ABC47529; Wed, 16 Apr 2014 11:28:25 +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 A2CFA2030; Wed, 16 Apr 2014 11:28:25 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 16 Apr 2014 07:28:25 -0400 From: "Salz, Rich" To: Martin Thomson , Trevor Perrin Date: Wed, 16 Apr 2014 07:28:22 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9ZNTr7JosnXlEPQTS9xvQeL7nAVQAMa3+A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4906DD@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@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/fkTjb4JvYs5DpWNMpRnqhlBLmeg Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 11:28:30 -0000 WWVzLCBJJ2Qgc2F5IHRoYXQgTWFydGluJ3MgZGVzY3JpcHRpb24gaXMgYSBtb3JlIGFjY3VyYXRl IHN0YXRlbWVudCBvZiBteSB2aWV3Lg0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5l ZXINCkFrYW1haSBUZWNobm9sb2d5DQpDYW1icmlkZ2UsIE1BDQoNCg== From nobody Wed Apr 16 06:54: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 70D6E1A01A7 for ; Wed, 16 Apr 2014 06:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwLIqCinUvV3 for ; Wed, 16 Apr 2014 06:54:16 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E41EE1A019B for ; Wed, 16 Apr 2014 06:54:15 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl14so10947919pab.4 for ; Wed, 16 Apr 2014 06:54:12 -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=P+/tJ5VSTFsOoBrKfHOemFUJkLg08Ne3O6jcgy8QnYY=; b=Eey4ZPNzmYR2ina3+rE2VBIoKnT4x0yh76R9uX29woHArOeiRh1i4Od1iWKwHn/7kE oABJcVC/iP8mPzj34vWi713qps3YmNzvszJ2/j9A5x2N4tYSGYPTa/+wVlJCHeI9tw0G No0AnR2GxaVOf6xra04Tg/gpCgAvvV/ntVDFI= 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=P+/tJ5VSTFsOoBrKfHOemFUJkLg08Ne3O6jcgy8QnYY=; b=RtqlxuV6bWqfVJmOf3CoSZK5Kqh+9JvKDy4Bt0gGLtxWdVg7/agJibnVF8inYnyjcA juWNB4/WsPNr7TAa44C0+dSjReYqp5IHPxhadqgVUVaCrM7FqM8RGmrRiMHtNJt6T/29 mUf2/KmrrloDX9leOJPjFZ4dqYgbQgBv52mrxi1794gfdH+sFrDZsFBLwHeOZ/mYr6Wn lF+LyWiclGtBh+K/AiwEDFxCFF537RAFbDzquArQoCOTGJUhK3xqFSCiMoe8mgX51lau iqqURfR5ZuAsATr8D6HhS6RB3Z1QJAhDrf9patS4QsMP4D/9+whRM+XpXplYW12QD7DU zTzw== X-Gm-Message-State: ALoCoQkXaFyuz98Dw6Ll5o+sCZx/s9YiA7dRyA2Wnr0E8cfbqRVoDFSsSaaZA8GzFDlMci/GjVwb X-Received: by 10.66.140.104 with SMTP id rf8mr8626852pab.107.1397656452581; Wed, 16 Apr 2014 06:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Wed, 16 Apr 2014 06:53:51 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Tom Ritter Date: Wed, 16 Apr 2014 09:53:51 -0400 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ovuTzETENRYVe3WV5fUhRnrblaw Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 13:54:20 -0000 On 15 April 2014 23:50, Eric Rescorla wrote: > However, it's worth considering > and I'd love to hear from people who want encrypted SNI what they > think of this tradeoff. I don't much like opt-in security or privacy mechanisms. I feel that over time, people's opinion of their usefulness dwindles, they're removed in favour of simplicity or performance, and then later on we realise we wished we had them and wind up having to work around things. But the status quo has become to do without, and thus re-proposing it is a non-starter. (An example could be OCSP-nonce requests.) Furthermore, no offence to Rich, but I suspect if you told him "We'll build the DNS subdomain forwarding, and you can use that or just not encrypted SNI", he will choose not to use it. Maybe I'm wrong, but since he argued against it initially, I'll make the leap. So making it opt-in seems to be as equivalent to building an optional feature that almost no one will use from the beginning. No matter what we do, we will be defining a new protocol that requires network operators do a test deployment, change configurations, and move some inter-operating pieces into play. While I'm sympathetic to keeping that effort as low as possible, I feel optimising for that goal is the incorrect optimisation. Rather, optimising for the best protocol on the wire, with 0-RTT and 1-RTT, a protected handshake, and the like is more important. There are a couple options that can try to address the technical problems Rich has raised. The wildcard approach is one way to solve this, and I don't have any immediate concerns about beyond it's heavy requirement on DNS integrity. While it's my sincere hope we will have it at least deployed, I suspect not all clients will have validating resolvers such that we're willing to bank what will be significant amounts of dependence on it. ....But... There once was a thing called DNSSEC Stapled Certs (https://www.imperialviolet.org/2011/06/16/dnssecchrome.html) where a SSL certificate had a chain of DNSSEC signatures in it, validating it via DANE (or at that time, a DANE-like mechanism.) It violates a layering principal that people hold dearly, shoving DNS information in other corners it shouldn't be. But I think it would be necessary for the wildcard approach to be reliable for clients like browsers. This DNSSEC chain (from root, to TLD, to the record that xxx.privacy.org TLSNAMEs to privacy.cdn.com) could be provided by privacy.org in an HTTP Header, HTML META tag, or other mechanism. The browser sees this, and then doesn't even need to perform a DNS lookup for the subdomain when it encounters it. The application server for privacy.org only needs a DNSSEC-capable client to retrieve these records periodically. Another approach I think can be made to work is the idea of per-IP shared parameters. A static key, valid for a week, for an IP that servers 10,000 domains does not seem less secure to me than 10,000 RSA keys on a server serving 10,000 domains. If you can steal one RSA key, I don't understand why you could not so target the other 9,999. CDNs are probably in the _best_ position to rotate these keys quickly, as a client who is on the internet is more likely to talk to a CDN every day than any individual domain name. The idea of the handshake being indistinguishable from random using Elligator is very very attractive. Several people in internet censorship research have lamented that if you build a protocol that is indistinguishable from random bytes on the wire - you are the _only_ protocol to do so, and thus are distinguishable. I would love for TLS 1.3/1.4/2.0/whatever to lay out that goal, as I feel we would be giving the notion of Net Neutrality a powerful gift: Outside intranets, on the internet itself, all traffic is equal, and you cannot distinguish between the most popular protocol or MyFirstRandomProtocol. -tom From nobody Wed Apr 16 07:28: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 982911A01D6 for ; Wed, 16 Apr 2014 07:28:31 -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 VXpHW_OLKjbd for ; Wed, 16 Apr 2014 07:28:27 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 246A21A01CF for ; Wed, 16 Apr 2014 07:28:27 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so1469857wib.16 for ; Wed, 16 Apr 2014 07:28: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:from:date :message-id:subject:to:cc:content-type; bh=xCB0d55mQC2/mnFbqOeDO6tAOBAvMxUrjpnoQIPXHbs=; b=ipKir9W2FG6Jcu+//pPgXmO9MBow87K3aYGpTRng6g0vATNdJeRXRn6E7LtIOaM5nn Y8pc8JoilDwkJgXIhPxAjMCSxtneic/LrglR6aE0iGbqO1YEDcQMiP4WLP10sSMp0/1z YQWvEmPZZiJXLtOcpriJ4Gv8XpvSEGnURLq1hw2oLFWPuhn7gzOdJGOEno/8EKSpn7SM YKz2xK8MlhqH9sCxqXg7gpnlBXDCwjuXNh/0vtPBLqm1yBa9sqEqgAsrzfGz8pHI/4v1 xYOmCmHsMntK+VSnAVfv+H1LsY/MJJxXacs+6mbhUB7u+xfk0BIV+rjZq1yFGAe6lI/A 7X/w== X-Gm-Message-State: ALoCoQlbUgILxpY3E/qm7KKWIjLCKwpeHc2hhHQ/6rBqcW2s7CBrpIGJSkx2/5h7eNK4106X7qSC X-Received: by 10.180.212.76 with SMTP id ni12mr7773558wic.49.1397658503449; Wed, 16 Apr 2014 07:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 16 Apr 2014 07:27:43 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Wed, 16 Apr 2014 07:27:43 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c351a49da56a04f729baa5 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SQZQ4z6VCoV1RAx7aGM9nU3o6p4 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 14:28:31 -0000 --001a11c351a49da56a04f729baa5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 15, 2014 at 10:32 PM, Martin Thomson wrote: > On 15 April 2014 17:46, Trevor Perrin wrote: > > > > So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3 > > that completes quickly and with small changes to TLS 1.2. > > That's a not quite accurate reinterpretation of my statements. > > My position is that TLS 1.3 should meet its chartered goals as > expediently as possible. Depending on the answers to certain > questions (like the SNI question), that might involve small changes to > 1.2 or it might be big. Arguably, completely changing the record > layer as we've essentially agreed is a big change, so we're already > there. Just as a clarifying point, I believe that what we've agreed isn't to completely change the record layer, but rather we've agreed (assuming there is consensus to do so) to deprecate two of the record variants (StreamCipher and BlockCipher) in favor of the third, AEAD, which shouldn't be changing significantly. -Ekr --001a11c351a49da56a04f729baa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 15, 2014 at 10:32 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 15 April 2014 17:46, Trev= or Perrin <trevp@trevp.net> wr= ote:
>
> So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3<= br> > that completes quickly and with small changes to TLS 1.2.

That's a not quite accurate reinterpretation of my statements.
My position is that TLS 1.3 should meet its chartered goals as
expediently as possible. =A0Depending on the answers to certain
questions (like the SNI question), that might involve small changes to
1.2 or it might be big. =A0Arguably, completely changing the record
layer as we've essentially agreed is a big change, so we're already=
there.

Just as a clarifying point, I believ= e that what we've agreed isn't to
completely change the r= ecord layer, but rather we've agreed
(assuming there is conse= nsus to do so) to deprecate two
of the record variants (StreamCipher and BlockCipher) in favor
of the third, AEAD, which shouldn't be changing significantly.
=

-Ekr
--001a11c351a49da56a04f729baa5-- From nobody Wed Apr 16 07:32: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 58CB81A01C1 for ; Wed, 16 Apr 2014 07:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCLX3kxQ0C3s for ; Wed, 16 Apr 2014 07:32:36 -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 6D4271A01AA for ; Wed, 16 Apr 2014 07:32:36 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3B13F1656F6; Wed, 16 Apr 2014 14:32:33 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 303971656F1; Wed, 16 Apr 2014 14:32:33 +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 18D7B1E04D; Wed, 16 Apr 2014 14:32:33 +0000 (GMT) Received: from Tereva.local (172.19.113.223) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 16 Apr 2014 10:32:32 -0400 From: Brian Sniffen To: Tom Ritter , Eric Rescorla In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Wed, 16 Apr 2014 09:32:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3s05qTHKwE4Ot7kWA7J2GqdTjFg Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:32:37 -0000 > Furthermore, no offence to Rich, but I suspect if you told him "We'll > build the DNS subdomain forwarding, and you can use that or just not > encrypted SNI", he will choose not to use it. Maybe I'm wrong, but > since he argued against it initially, I'll make the leap. So making > it opt-in seems to be as equivalent to building an optional feature > that almost no one will use from the beginning. Yes: we will not use encrypted SNI. We can't. We need to put thousands of HTTP hosts with incompatible crypto requirements on each IP address. Per-IP keys don't help us very much. > Another approach I think can be made to work is the idea of per-IP > shared parameters. A static key, valid for a week, for an IP that > servers 10,000 domains does not seem less secure to me than 10,000 RSA > keys on a server serving 10,000 domains. If you can steal one RSA key, > I don't understand why you could not so target the other 9,999. Those 10k domains can't agree on basic cryptographic primitives, never mind parameters of those primitives. Moreover, we don't have a single machine or a single location behind each of those IP addresses---so the key distribution problem there gets a little complicated. That part is not insurmountable---but I think continuing to make TLS push us to use a number of IP addresses proportional to the number of web sites misses the prime benefit of SNI. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Wed Apr 16 07:40: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 89DD41A01C1 for ; Wed, 16 Apr 2014 07:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BS5leH3W8Tn for ; Wed, 16 Apr 2014 07:40:23 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 33ED41A015D for ; Wed, 16 Apr 2014 07:40:22 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so8324145lan.30 for ; Wed, 16 Apr 2014 07:40:19 -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=ay/x3sdEnewHDZRs7ZJ/iW3gGd064bCFuTd0CUlJVV0=; b=j0lIvz0jflO3hiJ04cSdgvoONuYFxgcpn+szVXjC4bHnkrdtTYvlKx6cj4U7AumHq7 r605jY/Zfw8s9hy9UdV+jf7PI99WBikVuoDn7JMJIj84sollCYYCTXonPficHLLJnUxF cNjFvr3oKN9S9tNgwctOFLrSZq/Na8zBvqccgu2aPO8n0AsvFK7+nWh1TpB42KByVUFM SnUqR/wEyer1nViDBR4KMdaE7brpC67GbvjD0xfVdnxdykAMHlOxPVQT0wj42F4mzwr8 +Sw2lghuacb7WGH8zQfw9pL3LnVx67IjjvwE2YqFqyAul5Nwi5SxU/zxy5MXKzU5pKcD Iddg== X-Gm-Message-State: ALoCoQlfYaIN1vef+CsePwz0wwHPbRkHKLDjdlLjCRuvQ/m/lWOvX9aOk2pkp91GkjP6spnUYf+y X-Received: by 10.112.171.67 with SMTP id as3mr3105640lbc.10.1397659219230; Wed, 16 Apr 2014 07:40:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 07:39:59 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 07:39:59 -0700 Message-ID: To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2nZmg0u_56PpAEtvwxfWC17Il-g Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:40:27 -0000 On Wed, Apr 16, 2014 at 7:32 AM, Brian Sniffen wrote: >> Furthermore, no offence to Rich, but I suspect if you told him "We'll >> build the DNS subdomain forwarding, and you can use that or just not >> encrypted SNI", he will choose not to use it. Maybe I'm wrong, but >> since he argued against it initially, I'll make the leap. So making >> it opt-in seems to be as equivalent to building an optional feature >> that almost no one will use from the beginning. > > Yes: we will not use encrypted SNI. We can't. We need to put thousands > of HTTP hosts with incompatible crypto requirements on each IP address. > Per-IP keys don't help us very much. Would a protocol along the lines of my strawman work for you? I explicitly did not require that the eventual cipher suite match for different SNI values. I even made it possible to for whatever receives the initial SSL connection to strip the SNI encryption and hand the connection of to something else, without sharing any long-term secrets between the machines in question. --Andy From nobody Wed Apr 16 07:53: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 A9D8A1A0217 for ; Wed, 16 Apr 2014 07:53:13 -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 ordUDHgTy3vn for ; Wed, 16 Apr 2014 07:53:09 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id D37871A0215 for ; Wed, 16 Apr 2014 07:53:08 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so8264736lbi.13 for ; Wed, 16 Apr 2014 07:53: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=iKIhty1GA8WgvBUDqlJoW90j+t5Yd9Bh8OBvXqvwFHo=; b=XY1R9MB1On//Qin6jVk6vMY93Cb2uR5XOHABotQxCItOCQSfb8Pe5YZFfMw7NXq74M P9CHH/q0DMT+RyGhomnnLDJcI4XmKxQLIufop7/WXyx2jb61Tv435FiuRwo+NtcZpKQX 9q1k30Fb5c9+dT9mRsDaIF7ht+92MpM8Qv5pUYmCb+DPq/sG18reMLb6hYKvYUJyNH2u Q+mgirZPVOWZJ9tVoEMhBYuJljilwO1NHIEaDWX872rTJxDvy5z14gDgx9UyOn9PRaFe TcgTAl/6eUW3BweMXlQH93elvjJJ/ct2GSSYLppT17xGmMV95Cr2Zen+dapoCkBl7pm1 IJHg== X-Gm-Message-State: ALoCoQn5z5p1BrWjEja+shkhqQ2AfdkC3qlfeLJ7G4wCa9l7VoVKPDwrq0NxSCU4F48oxIHMIrln X-Received: by 10.112.131.34 with SMTP id oj2mr1948767lbb.43.1397659985039; Wed, 16 Apr 2014 07:53:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 07:52:44 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 07:52:44 -0700 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dgmcaV_ibfdlKgQtfinQjCyJ7OM Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 14:53:13 -0000 On Tue, Apr 15, 2014 at 8:50 PM, Eric Rescorla wrote: > Andy, > > This is an interesting idea and as you say, it has the virtue that it > doesn't require messing with the state machine at all. I have a few > comments: > > 1. You probably have to frame this as a ClientHello with some > opaque extensions which happen to be encrypted. The reason for > this is that there are stateful inspection devices which examine > data on port 443 and enforce that it looks like TLS. As these > devices are associated with the client not the server, the server's > TLS 1.3 compatibility does not guarantee that the client will > in fact be able to send a non-TLS framed ClientHello. This is annoying but shouldn't be a real problem. If large numbers of sites end up deploying it, and everyone involved agrees to send the exact same sequence of "TLS" header bytes in front, then there's an added benefit: middle boxes won't be able to tamper with the actual encrypted part, so it should be extensible in the future with impunity. Of course, MITM boxes will hate it, because a client configured in a hard fail mode won't be able to complete a handshake through a MITM box with a CA key, since the MITM box won't be able to understand the handshake. I think this isn't so terrible. > > 2. It might (or might not) be easier to frame the advertised information > as a TLS cipher suite. > Hmm. This could work if TLS cipher suites get split into separate cipher, signature, and key exchange parts. In the mean time, there are no signatures involved at all, so most of the cipher suites don't make much sense here. And I don't think anyone wants to add TLS_CURVE25519ELGAMAL_AES_128_GCM_SHA256 as a high-performance non-PFS option. > 3. This only prevents downgrade attacks if the information > is secured via DNSSEC. There are intermediate elements which > damage enough of the DNS resolution process that they will > cause DNS signature failures even when the client knows that > the records are supposed to be signed. Hard-failing in these > cases will likely result in unacceptably high failure rates, but > if you don't hard fail, then a network-based downgrade to > unencrypted SNI is possible. > Fedora is currently mulling over making everyone's laptop use DNSSEC by default. This may be a mess, but it looks like it'll actually work, albeit with a bit of DNSSEC-over-TCP hackery. In any event, there will eventually be clients who will refuse to connect to HTTPS sites without either a valid TLSA entry or a proof that there isn't one, and these clients will be fully protected by this kind of hello encryption. > > More generally, I note that a number of the suggestions that people > have provided here (yours, Watson's Rich's, my modification of Rich's) > have the common factor that they require the server to opt-in in some > way. This has the major advantage that it allows us to design a > mechanism which might be inconvenient for some network environments > because they can just not opt-in, as well as allowing out-of-band > delivery of some data in the DNS. > > The disadvantage seems to be that a smaller fraction of sites will offer > encrypted SNI, which slightly paints > a target on them. I think that's probably OK, since no matter what mechanism > we use for encrypted SNI, it seems likely that an attacker will be able to > get a good handle on the virtual hosts served by a given site, and so > can use that to identify which sites he is interested in tracking even if > everyone were to use encrypted SNI. However, it's worth considering > and I'd love to hear from people who want encrypted SNI what they > think of this tradeoff. > True. I bet that Google, at least, would enable this thing, and there may be enough pressure on the big CDNs to do it that one or two of them will as well. At that point, there's already a lot of benefit. If a proposal like this were adopted, someone should try to prove that a server that does not know the private key associated with the ClientHello protection cannot tamper with any legitimate connections to that domain. If true, this would be a nice bonus. It might pay to adjust the protocol, if needed, to make such a proof simpler. For example, the ServerHello could include an extension that proves knowledge of the ClientHello temporary key. To make that work well, there would have to be some extra trickery to make sure that big virtual hosts can strip the ClientHello encryption and still successfully connect. The existing client random field may already be enough, though. --Andy From nobody Wed Apr 16 08:03: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 9E7F11A0173 for ; Wed, 16 Apr 2014 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeT1LiKRpM8R for ; Wed, 16 Apr 2014 08:02:14 -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 86AA91A01F9 for ; Wed, 16 Apr 2014 08:02:07 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5C1751656E2; Wed, 16 Apr 2014 15:02:04 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 5129A1656D5; Wed, 16 Apr 2014 15:02:04 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 393121E04D; Wed, 16 Apr 2014 15:02:04 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 16 Apr 2014 11:02:03 -0400 From: "Salz, Rich" To: "Sniffen, Brian" , Tom Ritter , Eric Rescorla Date: Wed, 16 Apr 2014 11:02:02 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9ZgLgyCg5FjiX5Qee5/3QOJdiLvAAA4nRQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120B49085F@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XhK0vlOgNaHPQni3TRX55erM8go Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:02:33 -0000 > Yes: we will not use encrypted SNI. We can't. We need to put thousands = of HTTP hosts with incompatible crypto requirements on each IP address. Brian makes a simple declarative statement. I started this thread by trying= to list why the tradeoffs are such that a consensus could reasonably come = to the conclusion that encrypted SNI should not be a part of TLS 1.3 /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Wed Apr 16 08:04: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 66C461A0135 for ; Wed, 16 Apr 2014 08:04:16 -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 G64pp30AIVTf for ; Wed, 16 Apr 2014 08:04:06 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 91E831A01A5 for ; Wed, 16 Apr 2014 08:04:02 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so10954501wgg.6 for ; Wed, 16 Apr 2014 08:03: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:from:date :message-id:subject:to:cc:content-type; bh=D+tiZVN6mqa9pp0unvsnpGeJJR/rQXI6l3clWnSmIBQ=; b=XT4i1oFwUubI5LaJZB6YR0HsfYgYPCfGbhf4X5yIXKgY2qefFDGFy6nVk2QM1wlZZz YJAMLEdB5KksaS4/AWp+VkDNBFI6IUp44FjwivBsNMXg1fAsP9R0Qh21DXT2CaZIYkPW +cWmnPfQHoV2Aon8mCx6iuzqKkaAZPNT0Qivwg+h28wXq52f4WkSU0j3jZ/8R0Fk0N3i xGeKDowhxJHDxv8/QOr9gdEv3J57Cz3paQ61E7uJ1zmtPlWmVt4P8d1RvMFggTg1bD07 APuAD/8fd4s/oQ3hDlHaJkbFpu6gx+3Je3Yy6sCJY/fymc6vI8Mq0d5RWBFTt5qWXz6L tNHw== X-Gm-Message-State: ALoCoQnzvpQ4PKdqVZTl+g2Y9U6dHsss9FoYnJJ+2Hs+h3WQrzPp6u+IHVr5UCUHGlvRG4Qsi2BR X-Received: by 10.180.212.76 with SMTP id ni12mr7918057wic.49.1397660638905; Wed, 16 Apr 2014 08:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 16 Apr 2014 08:03:17 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Eric Rescorla Date: Wed, 16 Apr 2014 08:03:17 -0700 Message-ID: To: Andy Lutomirski Content-Type: multipart/alternative; boundary=001a11c351a4e6263d04f72a3942 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xY-yzpt9CX6uE6BOETA0UOgnRDA Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:04:16 -0000 --001a11c351a4e6263d04f72a3942 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 16, 2014 at 7:52 AM, Andy Lutomirski wrote: > On Tue, Apr 15, 2014 at 8:50 PM, Eric Rescorla wrote: > > Andy, > > > > This is an interesting idea and as you say, it has the virtue that it > > doesn't require messing with the state machine at all. I have a few > > comments: > > > > 1. You probably have to frame this as a ClientHello with some > > opaque extensions which happen to be encrypted. The reason for > > this is that there are stateful inspection devices which examine > > data on port 443 and enforce that it looks like TLS. As these > > devices are associated with the client not the server, the server's > > TLS 1.3 compatibility does not guarantee that the client will > > in fact be able to send a non-TLS framed ClientHello. > > This is annoying but shouldn't be a real problem. > I agree. I wasn't trying to suggest that it was. To be clear, I think this is a clever idea definitely worth exploring. Thanks for suggesting it. If large numbers of sites end up deploying it, and everyone involved > agrees to send the exact same sequence of "TLS" header bytes in front, > then there's an added benefit: middle boxes won't be able to tamper > with the actual encrypted part, so it should be extensible in the > future with impunity. > > Of course, MITM boxes will hate it, because a client configured in a > hard fail mode won't be able to complete a handshake through a MITM > box with a CA key, since the MITM box won't be able to understand the > handshake. I think this isn't so terrible. I'm not sure how deployable that is going to turn out to be. As you know, current browsers don't allow CA pinning to override MITM boxes for deployment reasons, so this seems like it might be a disincentive for people to adopt this. I'd love to hear from large client implementors how they would feel about this. (I'll ask around Mozilla...) > 2. It might (or might not) be easier to frame the advertised information > > as a TLS cipher suite. > > > > Hmm. This could work if TLS cipher suites get split into separate > cipher, signature, and key exchange parts. In the mean time, there > are no signatures involved at all, so most of the cipher suites don't > make much sense here. And I don't think anyone wants to add > TLS_CURVE25519ELGAMAL_AES_128_GCM_SHA256 as a high-performance non-PFS > option. Yeah, I'm not sure about this one either. Will have to think about it more. > > 3. This only prevents downgrade attacks if the information > > is secured via DNSSEC. There are intermediate elements which > > damage enough of the DNS resolution process that they will > > cause DNS signature failures even when the client knows that > > the records are supposed to be signed. Hard-failing in these > > cases will likely result in unacceptably high failure rates, but > > if you don't hard fail, then a network-based downgrade to > > unencrypted SNI is possible. > > > > Fedora is currently mulling over making everyone's laptop use DNSSEC > by default. This may be a mess, but it looks like it'll actually > work, albeit with a bit of DNSSEC-over-TCP hackery. In any event, > there will eventually be clients who will refuse to connect to HTTPS > sites without either a valid TLSA entry or a proof that there isn't > one, and these clients will be fully protected by this kind of hello > encryption. I suspect that the problem here is the browsers, which generally don't want to accept even marginal increase in failure rates (and DNS over TCP is associated with that...) > More generally, I note that a number of the suggestions that people > > have provided here (yours, Watson's Rich's, my modification of Rich's) > > have the common factor that they require the server to opt-in in some > > way. This has the major advantage that it allows us to design a > > mechanism which might be inconvenient for some network environments > > because they can just not opt-in, as well as allowing out-of-band > > delivery of some data in the DNS. > > > > The disadvantage seems to be that a smaller fraction of sites will offer > > encrypted SNI, which slightly paints > > a target on them. I think that's probably OK, since no matter what > mechanism > > we use for encrypted SNI, it seems likely that an attacker will be able > to > > get a good handle on the virtual hosts served by a given site, and so > > can use that to identify which sites he is interested in tracking even if > > everyone were to use encrypted SNI. However, it's worth considering > > and I'd love to hear from people who want encrypted SNI what they > > think of this tradeoff. > > > > True. > > I bet that Google, at least, would enable this thing, and there may be > enough pressure on the big CDNs to do it that one or two of them will > as well. At that point, there's already a lot of benefit. > > If a proposal like this were adopted, someone should try to prove that > a server that does not know the private key associated with the > ClientHello protection cannot tamper with any legitimate connections > to that domain. If true, this would be a nice bonus. It might pay to > adjust the protocol, if needed, to make such a proof simpler. For > example, the ServerHello could include an extension that proves > knowledge of the ClientHello temporary key. To make that work well, > there would have to be some extra trickery to make sure that big > virtual hosts can strip the ClientHello encryption and still > successfully connect. The existing client random field may already be > enough, though. This does seem like a worthwhile goal. -Ekr --001a11c351a4e6263d04f72a3942 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 16, 2014 at 7:52 AM, Andy Lutomirski = <luto@amacapita= l.net> wrote:
On Tue, Apr 15, 2014 at 8:50= PM, Eric Rescorla <ekr@rtfm.com>= wrote:
> Andy,
>
> This is an interesting idea and as you say, it has the virtue that it<= br> > doesn't require messing with the state machine at all. I have a fe= w
> comments:
>
> 1. You probably have to frame this as a ClientHello with some
> opaque extensions which happen to be encrypted. The reason for
> this is that there are stateful inspection devices which examine
> data on port 443 and enforce that it looks like TLS. As these
> devices are associated with the client not the server, the server'= s
> TLS 1.3 compatibility does not guarantee that the client will
> in fact be able to send a non-TLS framed ClientHello.

This is annoying but shouldn't be a real problem.

I agree. I wasn't trying to suggest that it was. T= o be clear, I think this
is a clever idea definitely worth explor= ing. Thanks for suggesting it.


If large numbers of sites end up deploying it, and everyone involved
agrees to send the exact same sequence of "TLS" header bytes in f= ront,
then there's an added benefit: middle boxes won't be able to tamper=
with the actual encrypted part, so it should be extensible in the
future with impunity.

Of course, MITM boxes will hate it, because a client configured in a
hard fail mode won't be able to complete a handshake through a MITM
box with a CA key, since the MITM box won't be able to understand the handshake. =A0I think this isn't so terrible.

I'm not sure how deployable that is going to turn out to be. As = you know,
current browsers don't allow CA pinning to override= MITM boxes for
deployment reasons, so this seems like it might be a disincentive for<= /div>
people to adopt this. I'd love to hear from large client impl= ementors
how they would feel about this. (I'll ask around Moz= illa...)



> 2. It might (or might not) be easier to frame the advertised informati= on
> as a TLS cipher suite.
>

Hmm. =A0This could work if TLS cipher suites get split into separate<= br> cipher, signature, and key exchange parts. =A0In the mean time, there
are no signatures involved at all, so most of the cipher suites don't make much sense here. =A0And I don't think anyone wants to add
TLS_CURVE25519ELGAMAL_AES_128_GCM_SHA256 as a high-performance non-PFS
option.

Yeah, I'm not sure about this o= ne either. Will have to think about
it more.

=
=A0
> 3. This only prevents downgrade attacks if the information
> is secured via DNSSEC. There are intermediate elements which
> damage enough of the DNS resolution process that they will
> cause DNS signature failures even when the client knows that
> the records are supposed to be signed. Hard-failing in these
> cases will likely result in unacceptably high failure rates, but
> if you don't hard fail, then a network-based downgrade to
> unencrypted SNI is possible.
>

Fedora is currently mulling over making everyone's laptop use DNS= SEC
by default. =A0This may be a mess, but it looks like it'll actually
work, albeit with a bit of DNSSEC-over-TCP hackery. =A0In any event,
there will eventually be clients who will refuse to connect to HTTPS
sites without either a valid TLSA entry or a proof that there isn't
one, and these clients will be fully protected by this kind of hello
encryption.

I suspect that the problem here= is the browsers, which generally
don't want to accept even m= arginal increase in failure rates
(and DNS over TCP is associated= with that...)


> More generally, I note that a number of the suggestions that people > have provided here (yours, Watson's Rich's, my modification of= Rich's)
> have the common factor that they require the server to opt-in in some<= br> > way. This has the major advantage that it allows us to design a
> mechanism which might be inconvenient for some network environments > because they can just not opt-in, as well as allowing out-of-band
> delivery of some data in the DNS.
>
> The disadvantage seems to be that a smaller fraction of sites will off= er
> encrypted SNI, which slightly paints
> a target on them. I think that's probably OK, since no matter what= mechanism
> we use for encrypted SNI, it seems likely that an attacker will be abl= e to
> get a good handle on the virtual hosts served by a given site, and so<= br> > can use that to identify which sites he is interested in tracking even= if
> everyone were to use encrypted SNI. However, it's worth considerin= g
> and I'd love to hear from people who want encrypted SNI what they<= br> > think of this tradeoff.
>

True.

I bet that Google, at least, would enable this thing, and there may be
enough pressure on the big CDNs to do it that one or two of them will
as well. =A0At that point, there's already a lot of benefit.

If a proposal like this were adopted, someone should try to prove that
a server that does not know the private key associated with the
ClientHello protection cannot tamper with any legitimate connections
to that domain. =A0If true, this would be a nice bonus. =A0It might pay to<= br> adjust the protocol, if needed, to make such a proof simpler. =A0For
example, the ServerHello could include an extension that proves
knowledge of the ClientHello temporary key. =A0To make that work well,
there would have to be some extra trickery to make sure that big
virtual hosts can strip the ClientHello encryption and still
successfully connect. =A0The existing client random field may already be enough, though.

This does seem like a worth= while goal.

-Ekr
=A0
--001a11c351a4e6263d04f72a3942-- From nobody Wed Apr 16 08: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 1B2611A01AE for ; Wed, 16 Apr 2014 08:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tCpiw1FhbHO for ; Wed, 16 Apr 2014 08:11:58 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5113E1A00FB for ; Wed, 16 Apr 2014 08:11:57 -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=1397661115; x=1429197115; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vxkfk5gPDyF5LiKAkH5LBTcRIydUz3TT2RFmUXSroFc=; b=oyrwhI/Am6uTdTGKrjBlALBZrODojIYwEN3O05UxNmQPtad+r3VHrcgD H3N9IihN+GB7AGYDSIpUDAw+nfa2xupwuWbA/kPzUJmJky+q80tfVujR0 2nOC4ITqUl22QYDWlde+48z+Ts3ljkg1yz44ckEIA//pfJUPi2NbICet/ Y=; X-IronPort-AV: E=Sophos;i="4.97,872,1389697200"; d="scan'208";a="247660435" 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; 17 Apr 2014 03:11:53 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Thu, 17 Apr 2014 03:11:53 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Comments on draft-ietf-tls-encrypt-then-mac Thread-Index: Ac9ZhjJmVUn7PUGXQTmV3a1Mj7ib6A== Date: Wed, 16 Apr 2014 15:11:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC02A1E@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/PZqjB2KsU2CAI3hT3gjkaiY38zk Subject: Re: [TLS] Comments on draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:12:05 -0000 Eric Rescorla writes:=0A= =0A= >2. IMO you should point to draft-moeller in the Security Considerations.= =0A= =0A= Is it appropriate to include a downref to a draft? I'd deliberately worded= =0A= the text to avoid having to do this.=0A= =0A= Peter.=0A= From nobody Wed Apr 16 08: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 881611A0196 for ; Wed, 16 Apr 2014 08:25:39 -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 Iskvj7T4tTPc for ; Wed, 16 Apr 2014 08:25:35 -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 8B9381A01DB for ; Wed, 16 Apr 2014 08:25:34 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so11181492wgh.12 for ; Wed, 16 Apr 2014 08:25: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=1DKL/BIVsSQ1MVcoK+HYeyool+l7yM+mEwe5ZcfEzYA=; b=WI2JPXDN9HjVb6BYV1EKTldWLL5YOaUinZmmISiA449gLFyY9Cbzzkh4Uec1xtLJUL 1ZpRypeCAQ2mZJOLJLqJpKgS5/15HgCkw2W5HguD+YOEHikJpqDZ3Ebx20cWPLe9Oxw5 vUyCcJMFxiRBop/BaUykfVJz82o2dMLqccs4J1W4ziPVr+7Vnt7DIzY3DpaFq1Ky9M8n plIGmOsUvl3eq8zO88ui4dfS1fWq3ttnEG3MkRBn42AnAmGxPeHDPxIgrBFCtuobvOF/ pASg+eOEFIMDB95zYHQrfn2x6Mez05j7tItw9VQSQ3ladZyHG1mFCl++CgJP+u5Yi4SA ppRg== X-Gm-Message-State: ALoCoQm4MfK0a0SG1wIIWGVZqclwXVHYox95Vn3XaUUu/Q2UvHvGRa8UMFAwL1pNus5bQUZLywn6 X-Received: by 10.180.81.228 with SMTP id d4mr19862963wiy.49.1397661930954; Wed, 16 Apr 2014 08:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 16 Apr 2014 08:24:50 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC02A1E@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC02A1E@uxcn10-tdc06.UoA.auckland.ac.nz> From: Eric Rescorla Date: Wed, 16 Apr 2014 08:24:50 -0700 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=f46d043bdb0ee9393304f72a86a1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cyo1mdJ4IDmad2PObUP9DqzycT8 Cc: "" Subject: Re: [TLS] Comments on draft-ietf-tls-encrypt-then-mac X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:25:39 -0000 --f46d043bdb0ee9393304f72a86a1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 16, 2014 at 8:11 AM, Peter Gutmann wrote: > Eric Rescorla writes: > > >2. IMO you should point to draft-moeller in the Security Considerations. > > Is it appropriate to include a downref to a draft? I'd deliberately worded > the text to avoid having to do this. > Yes, you can do that as long as it's informative. With that said, I can see how one might want to do this. Here's what I suggest: put the ref in as informative and then once this has passed the IESG, if it looks like we are going forward with draft-moeller you leave it in and if it looks like we have decided to drop it, you take it out in Auth 48. How does that sound? -Ekr > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043bdb0ee9393304f72a86a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Apr 16, 2014 at 8:11 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Eric Rescorla <ekr@rtfm.com> writes:

>2. IMO you should point to draft-moeller in the Security Considerations= .

Is it appropriate to include a downref to a draft? =A0I'd deliber= ately worded
the text to avoid having to do this.

Ye= s, you can do that as long as it's informative. With that said, I can s= ee how
one might want to do this. Here's what I suggest: put = the ref in as informative
and then once this has passed the IESG, if it looks like we are going = forward
with draft-moeller you leave it in and if it looks like w= e have decided to drop
it, you take it out in Auth 48.

How does that sound?

-Ekr
=A0
Peter.

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

--f46d043bdb0ee9393304f72a86a1-- From nobody Wed Apr 16 09:00: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 D5D5A1A01C0 for ; Wed, 16 Apr 2014 09:00: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 FWL4GIPIiKCM for ; Wed, 16 Apr 2014 09:00:50 -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 C1BB91A01AC for ; Wed, 16 Apr 2014 09:00:50 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so10910856yho.39 for ; Wed, 16 Apr 2014 09:00: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=mAJeAzRHhl0tk5OkYm3+p81DvJIcdC5S9lNxxGwCvcw=; b=eu/vnD8zqCJfB6eNnhNbua3ty0ETd98RSXh7o8n7YBPQN7z6kv8+gBDAYIK8Bn34+Q yx/mNcPoyfY+rP+CodN9l3dwCMdjIDqhdvi6EiaqshG9+of32hULhdCuus+9Lun+gbuJ X4YM5vr8yXAk1fABvlEaAdq3HUjIQncZf+S/rPqkBGgky5oe5aXGSKMllnQYhLug54sE EBTra9JpsF5+Wr+S8JnRELDO0nXVTU2eZDwBCEWcTO1V9j+lO/maEYh2uhnrGudS8Lig pOfoMqXoM8iiOx47wIthc1Q0FfgmBRz/N4Pmk/gCGtCrvLrkxUGjTYEIayY0U/9YAE54 CVfQ== MIME-Version: 1.0 X-Received: by 10.236.198.243 with SMTP id v79mr13524575yhn.87.1397664047332; Wed, 16 Apr 2014 09:00:47 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 16 Apr 2014 09:00:47 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Wed, 16 Apr 2014 09:00:47 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EhjsRP1PEZalrryy7tHvespVeM4 Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:00:52 -0000 Pardon my confusion, but it sounds like we imagine the overlay that hides SNI as not adding a round trip, and thus being intermingled with TLS in negotation. Or is this a matter of encrypting the entire Client Hello packet, then the rest of the connection with the same key, and completing the handshake over this channel, then running the record layer outside? I think that's what Andy's getting at with ECIES (El Gammal only encrypts group elements!) and using the encrypted key in the negotiation. I do worry about DNSSEC deployment+usage here. The local resolver is actively hostile in many censorship regimes as ISPs are part of the system. DNSSEC needs to get to the browser for any information in it to be trusted if you do a lookup in places like Ethiopia, China, or the US on Verizon. Sincerely, Watson Ladd From nobody Wed Apr 16 09:15: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 B0D1B1A021B for ; Wed, 16 Apr 2014 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS41qz_I06Td for ; Wed, 16 Apr 2014 09:15:22 -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 0555A1A0235 for ; Wed, 16 Apr 2014 09:15:22 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 89435284D9; Wed, 16 Apr 2014 16:15:18 +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 6B298284CF; Wed, 16 Apr 2014 16:15:18 +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 4996F202F; Wed, 16 Apr 2014 16:15:18 +0000 (GMT) Received: from Tereva.local (172.19.113.223) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 16 Apr 2014 12:15:17 -0400 From: Brian Sniffen To: Andy Lutomirski , Watson Ladd , "Salz, Rich" In-Reply-To: <534DB18A.4060408@mit.edu> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Wed, 16 Apr 2014 11:15:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xYs9NGQ8XVc8umTWmIAJzrRhYEo Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:15:26 -0000 Andy Lutomirski writes: > On 04/14/2014 10:21 PM, Watson Ladd wrote: >> Now, the best mechanism I can think off would be to use DNS to preload >> a per-IP SNI encryption key, or have the handshake optionally involve >> getting one. But I still can't figure out how to authenticate the >> gotten key without a lot of complexity. The best solution is for the >> client and server to do a DH, then pass the desired website (which >> might get you investigated when the initial handshake is intercepted), >> and have that cert sign the handled DH, then go back and do a TLS >> connection. Ugh. > > What if it were an opt-in thing? A hypothetical DANE extension could > associate with each domain a tuple (ClientHello-protection public key, > TLS version guaranteed to be supported). Clients could resolve that > essentially for free as long as they're already querying DNS, and this > could prevent downgrade attacks and give an efficient way to encrypt the > entire ClientHello. Then the censor looks to see which key is used, yes? > There's a weak argument to be made for arranging for the actual > encrypted ClientHello to be indistinguishable from random by anyone who > doesn't know the private key. This ought to be straightforward using > Elligator. Off the top of my head, it sounds cute, but I don't really > see a benefit. Or does this protect against it? -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Wed Apr 16 09:39: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 6252C1A01F2 for ; Wed, 16 Apr 2014 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRCyurnLg6AG for ; Wed, 16 Apr 2014 09:39:32 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2241A014B for ; Wed, 16 Apr 2014 09:39:32 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id pv20so8492285lab.9 for ; Wed, 16 Apr 2014 09:39: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F9b4EzQ2q13IsuRSlq6pW0zNUIeTz4SB5IgrGH8ZaDM=; b=a6pD427mCVYOf98gUZwP1g+Fu2kOVKvD2ZCyDcbtyMf4PSgXZBaisv//7W4FY2E780 /c4zk0KXjCUgL5bdYQk7LVQpe6OX3Q2sluKIfF4ee8usokoPRmPzjP7Yz1tao9SABOW3 H60nB8gbNqPUe1vlrXRYzzZnInVi4vjnV10hJldgYhjWAlQPdXrc9eQ4hZ7FCIjJdNuS Dy27YvR+QNwRAOJBVsgwqhe+Dg9bb9Ft2cbzp+W82aIiGqosb4Pads8nNi1l+P6J1RMZ BfQyNz+AKHxdNQk7KqEQM+8p6ojYZn3COVSfXI71Z2bDLXRetI8EaJhsr0A/Zz4f1fJN GbNw== X-Gm-Message-State: ALoCoQntfc08lO0QWfJYcXA3oYeZQZlF4TsA0yNuU1aFhe1xNullPVbCYIOUFulNydCNhZ0Lgh73 X-Received: by 10.152.18.229 with SMTP id z5mr6053079lad.27.1397666367903; Wed, 16 Apr 2014 09:39:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 09:39:07 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 09:39:07 -0700 Message-ID: To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/klHYJXchqUiZDpmFrNLm-RnlesE Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:39:36 -0000 On Wed, Apr 16, 2014 at 9:15 AM, Brian Sniffen wrote: > Andy Lutomirski writes: > >> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>> Now, the best mechanism I can think off would be to use DNS to preload >>> a per-IP SNI encryption key, or have the handshake optionally involve >>> getting one. But I still can't figure out how to authenticate the >>> gotten key without a lot of complexity. The best solution is for the >>> client and server to do a DH, then pass the desired website (which >>> might get you investigated when the initial handshake is intercepted), >>> and have that cert sign the handled DH, then go back and do a TLS >>> connection. Ugh. >> >> What if it were an opt-in thing? A hypothetical DANE extension could >> associate with each domain a tuple (ClientHello-protection public key, >> TLS version guaranteed to be supported). Clients could resolve that >> essentially for free as long as they're already querying DNS, and this >> could prevent downgrade attacks and give an efficient way to encrypt the >> entire ClientHello. > > Then the censor looks to see which key is used, yes? > The idea is that the same key would be used for hello encryption for all domains served by the same IP addresses. Even if different keys were used, I'm not sure the censor can tell which. I think that the particular public-key protocol I suggested doesn't leak any information about the public key used to a censor that doesn't know the private key, but I could be wrong. >> There's a weak argument to be made for arranging for the actual >> encrypted ClientHello to be indistinguishable from random by anyone who >> doesn't know the private key. This ought to be straightforward using >> Elligator. Off the top of my head, it sounds cute, but I don't really >> see a benefit. > > Or does this protect against it? > This shouldn't make a difference, since Elligator just makes curve points indistinguishable from any other string of bits, more or less. In this case, the censor already knows that a particular part of the message is a curve point, so Elligator just masks that fact. --Andy From nobody Wed Apr 16 09:53: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 0B77A1A0282 for ; Wed, 16 Apr 2014 09:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI-F6S7r0sJE for ; Wed, 16 Apr 2014 09:53:47 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id DD44F1A026E for ; Wed, 16 Apr 2014 09:53:46 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so8364179lbd.15 for ; Wed, 16 Apr 2014 09:53: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=q1B9Ygy2mxnYbV8GZR8Lv2ALF46RIx8hdkXE1kCRK8Y=; b=co/VvkO7X3e2/oK7c+DUAHqX3jouFSfrOX63xb7/ugKo6O9quKRSe8nxYc7tFYauox 2yS66DOzHZa9J+ZlqhrluRF/I8dHpXj0pdboP1pgpGIhjf0nDyjMO+vVUEbs9NZmAF+K wQE8tkU1Oc7WAaA9CaOJwrtQEC96doHjYAtJyl516nSsPqfjJo7zcxsgK1xPlSFhYnyc 0SzAANWtMkxUWHgdw/PlMULFymglpCqMJlqYgbyhRzKED150F6xhr1plAtMjq+VtY0iw EH9kwY3yhW63qOoj+/g4bXFMex0mtX7OH56PzTgWVkh+pDtrYxZFQeX4PvXkbMLVEXmU mhFA== X-Gm-Message-State: ALoCoQk8/0D7tJGEFWv1axVV21CLBMCEE7WrYS/vwScRz0ahFDJMlP1/mbIPUlMH4ebyg63/Apsr X-Received: by 10.152.18.170 with SMTP id x10mr1887401lad.55.1397667222985; Wed, 16 Apr 2014 09:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 09:53:22 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 09:53:22 -0700 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M5vQF_REauUQ4mEFJCLw5I25eME Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:53:50 -0000 On Wed, Apr 16, 2014 at 9:00 AM, Watson Ladd wrote: > Pardon my confusion, but it sounds like we imagine the overlay that > hides SNI as not adding a round trip, and thus being intermingled with > TLS in negotation. Or is this a matter of encrypting the entire Client > Hello packet, then the rest of the connection with the same key, and > completing the handshake over this channel, then running the record > layer outside? Neither. I'm actually suggesting encrypting just the ClientHello to simplify allowing very large virtual hosts to receive an encrypted hello, decrypt it, and hand the entire connection off to something else that doesn't need to know about encrypted hellos. A more complicated approach would be to encrypt the whole handshake and then run the record layer outside. This would have the added benefit of protecting the server's choice of cipher suite, which may be important. To make this work, the client would have two choices: Header indicating encrypted ClientHello || encrypted handshake session key || encrypted ClientHello or Plaintext ClientHello, with extension giving a plaintext session key to use to encrypt the rest of the handshake The latter adds no security whatsoever, but it does allow a virtual server to decrypt the encrypted client hello, add the extension, and then hand off the connection. Other variants are possible, of course. My goal here is to keep this as painless as possible for large CDNs, to minimize the degree to which the state machine gets more complicated, to add no roundtrips, and to still protect the ClientHello in cases where the client has access to valid DNSSEC data. > I think that's what Andy's getting at with ECIES (El > Gammal only encrypts group elements!) and using the encrypted key in > the negotiation. > Yes, you're right. This is ECIES, not ElGamal. I'm not a real (classical) cryptographer, so my terminology may be wrong, and any security claims I make should be taken with a giant grain of salt. > I do worry about DNSSEC deployment+usage here. The local resolver is > actively hostile in many censorship regimes as ISPs are part of the > system. DNSSEC needs to get to the browser for any information in it > to be trusted if you do a lookup in places like Ethiopia, China, or > the US on Verizon. > Paul Wouters is working on having hosts run their own DNSSEC-validating resolvers. I have the prototype he suggests installed on my laptop, and it works so far. Then again, I'm on one of the friendliest ISPs around. We'll see how it goes. I do expect that, some day, a large fraction of browsers will either validate DNSSEC themselves or will be able to talk to something else on the same machine that validates DNSSEC. I should mention that there's an ugly corner case with my suggestion. If a given domain is served by multiple virtual hosts, load balanced by multiple AA/AAAA records, either they need to share the same ClientHello key, or the data in DNS needs to indicate which IP goes with which ClientHello key. In practice this may not be very common. --Andy From nobody Wed Apr 16 09:54: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 8F2731A025A for ; Wed, 16 Apr 2014 09:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo1kQ7o_rSfo for ; Wed, 16 Apr 2014 09:54:13 -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 27EBC1A0258 for ; Wed, 16 Apr 2014 09:54:13 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D211748276; Wed, 16 Apr 2014 16:54:09 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id BB4C348273; Wed, 16 Apr 2014 16:54:09 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8A1A01E03D; Wed, 16 Apr 2014 16:54:09 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 16 Apr 2014 12:54:07 -0400 From: "Sniffen, Brian" To: Andy Lutomirski Date: Wed, 16 Apr 2014 12:54:06 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9ZlHrqPWDyEh6gSqy5zIHp95J42A== Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_58D3ECD9-8399-482C-BAE0-F4977C6A96AF"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F9aGubHprFN5jjimRXprbWIlApg Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:54:17 -0000 --Apple-Mail=_58D3ECD9-8399-482C-BAE0-F4977C6A96AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 16, 2014, at 11:39 AM, Andy Lutomirski = wrote: > On Wed, Apr 16, 2014 at 9:15 AM, Brian Sniffen = wrote: >> Andy Lutomirski writes: >>=20 >>> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>>> Now, the best mechanism I can think off would be to use DNS to = preload >>>> a per-IP SNI encryption key, or have the handshake optionally = involve >>>> getting one. But I still can't figure out how to authenticate the >>>> gotten key without a lot of complexity. The best solution is for = the >>>> client and server to do a DH, then pass the desired website (which >>>> might get you investigated when the initial handshake is = intercepted), >>>> and have that cert sign the handled DH, then go back and do a TLS >>>> connection. Ugh. >>>=20 >>> What if it were an opt-in thing? A hypothetical DANE extension = could >>> associate with each domain a tuple (ClientHello-protection public = key, >>> TLS version guaranteed to be supported). Clients could resolve that >>> essentially for free as long as they're already querying DNS, and = this >>> could prevent downgrade attacks and give an efficient way to encrypt = the >>> entire ClientHello. >>=20 >> Then the censor looks to see which key is used, yes? >>=20 >=20 > The idea is that the same key would be used for hello encryption for > all domains served by the same IP addresses. Oh, I see. But the US government customers want a key to a NIST scheme = generated with Dual_EC, and the notional non-government entities want = anything but that. > Even if different keys were used, I'm not sure the censor can tell > which. I think that the particular public-key protocol I suggested > doesn't leak any information about the public key used to a censor > that doesn't know the private key, but I could be wrong. But they want different protocols. So we drift to having the = censor-approved data on one IP, and the censor-opposed data on another = IP. I see the benefit of the wildcard proposal=97it seems to help small = users who don=92t really get a say in their crypto, and just use = example.tumblr.com and similar, where there=92s a bunch of innocent = social data mixed in with the politically interesting parts. I don=92t = see how encrypted SNI helps preserve the privacy of the clients of a big = web site against the adversaries I understand to oppose such. -Brian --Apple-Mail=_58D3ECD9-8399-482C-BAE0-F4977C6A96AF 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 - http://gpgtools.org iQEcBAEBAgAGBQJTTrWuAAoJEKC8r+lsJnHJkX0H/2pBhAeqZR3CzxCKDj8hJOEU bFSSAs146b0UM35/x/6jDeRYUncwYTHlP6wsUhkTL/fojiu0QdbNy73xSByxlyi7 vYU/22ldDvFKyG/jYgTJjRpWPpF70Mmohj+Pua177RycL+2mXeVZ5jDk7ymMpb3u G9bfKv8KlBnQmwDYJd/bDdvp7Bi9FsHXYTTE9nKEcao0MqSqZp0SUQiRtDIr40zA nriaU/8M8G+V8H5AxUCm8Nent9WHIdGsHv0GTHFhSxR2+4g5ogVl6gE0PenfzoT0 WYlmj/1G8QhonPEcRQT+JfQRm70alrGqfxlFu8WnF/uHMdZuHUWO/9dXDifDPwc= =aYoo -----END PGP SIGNATURE----- --Apple-Mail=_58D3ECD9-8399-482C-BAE0-F4977C6A96AF-- From nobody Wed Apr 16 10:22: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 608441A0260 for ; Wed, 16 Apr 2014 10:22:37 -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_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 JeNvNaI1JJOk for ; Wed, 16 Apr 2014 10:22:33 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 17B621A024F for ; Wed, 16 Apr 2014 10:22:32 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so8298844lan.40 for ; Wed, 16 Apr 2014 10:22:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1sEPuSbwhhZUVIveZ+yYF3Pxb5pArkapInBYrlnWQbw=; b=YhszUUIZxt7TJ++30vPo8OZaOOXmq4UHyuAxokrl+2BU1aNWgWqiwwmNpbAHNM+ZMf atdeOs+6eixy4WF3dtaWwdbfwUfdbF66dUVn6kUj/mzPo1ms6bVGJnmL1qbP895i5zmi UcKCMOokZP4sB2mOP+Ui/guryvbkyNtv1e4fmyZNeAgwOlpGhn0XJb9Bv7qh18o8UMWi w81c1zeiUooOJUocY1yTJDOeG1tGrIfNa78ZClPKBY7J+cBra+yynQYDCv5U6B0crVes n94hS+0wILOqiZlN2KehbGjFILgYrJZ1S3PF9vIWrtCO8HAaPPdw/o9GR/dhCgZhapSF bQrg== X-Gm-Message-State: ALoCoQnjNFPliLrRv1S/NlE7atLKOo8rTKap9wrDFafecV+02K4LP4mJE07d4d7rrBHe+rvGwDoN X-Received: by 10.112.134.230 with SMTP id pn6mr3598343lbb.37.1397668949074; Wed, 16 Apr 2014 10:22:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 10:22:08 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 10:22:08 -0700 Message-ID: To: "Sniffen, Brian" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0BY2GIKmhVysMqGtYlGJ7zOof2s Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:22:37 -0000 On Wed, Apr 16, 2014 at 9:54 AM, Sniffen, Brian wrote: > > On Apr 16, 2014, at 11:39 AM, Andy Lutomirski wrote: > >> On Wed, Apr 16, 2014 at 9:15 AM, Brian Sniffen wrote: >>> Andy Lutomirski writes: >>> >>>> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>>>> Now, the best mechanism I can think off would be to use DNS to preload >>>>> a per-IP SNI encryption key, or have the handshake optionally involve >>>>> getting one. But I still can't figure out how to authenticate the >>>>> gotten key without a lot of complexity. The best solution is for the >>>>> client and server to do a DH, then pass the desired website (which >>>>> might get you investigated when the initial handshake is intercepted), >>>>> and have that cert sign the handled DH, then go back and do a TLS >>>>> connection. Ugh. >>>> >>>> What if it were an opt-in thing? A hypothetical DANE extension could >>>> associate with each domain a tuple (ClientHello-protection public key, >>>> TLS version guaranteed to be supported). Clients could resolve that >>>> essentially for free as long as they're already querying DNS, and this >>>> could prevent downgrade attacks and give an efficient way to encrypt the >>>> entire ClientHello. >>> >>> Then the censor looks to see which key is used, yes? >>> >> >> The idea is that the same key would be used for hello encryption for >> all domains served by the same IP addresses. > > Oh, I see. But the US government customers want a key to a NIST scheme generated with Dual_EC, and the notional non-government entities want anything but that. > >> Even if different keys were used, I'm not sure the censor can tell >> which. I think that the particular public-key protocol I suggested >> doesn't leak any information about the public key used to a censor >> that doesn't know the private key, but I could be wrong. > > But they want different protocols. So we drift to having the censor-approved data on one IP, and the censor-opposed data on another IP. OK, I see the problem here. Three possible solutions: 1. US government customers can just skip setting the DNSSEC option. The same IP can host encrypted and unencrypted ClientHello users. 2. See if Curve25519 can be used in an encrypted ClientHello even with FIPS certification. The argument would be that this isn't really cryptography, since it's just an additional layer on top of something that's already certified. I don't know whether this would fly. 3. Use something like Elligator. This slows down the server a little bit, since it will have to attempt to decrypt the ClientHello once for each possible key, but there only really need to be two keys here. This needs some padding trickery -- see below. I don't think that Elligator works for NIST curves, but Elligator Squared seems to. I actually like #3, despite its complexity, because it allows the entire encrypted ClientHello payload to be indistinguishable from random. This is a further argument for adding a little bit more complexity to allow the rest of the handshake and the record layer to be indistinguishable from random as well. If nothing else, this will make it much easier to extend things in the future, since middle boxes that support TLS 1.3 won't be able to peek inside and screw up future extensions. IIUC the TLS 1.2 record layer is easily distinguishable from random. To keep everything on one page, here's the updated strawman: DNS indicates, for each domain: (cryptosystem, public key, guaranteed TLS version) Cryptosystems include: Non-US-government-preferred choice: ECIES/Elligator on Curve25519, with ChaCha20+Poly1305 AEAD. US-governement-preferred choice: ECIES/Elligator Squared on P-256, with AES-128-GCM. If the client sees one of these DNS records, it sends: ClientHello wrapper || f(a*G) || IV || AEAD(real ClientHello) The function f is either Elligator 2 or Elligator Squared, as appropriate. If Elligator is being used, the client needs to try an average of two times to get a value of a that works. The client is expected to include a padding extension in the real ClientHello with a length calculated to hide the length of the SNI and the length of the ECIES header. The real ClientHello will contain a further extension that contains a session key that will be used to encrypt the rest of the handshake and indicates the cipher suite. This cipher suite MUST be exactly the same as the one used for the ClientHello (ChaCha20+Poly1305 or AES-128-GCM, respectively). The server tries to decrypt the ECIES payload with each of its keys. This is quite fast, unless P-256 is supported, in which case it's still not that bad. It then proceeds exactly as it would if the real ClientHello were sent in the clear. In particular, it does not need to remember the ECIES session key. If the encrypted ServerHello extension is in use, then the ServerHello and all remaining handshake messages are encrypted as specified. This happens regardless of whether the ClientHello is encrypted. If TLS 1.3 plans on encrypting the ServerHello anyway in a manner that is indistinguishable from random, then the extension part of this strawman can be dropped. I don't see why FIPS certifiers would object to the use of Elligator Squared. It's just a transformatoin of the bytes before they are sent on the wire. --Andy From nobody Wed Apr 16 10:31: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 AC0D51A01C9 for ; Wed, 16 Apr 2014 10:31:57 -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 TV-fdvNpkZXq for ; Wed, 16 Apr 2014 10:31:53 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBB1A024F for ; Wed, 16 Apr 2014 10:31:53 -0700 (PDT) Message-ID: <534EBE88.2000700@akr.io> Date: Wed, 16 Apr 2014 18:31:52 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vs3xX87sV2EUZyfahnZQRr2-U1A Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:31:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/04/2014 17:54, Sniffen, Brian wrote: >> The idea is that the same key would be used for hello encryption >> for all domains served by the same IP addresses. > Oh, I see. But the US government customers want a key to a NIST > scheme generated with Dual_EC, and the notional non-government > entities want anything but that. Let them have a parallel cryptosystem, then? We can put a cryptosystem ID in the DNS record (as I just see, while replying, that Andy has suggested). That also provides scope for agility. I'm not sure approval (or otherwise) from any government in particular should stifle developments in this WG, especially in today's climate. Perhaps NIST would consider adopting our work, when it is finished. After everything that's happened, even being mindful of the general effect they have on the market, I think you can understand that the other way around is far less palatable. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTr6IAAoJEOyEjtkWi2t6ADAP/ig1EfGreOm4qb8G9FZEC61i 1EKq7Q1vjFVy6o5rWSbGbHR5tYEZWkjy+3/x8wCpzH+GUQewn8KFMJZbW7TMCTQr DL8jaT/ZipU5XzQSpflYuICCsqqAAHKHPMX74Fwfn1zs63N21GYTn/+wr/Ls1jKU D/O9yksZjwhbx8H1IOGpk7Ht6vofFZoFvV1cGFtVTNukNnuwDQ0kqk/lYJlBtl/v WIptOnP+fgceoXYN0OeRVTK0nH8AofxwcSXLVtPDd+/xk5h1j/6UhKr0VcQZyvaO T2WizIq9zuhaNWCNWf6NoKmFFoDve2FgKJRxXeOEpMS+6w71PiasKseRe0pCVpN3 XQBcoYsPeE+KN7OhnSnRIGbezLgDQM7ALIeW2AgM+u2hMi8JeYwZC1lGdoWOkQv9 xSoCX70tf3el/cSARkM+vBXy2FZDNRxPdTcVptHg7tJunick9rvJPYG6eIrZ4rZM EiRmqtnyNlX9I/SHHbEvcD2iwTaEi4hbRLsSp9UJZdmB+6KGGqhIeewD6hNwHuRw ODw0L7CJd6KshOwaKQEMpje+6AkwRTffLSiU0rl1eFsrdmCkyVpG9cvKEdPi9Pn3 ObNRUcwu1/2CRRWPduahZcwhYLxleS+6es695YLCdWkJaDzdlHrHvgxCz94O337+ YcESjuil0Y8CxNNOoie+ =+Dff -----END PGP SIGNATURE----- From nobody Wed Apr 16 11:09: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 7D8451A0227 for ; Wed, 16 Apr 2014 11:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdDh3BDTwg-k for ; Wed, 16 Apr 2014 11:09:21 -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 B327B1A02AF for ; Wed, 16 Apr 2014 11:09:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 66F2510468 for ; Wed, 16 Apr 2014 14:09:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=SJ5yTc0m9qvE wwCRPMYW+QzHEM0=; b=KqOkvU/dggG5/y+6bDKbkXE0nz/4NqZ6SslsgYj7Npmr 4qJD5MFsukjsFkfa8JSSguqP3oo5tEpR/cyv51wQ3cRGPbfgCqOuEuySUY1uV7+5 4WBGbGSwQiN0f8RaaCEX/w75rAB0S6t5agd+dofpL9TpZwlBwNXvjbzbQLLtFCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=eBlPch GerbHXrHoNWN/bpzF8cLiw115bzzRbeazB8uE6/ZfouL+yjbRGzWSGB5wnhQd/uO SZ/dRnLaKWMJbL6g1E/f7IZqrG5pBFx7LGttG8TTUy+9wLIXP0Xr2BqFBMZKyJWN 5rGoV7j7eBpb0y0Us7XVcYV2OG00pYQB/cZRQ= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5D8DD10467 for ; Wed, 16 Apr 2014 14:09:16 -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 C60A310466 for ; Wed, 16 Apr 2014 14:09:14 -0400 (EDT) Message-ID: <534EC749.90609@pobox.com> Date: Wed, 16 Apr 2014 11:09:13 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "tls@ietf.org" References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 38234806-C592-11E3-94E2-873F0E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4yjc_G1Ojg6lHiUg5CQH4QywT6k Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:09:26 -0000 > [several suggestions to use DNS for this or that elided] Currently TLS clients only need to use DNS to determine the IP address of the server. Do we really want to start leaning heavily on DNS for anything else? I'm skeptical.... Mike From nobody Wed Apr 16 11:44:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3CD1A01DD for ; Wed, 16 Apr 2014 11:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrQasjQfwb7r for ; Wed, 16 Apr 2014 11:44:35 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48E1A0201 for ; Wed, 16 Apr 2014 11:44:35 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 0BFC71E0E1; Wed, 16 Apr 2014 18:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1397673871; bh=MXkSe/kJGcsSvgyrGBGOjaXfbY0FAl4PXiyAuzWzaBM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BJJerp8hoMjZe8wjNO1eReYz4tkn0rWBRx/6GZTD6Xm9j/Ra8X5jXglWAgL2swhqK 5vQk3NEkCUAU1zwHZyyjaYElOlgnR873JnvvczYgLF7hFX25pnh2lqhkg+utkCdmGl cJPjexYJ9I+AU7rHy4c+ya2PMa9smEooOC0xR524= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5F42D6001D; Wed, 16 Apr 2014 18:32:13 +0000 (UTC) From: James Cloos To: In-Reply-To: (Andy Lutomirski's message of "Wed, 16 Apr 2014 10:22:08 -0700") References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 16 Apr 2014 14:32:13 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140416:tls@ietf.org::6qgFjilHpzyQET0p:0000iucPG X-Hashcash: 1:30:140416:luto@amacapital.net::XpTUuTfJIgQAqnDP:00000000000000000000000000000000000000000WmzGu X-Hashcash: 1:30:140416:bsniffen@akamai.com::N/RSN+UJTJf7XLmZ:00000000000000000000000000000000000000000ndYGL Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UxddXKMdGh1ffL5n9o1-KhYah9w Cc: Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:44:40 -0000 >>>>> "AL" == Andy Lutomirski writes: AL> US-governement-preferred choice: ECIES/Elligator Squared on P-256, AL> with AES-128-GCM. DJB's parallel paper (http://cr.yp.to/snuffle/bruteforce-20050425.pdf) implies all should s/AES-128/AES-256/g. Especialy when there is a significant quantity of traffic available for probabilistic attacks. (I presume those who like NIST crypto will be happy with AES256-GCM-SHA384.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Wed Apr 16 11:47:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191A1A0213 for ; Wed, 16 Apr 2014 11:47:16 -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 CjIkN6inAhjh for ; Wed, 16 Apr 2014 11:47:12 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 42BAD1A01E5 for ; Wed, 16 Apr 2014 11:47:12 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x3so12404733qcv.12 for ; Wed, 16 Apr 2014 11:47:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fj+BeDYnawE29KreKMTv3js/qrqVzXYnSkEd0eyWxA0=; b=fbXpL+PrLyEspcg+U5Q3CBRv2E7FQzC+NJe7rISv2vRFMJcJjRCHIvmgte9uauXNtQ dTeLqzYOU+RuDbdraiuihWGStrGjtPPDQVRH/9ZHjHbbyzWc2sFByH8kAWy/3jO4TH44 JyswYzKM02m07K226PGvOfMYbf94oMaBliMHezKr8l+05QOWvp18Sk/47QYWQeK2IRdH i55Wa9Epboxw9kQpPD5cE3yNTMpWPtQtTG22JHvObYTgbtHPqzdE8vRHXuA06M8gQZkW Y3t/VAhQItTA+TzfpMn3UDO4kR1EYv0b8a8yDbC8svc6tB1ktkyvyj5FAki7MCksST2m sG6g== X-Gm-Message-State: ALoCoQlZtF3Ak/QFRlJH8/ezuWOzk7iRiITdNb87Or11kN5Qw9fNQQqYh3bQrC9fQJ8ruDxT4EM4 MIME-Version: 1.0 X-Received: by 10.140.48.77 with SMTP id n71mr4712333qga.90.1397674028761; Wed, 16 Apr 2014 11:47:08 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Wed, 16 Apr 2014 11:47:08 -0700 (PDT) X-Originating-IP: [109.163.234.10] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Wed, 16 Apr 2014 18:47:08 +0000 Message-ID: From: Jacob Appelbaum To: Brian Sniffen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RKQWS1dv-F83vofIoY4SGiKnOls Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:47:16 -0000 On 4/16/14, Brian Sniffen wrote: > Andy Lutomirski writes: > >> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>> Now, the best mechanism I can think off would be to use DNS to preload >>> a per-IP SNI encryption key, or have the handshake optionally involve >>> getting one. But I still can't figure out how to authenticate the >>> gotten key without a lot of complexity. The best solution is for the >>> client and server to do a DH, then pass the desired website (which >>> might get you investigated when the initial handshake is intercepted), >>> and have that cert sign the handled DH, then go back and do a TLS >>> connection. Ugh. >> >> What if it were an opt-in thing? A hypothetical DANE extension could >> associate with each domain a tuple (ClientHello-protection public key, >> TLS version guaranteed to be supported). Clients could resolve that >> essentially for free as long as they're already querying DNS, and this >> could prevent downgrade attacks and give an efficient way to encrypt the >> entire ClientHello. > > Then the censor looks to see which key is used, yes? Keys are free - names and signatures are not. The good news is that signatures may be regenerated at a low cost depending on the systems; the bad news is that names generally can't change without a lot of effort on both the client and the server side. > >> There's a weak argument to be made for arranging for the actual >> encrypted ClientHello to be indistinguishable from random by anyone who >> doesn't know the private key. This ought to be straightforward using >> Elligator. Off the top of my head, it sounds cute, but I don't really >> see a benefit. > > Or does this protect against it? > I have previously hoped for a TLS (handshake, protocol, implementation, etc) that actually considers that an attacker will try to distinguish users and then treat them differently, eg: attacking them, even with a simple DoS. We see this often with the Tor network. We once were blocked in Iran because we used a specified prime from the relevant RFC - it turns out nearly no one else was impacted because they used another prime. We changed the primes on the server to be dynamically generated and the network was unblocked without a client side update. Fixed identifiers or patterns in protocols are how censors target specific users and protocols for censorship. The SNI in TLS is the most obvious and easy distinguisher and it also suggests that privacy isn't actually a cohesive security property of Transport Layer Security. Not every TLS service uses DNS simply because it may also use names. Names aren't only used in DNS. Just as there is more to the internet than the world wide web, there is more to naming than the DNS. Also, while I sympathize to the Akamai use case, I think that the problems created with some kinds of centralization here should not be over looked. That there are thousands of hosted sites/services on a single IP is clearly something that needs to be supported. Is it really only by ensuring that *everyone* that uses TLS is leaking information to the network? I think there are probably other options... All the best, Jacob From nobody Wed Apr 16 11:55: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 B45341A01C9 for ; Wed, 16 Apr 2014 11:55:54 -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 vTfMIX0qrbbG for ; Wed, 16 Apr 2014 11:55:50 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEE21A01DD for ; Wed, 16 Apr 2014 11:55:49 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so8611494lbd.29 for ; Wed, 16 Apr 2014 11:55:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W0Az49bU2weYSOVxG029l0xySX473eq0b1WOtgBJBMg=; b=mtCFXnXQRsoNO2Oax7eKhgn/u8oUWtAeHRe9r2QH1Y2kaO4ywEjztFUPNGHn+JCx7P YODuNQ5NqJsf0LvtSlgDATpwjPPmqN+4LXE9iJiKUekumlw58MBAHLbTHwzZVQhQeLSs Pf2CTaRrxzGd5/2zavfl1MTyNBs78ok9huvifsg4XoW6zzDiXaarVnMZKlWR4XtAAsPn bZAGfeFDjbxQDjeTAmn6EGqxlHg1LL1xp2I3xp46hI/9lclbu07eOEVK1Ce+kDzeqXsf MSrl/ZZdbR7Sc14r6BiaAXxrDOUnlbxj+Q2QmtXDtJ2bifI1GWiWBS3/qD5zPHSYfCM8 MzMg== X-Gm-Message-State: ALoCoQn0Dt7yUhEkWYI/lzy9Rq9DcHCBnlCseOqsLTvzNKlz4W01SqfzFX5DqPrtHM8QxVai3W3s X-Received: by 10.152.234.130 with SMTP id ue2mr6603102lac.0.1397674546110; Wed, 16 Apr 2014 11:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 11:55:25 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 11:55:25 -0700 Message-ID: To: Jacob Appelbaum Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YhB0JNys8eU0M1Oum7wiRiP-idE Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:55:54 -0000 On Wed, Apr 16, 2014 at 11:47 AM, Jacob Appelbaum wrote: > On 4/16/14, Brian Sniffen wrote: >> Andy Lutomirski writes: >> >>> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>>> Now, the best mechanism I can think off would be to use DNS to preload >>>> a per-IP SNI encryption key, or have the handshake optionally involve >>>> getting one. But I still can't figure out how to authenticate the >>>> gotten key without a lot of complexity. The best solution is for the >>>> client and server to do a DH, then pass the desired website (which >>>> might get you investigated when the initial handshake is intercepted), >>>> and have that cert sign the handled DH, then go back and do a TLS >>>> connection. Ugh. >>> >>> What if it were an opt-in thing? A hypothetical DANE extension could >>> associate with each domain a tuple (ClientHello-protection public key, >>> TLS version guaranteed to be supported). Clients could resolve that >>> essentially for free as long as they're already querying DNS, and this >>> could prevent downgrade attacks and give an efficient way to encrypt the >>> entire ClientHello. >> >> Then the censor looks to see which key is used, yes? > > Keys are free - names and signatures are not. The good news is that > signatures may be regenerated at a low cost depending on the systems; > the bad news is that names generally can't change without a lot of > effort on both the client and the server side. > I'm not sure I understand what you mean. >> >>> There's a weak argument to be made for arranging for the actual >>> encrypted ClientHello to be indistinguishable from random by anyone who >>> doesn't know the private key. This ought to be straightforward using >>> Elligator. Off the top of my head, it sounds cute, but I don't really >>> see a benefit. >> >> Or does this protect against it? >> > > I have previously hoped for a TLS (handshake, protocol, > implementation, etc) that actually considers that an attacker will try > to distinguish users and then treat them differently, eg: attacking > them, even with a simple DoS. > > We see this often with the Tor network. We once were blocked in Iran > because we used a specified prime from the relevant RFC - it turns out > nearly no one else was impacted because they used another prime. We > changed the primes on the server to be dynamically generated and the > network was unblocked without a client side update. Fixed identifiers > or patterns in protocols are how censors target specific users and > protocols for censorship. The SNI in TLS is the most obvious and easy > distinguisher and it also suggests that privacy isn't actually a > cohesive security property of Transport Layer Security. > > Not every TLS service uses DNS simply because it may also use names. > Names aren't only used in DNS. Just as there is more to the internet > than the world wide web, there is more to naming than the DNS. I think that my updated proposal should work for you, as long as Tor has some other way to distribute the same data that's normally in the DNS record. I imagine that it could be distributed along with the IP addresses of entry nodes. Am I missing something here? My proposal, as currently written, results in the encrypted form the the TLS handshake looking like a fixed header (ClientHello TLS version whatever, throw-away values in fixed fields, extension prefix for the actual encrypted Clienthello) followed by data that is indistinguishable from random due to the use of Elligator 2 / Elligator Squared. If non-Tor sites adopt this, then Tor traffic will look just like everything else. --Andy From nobody Wed Apr 16 11:56: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 AEAE11A02A8 for ; Wed, 16 Apr 2014 11:56: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 97lGEcsE_VZy for ; Wed, 16 Apr 2014 11:56:32 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9AED31A02A7 for ; Wed, 16 Apr 2014 11:56:31 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so11050788vcb.6 for ; Wed, 16 Apr 2014 11:56:28 -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=VgBe//Onpfj5Wjsz3Hi1Av6kyMGuCrrDQhHFZebkW+4=; b=m1RjnKZB3aNh0E0EvmUMHZz0swGOY3XeL+RoSW8Ntmoe+ziEJWFXZciMsqPdSCYB3J PI9i0u4jN+7Bn6gXVyRGX4fwqukHh0ypE6e/QISVthNc+miGDl+NOVWolSK7QHVJYHTm Q01BBoSGd6V1TAtcjYSP25k+lc96i4WdgaAP/7UgI9q6kxo5HR4Yqo1ynETzAK6MxynJ dGB/0A4RCngJfz/K1vtlKN3UzBb5k93xWfs766y1x8LiSV90gxBjB72HhH2vRXeS5W8a 33tvFIyrvgbMyvn9+y68Oxj42RM0aJDslJZ1oPw0xEG1nO51irBPuWrsU+5FNEUovK9x 0VgA== MIME-Version: 1.0 X-Received: by 10.52.3.129 with SMTP id c1mr1497102vdc.37.1397674588137; Wed, 16 Apr 2014 11:56:28 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Wed, 16 Apr 2014 11:56:27 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Wed, 16 Apr 2014 14:56:27 -0400 X-Google-Sender-Auth: Xs5TE0dLhXtOqsqLKJIfK-J_V6Y Message-ID: From: Erik Nygren To: Andy Lutomirski Content-Type: multipart/alternative; boundary=20cf30363731566d6e04f72d7983 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OLdgDMZwkTSEiDj53IjeMeRoclg Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:56:36 -0000 --20cf30363731566d6e04f72d7983 Content-Type: text/plain; charset=UTF-8 If we do anything with DNS, we need to be very conscious that individual records change asynchronously from other records. For example, we can't assume that an A/AAAA record and a DANE record refer to the same operator (webserver, hosting provider, CDN, etc). In order for anything along these lines to be deployable, it must be possible for everything associated with a particular name->service binding to change together. In addition, browser vendors are extremely wary of doing extra DNS lookups synchronous to a request which is one reason that SRV records aren't in-use today for HTTP(S). After thinking about this some, if we are looking towards a future world where additional DNS security and privacy has been added, a new "service binding" record type (I'll call it a "B-record") might help partially address a number of these issues and raise the bar a little about SNI privacy. The B-record would glue together information needed for establishing a connection (and provide a client with a number of options to choose from). For example: _https._b.www.example.com B "AAAA=2001::abcd, port=443, alpn=h2s, handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335, pri=5, dane_cert_name=version83.ca.example.com" _https._b.www.example.com B "A=1.2.3.4, port=443, alpn=h2s, handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335, pri=5, dane_cert_name=version83.ca.example.com" _https._b.www.example.com B "A=1.2.3.5, port=443, alpn=h1s, handshake_ecdhe_key=438nkgj8utjs89we0t8tjer, handshake_token=asdjhk887, pri=3, dane_cert_name=version82.ca.example.com" Defines a set of HTTPS service bindings for a few sets of IP addresses with different ALPN settings. In the above, the handshake_ecdhe_key is the public part of the server key to encrypt the handshake (including SNI to and the handshake_token is the "opaque" value from ekr's flows proposal. Clients could select between which of them they'd use based on their ALPN support. At least for HTTP(S), something like this might be more deployable than current options. Note that the handshake_token (sent in the clear in the TLS handshake like the "opaque" value) will leak information to passive attackers who are building up correlation tables. Also if the key is used *only* for the handshake, it's not clear that this is any worse against active attackers even if DNSSEC is not used than the "new flows" proposal. (In both cases a MitM can provide an alternate handshake key or build up a table of ids to SNIs.) Clearly DNSSEC would need to be used for *every* step before DANE could be used, however. I think the question from above arises of whether it is worth doing all of the engineering work here if there's still no fundamental way to guard against active attackers or resourceful passive attackers. Some of this will come down to trade-offs. Erik On Wed, Apr 16, 2014 at 10:39 AM, Andy Lutomirski wrote: > On Wed, Apr 16, 2014 at 7:32 AM, Brian Sniffen > wrote: > >> Furthermore, no offence to Rich, but I suspect if you told him "We'll > >> build the DNS subdomain forwarding, and you can use that or just not > >> encrypted SNI", he will choose not to use it. Maybe I'm wrong, but > >> since he argued against it initially, I'll make the leap. So making > >> it opt-in seems to be as equivalent to building an optional feature > >> that almost no one will use from the beginning. > > > > Yes: we will not use encrypted SNI. We can't. We need to put thousands > > of HTTP hosts with incompatible crypto requirements on each IP address. > > Per-IP keys don't help us very much. > > Would a protocol along the lines of my strawman work for you? I > explicitly did not require that the eventual cipher suite match for > different SNI values. I even made it possible to for whatever > receives the initial SSL connection to strip the SNI encryption and > hand the connection of to something else, without sharing any > long-term secrets between the machines in question. > > --Andy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --20cf30363731566d6e04f72d7983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we do anything = with DNS, we need to be very conscious that individual records change async= hronously from other records.=C2=A0 For example, we can't assume that a= n A/AAAA record and a DANE record refer to the same operator (webserver, ho= sting provider, CDN, etc).=C2=A0=C2=A0 In order for anything along these li= nes to be deployable, it must be possible for everything associated with a = particular name->service binding to change together.=C2=A0 In addition, = browser vendors are extremely wary of doing extra DNS lookups synchronous t= o a request which is one reason that SRV records aren't in-use today fo= r HTTP(S).

After thinking about this some, if we are looking towards a futur= e world where additional DNS security and privacy has been added, a new &qu= ot;service binding" record type (I'll call it a "B-record&quo= t;) might help partially address a number of these issues and raise the bar= a little about SNI privacy.=C2=A0 The B-record would glue together informa= tion needed for establishing a connection (and provide a client with a numb= er of options to choose from).=C2=A0 For example:

=C2=A0=C2=A0=C2=A0=C2=A0 _https._b= .www.example.com B=C2=A0 "AAAA=3D2001::abcd, port=3D443, alpn=3Dh2= s, handshake_ecdhe_key=3D68sgjbjfsd8fyjgbsgd7863, handshake_token=3D5sdfkj3= 35, pri=3D5, dane_cert_name=3Dv= ersion83.ca.example.com"
=C2=A0=C2=A0=C2=A0=C2=A0 _https._b.www= .example.com B=C2=A0 "A=3D1.2.3.4, port=3D443, alpn=3Dh2s, handsha= ke_ecdhe_key=3D68sgjbjfsd8fyjgbsgd7863, handshake_token=3D5sdfkj335, pri=3D= 5,=C2=A0 dane_cert_name=3Dversi= on83.ca.example.com"
=C2=A0=C2=A0=C2=A0=C2=A0 _https._b.www= .example.com B=C2=A0 "A=3D1.2.3.5, port=3D443, alpn=3Dh1s, handsha= ke_ecdhe_key=3D438nkgj8utjs89we0t8tjer, handshake_token=3Dasdjhk887, pri=3D= 3,=C2=A0 dane_cert_name=3Dversi= on82.ca.example.com"

Defines a set of HTTPS service bindings for a few sets of IP addr= esses with different ALPN settings.=C2=A0

In the above, the h= andshake_ecdhe_key is the public part of the server key to encrypt the hand= shake (including SNI to and the handshake_token is the "opaque" v= alue from ekr's flows proposal.=C2=A0 Clients could select between whic= h of them they'd use based on their ALPN support.

At least for HTTP(S), something like this might be more deployabl= e than current options.

Note that the handshake_token (sent in the c= lear in the TLS handshake like the "opaque" value) will leak info= rmation to passive attackers who are building up correlation tables.

Also if the key is used *only* for the handshake, it's not cl= ear that this is any worse against active attackers even if DNSSEC is not u= sed than the "new flows" proposal.=C2=A0 (In both cases a MitM ca= n provide an alternate handshake key or build up a table of ids to SNIs.)= =C2=A0 Clearly DNSSEC would need to be used for *every* step before DANE co= uld be used, however.


I think the question from above arises of whether it is= worth doing all of the engineering work here if there's still no funda= mental way to guard against active attackers or resourceful passive attacke= rs.=C2=A0 Some of this will come down to trade-offs.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

=








On Wed, Apr 16, 2014 at 10:39 AM, Andy Lutomirski <l= uto@amacapital.net> wrote:
On Wed, Apr 16, 2014 at 7:32= AM, Brian Sniffen <bsniffen@akam= ai.com> wrote:
>> Furthermore, no offence to Rich, but I suspect if you told him &qu= ot;We'll
>> build the DNS subdomain forwarding, and you can use that or just n= ot
>> encrypted SNI", he will choose not to use it. Maybe I'm w= rong, but
>> since he argued against it initially, I'll make the leap. =C2= =A0So making
>> it opt-in seems to be as equivalent to building an optional featur= e
>> that almost no one will use from the beginning.
>
> Yes: we will not use encrypted SNI. =C2=A0We can't. =C2=A0We need = to put thousands
> of HTTP hosts with incompatible crypto requirements on each IP address= .
> Per-IP keys don't help us very much.

Would a protocol along the lines of my strawman work for you? =C2=A0I=
explicitly did not require that the eventual cipher suite match for
different SNI values. =C2=A0I even made it possible to for whatever
receives the initial SSL connection to strip the SNI encryption and
hand the connection of to something else, without sharing any
long-term secrets between the machines in question.

--Andy

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

--20cf30363731566d6e04f72d7983-- From nobody Wed Apr 16 12:09: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 D62741A020D for ; Wed, 16 Apr 2014 12:09: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 9c1_1g1_QVVP for ; Wed, 16 Apr 2014 12:09:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDA161A02E9 for ; Wed, 16 Apr 2014 12:09:48 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so8461521lbj.17 for ; Wed, 16 Apr 2014 12:09: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:from:date :message-id:subject:to:cc:content-type; bh=mf94TuDERfP7X3mniAP2kN+Eg4ZAROqGUlRScSL3zYg=; b=RPqRiPPNXCCpIeDvWCedzZATbicbQf39S0AaUsONg8npEKbIfpMabYt/qTwR/YJ5zy qHcqExYIUIHh0oC2Y2eg22oNjzQxfVVGdQ3OgRxDCu0mseZGgxeb8ortIOT4uS0C6oCA ThBfTRTcHck+rHMtRL0SPApd0x9ds/SxNsaX913yDS0d9fqP6hk46mRXtOV5PczsSdGD 4QfcU7vhf6Fa+yRJAOlgMiiWwj6HHS37nJsPBKfElgf8ykTuh0t5ckibeAxiEv+QELWB kqYHpdfz2JIQbHf9Y/Y/JKdMPL8UjtZ2XR5SuyLb21F98jTfrUZV3u6BFJlsaMA5aNa2 2adA== X-Gm-Message-State: ALoCoQkFV7CcS0m8sKYkwNjVlOPJBwSfcnG/ODG9zT5p4+ConZI/dKy07Ko3Wkvy/VMOBMce3Vnp X-Received: by 10.112.163.69 with SMTP id yg5mr3902528lbb.14.1397675384899; Wed, 16 Apr 2014 12:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 12:09:24 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 12:09:24 -0700 Message-ID: To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pPPF8Zf6bxNMil1EAYCk-qfdAqA Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:09:54 -0000 On Wed, Apr 16, 2014 at 11:56 AM, Erik Nygren wrote: > If we do anything with DNS, we need to be very conscious that individual > records change asynchronously from other records. For example, we can't > assume that an A/AAAA record and a DANE record refer to the same operator > (webserver, hosting provider, CDN, etc). In order for anything along these > lines to be deployable, it must be possible for everything associated with a > particular name->service binding to change together. In addition, browser > vendors are extremely wary of doing extra DNS lookups synchronous to a > request which is one reason that SRV records aren't in-use today for > HTTP(S). You can hack around this by temporarily turning off hello encryption when switching providers. This is unfortunate, though. > > After thinking about this some, if we are looking towards a future world > where additional DNS security and privacy has been added, a new "service > binding" record type (I'll call it a "B-record") might help partially > address a number of these issues and raise the bar a little about SNI > privacy. The B-record would glue together information needed for > establishing a connection (and provide a client with a number of options to > choose from). For example: > > _https._b.www.example.com B "AAAA=2001::abcd, port=443, alpn=h2s, > handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335, > pri=5, dane_cert_name=version83.ca.example.com" > _https._b.www.example.com B "A=1.2.3.4, port=443, alpn=h2s, > handshake_ecdhe_key=68sgjbjfsd8fyjgbsgd7863, handshake_token=5sdfkj335, > pri=5, dane_cert_name=version83.ca.example.com" > _https._b.www.example.com B "A=1.2.3.5, port=443, alpn=h1s, > handshake_ecdhe_key=438nkgj8utjs89we0t8tjer, handshake_token=asdjhk887, > pri=3, dane_cert_name=version82.ca.example.com" > > Defines a set of HTTPS service bindings for a few sets of IP addresses with > different ALPN settings. > > In the above, the handshake_ecdhe_key is the public part of the server key > to encrypt the handshake (including SNI to and the handshake_token is the > "opaque" value from ekr's flows proposal. Clients could select between > which of them they'd use based on their ALPN support. > > At least for HTTP(S), something like this might be more deployable than > current options. > > Note that the handshake_token (sent in the clear in the TLS handshake like > the "opaque" value) will leak information to passive attackers who are > building up correlation tables. I'm not sure exactly what you mean by handshake_token. Do you mean the anti-replay token? The handshake token as a way of identifying the service binding in use seems problematic to me. Wouldn't it be better to just leave it out entirely? As long as each IP only accepts one or two handshake keys, then figuring out which one is in use by trial decryption should be fine. I think that something is wrong if you have an IP with lots of handshake keys. Realistically, you may need up to four handshake keys: old FIPS, new FIPS, old non-FIPS, new non-FIPS. > > Also if the key is used *only* for the handshake, it's not clear that this > is any worse against active attackers even if DNSSEC is not used than the > "new flows" proposal. (In both cases a MitM can provide an alternate > handshake key or build up a table of ids to SNIs.) Clearly DNSSEC would > need to be used for *every* step before DANE could be used, however. > > > I think the question from above arises of whether it is worth doing all of > the engineering work here if there's still no fundamental way to guard > against active attackers or resourceful passive attackers. Some of this > will come down to trade-offs. I think my approach is actually secure against active attack, so long as the client is willing to fail if DNSSEC validation fails. Your idea of B records could be as the DNS component. --Andy P.S. As a side note, here's a tweak to mine: the DNS-encoded key should include the length of the maximum overhead that any handshake cipher suite imposes to make the padding calculation easier. That adds one byte or so. From nobody Wed Apr 16 13:34: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 AFA0E1A027F for ; Wed, 16 Apr 2014 13:34:38 -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 b4ZYGy99jnVh for ; Wed, 16 Apr 2014 13:34:33 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 217C61A02CA for ; Wed, 16 Apr 2014 13:34:32 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so11089080qaq.24 for ; Wed, 16 Apr 2014 13:34:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T0PiRSvCq1ejU/brhl2vnN7uV0Me7upODNoJpeAYCjw=; b=AlTKQ1BnSBXYKFGhwU0r7fOjxDv0j0VWtTLLFalLHmS90vsv2d3NxHxoGCWUoKXgVf ZVIFqJy+aK9rpI8LganFhvUbcWuwFjmDYQJLqlIbgmFAwkGWYWzSxxrBrVu9pOkPWYpE bJzoDa0aBcS2qF6YG/eSMcK8m0GGTPmmB9T7cgVQW+trtMV7vZ3sY0GShmQ6wJ/gEk2v FhajyFotN0FS7D0lYWAVfMy0sOatC1tvIpwBBBxfSEHRKoxbLW9elWDiV+vjCfeQ471J Z3mOPuL9ljTH0y9jDTW1IsDYTugwvCzmVOqbH78M6fdUZu86Y4Ji8Du7ILmJfhcRsWM9 O0Ag== X-Gm-Message-State: ALoCoQm2yR4W2yUuTSnadoIT+MOWIdm11hptfOCH1QQu7sW4JHnyxjGvZKB174qzWk4l1540+Y4C MIME-Version: 1.0 X-Received: by 10.229.58.68 with SMTP id f4mr5906357qch.18.1397680469464; Wed, 16 Apr 2014 13:34:29 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Wed, 16 Apr 2014 13:34:29 -0700 (PDT) X-Originating-IP: [185.17.93.142] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Wed, 16 Apr 2014 20:34:29 +0000 Message-ID: From: Jacob Appelbaum To: Andy Lutomirski Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/B_Zp7dqVkXEPw_QRMEC9hLP4-kA Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 20:34:38 -0000 On 4/16/14, Andy Lutomirski wrote: > On Wed, Apr 16, 2014 at 11:47 AM, Jacob Appelbaum > wrote: >> On 4/16/14, Brian Sniffen wrote: >>> Andy Lutomirski writes: >>> >>>> On 04/14/2014 10:21 PM, Watson Ladd wrote: >>>>> Now, the best mechanism I can think off would be to use DNS to preload >>>>> a per-IP SNI encryption key, or have the handshake optionally involve >>>>> getting one. But I still can't figure out how to authenticate the >>>>> gotten key without a lot of complexity. The best solution is for the >>>>> client and server to do a DH, then pass the desired website (which >>>>> might get you investigated when the initial handshake is intercepted), >>>>> and have that cert sign the handled DH, then go back and do a TLS >>>>> connection. Ugh. >>>> >>>> What if it were an opt-in thing? A hypothetical DANE extension could >>>> associate with each domain a tuple (ClientHello-protection public key, >>>> TLS version guaranteed to be supported). Clients could resolve that >>>> essentially for free as long as they're already querying DNS, and this >>>> could prevent downgrade attacks and give an efficient way to encrypt >>>> the >>>> entire ClientHello. >>> >>> Then the censor looks to see which key is used, yes? >> >> Keys are free - names and signatures are not. The good news is that >> signatures may be regenerated at a low cost depending on the systems; >> the bad news is that names generally can't change without a lot of >> effort on both the client and the server side. >> > > I'm not sure I understand what you mean. I mean - if you have a name that is blocked and the name is exposed in the protocol - you can't change the name easily. One can rotate a certificate when it is blocked. One may support a different protocol that isn't blocked. A name is a fixed string ripe for feature extraction and that often results in say, a forged TCP RST packet. > >>> >>>> There's a weak argument to be made for arranging for the actual >>>> encrypted ClientHello to be indistinguishable from random by anyone who >>>> doesn't know the private key. This ought to be straightforward using >>>> Elligator. Off the top of my head, it sounds cute, but I don't really >>>> see a benefit. >>> >>> Or does this protect against it? >>> >> >> I have previously hoped for a TLS (handshake, protocol, >> implementation, etc) that actually considers that an attacker will try >> to distinguish users and then treat them differently, eg: attacking >> them, even with a simple DoS. >> >> We see this often with the Tor network. We once were blocked in Iran >> because we used a specified prime from the relevant RFC - it turns out >> nearly no one else was impacted because they used another prime. We >> changed the primes on the server to be dynamically generated and the >> network was unblocked without a client side update. Fixed identifiers >> or patterns in protocols are how censors target specific users and >> protocols for censorship. The SNI in TLS is the most obvious and easy >> distinguisher and it also suggests that privacy isn't actually a >> cohesive security property of Transport Layer Security. >> >> Not every TLS service uses DNS simply because it may also use names. >> Names aren't only used in DNS. Just as there is more to the internet >> than the world wide web, there is more to naming than the DNS. > > I think that my updated proposal should work for you, as long as Tor > has some other way to distribute the same data that's normally in the > DNS record. I imagine that it could be distributed along with the IP > addresses of entry nodes. Am I missing something here? I am not really interested in the Tor case here but rather the large picture TLS usage which will later impact Tor. Though I do care that an evil Exit node might specifically block stuff based on SNI, I think that is a pretty unimportant corner case in the Big Picture. The Tor community already has stuff like ScrambleSuit and other Pluggable Transports to obfuscate traffic. What we're lacking is a transport layer security protocol that other people use without all of these distinguishers. Widespread use of easily censored protocols full of information leaks makes it harder for us to blend in with regular user traffic on the wire. That is a slight digression but I think it is probably useful context for what I'm thinking about and why I care about TLS in say, a web browser that doesn't use Tor at all. > > My proposal, as currently written, results in the encrypted form the > the TLS handshake looking like a fixed header (ClientHello TLS version > whatever, throw-away values in fixed fields, extension prefix for the > actual encrypted Clienthello) followed by data that is > indistinguishable from random due to the use of Elligator 2 / > Elligator Squared. I'm not clear that fixed sizes are what we'd want but I think the use of Elligator like systems is a good general idea. I tend to think that it would be useful to have a TLS mode where there is an outer layer of TLS that is unauthenticated and then a second layer with normal TLS on the inside that verifies the outer layer. This isn't unlike the way that OTR handles key exchange data to prevent the exposure of long term (public) keying material to a potentially hostile chat network. > > If non-Tor sites adopt this, then Tor traffic will look just like > everything else. > Maybe. This is much much harder to accomplish than it first appears! All the best, Jacob From nobody Wed Apr 16 15:36: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 4EF931A03CA for ; Wed, 16 Apr 2014 15:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.998 X-Spam-Level: ** X-Spam-Status: No, score=2.998 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=0.6, 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 CnTf8RWidF0W for ; Wed, 16 Apr 2014 15:36:14 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id F1A071A03C1 for ; Wed, 16 Apr 2014 15:36:13 -0700 (PDT) Message-ID: <534F05DD.5010906@akr.io> Date: Wed, 16 Apr 2014 23:36:13 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <20140415153435.7f82b3a0@hboeck.de> In-Reply-To: <20140415153435.7f82b3a0@hboeck.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/amdgCjyFdxsylaj6JYMbF9SLHPU Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 22:36:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It looks like RC4 is rapidly heading for the chopping block, with basically unanimous consensus. Good. In the meantime... On 15/04/2014 14:34, Hanno Böck wrote: > What other algorithms exist in the TLS spec that should see > deprecation? […] E.g. what about deprecating DSA? I actually favour, for reasons of complexity and weakness, potentially deprecating pretty much everything that falls in the following lists, if of course it isn't already deprecated, subject to discussion: • Anything with NULL anything - An accident waiting to happen (on purpose). • Anything EXPORT - Bad old days. Kill them with fire. TLSv1.1 deprecated them but didn't forbid them in TLSv1.0; if they're not already a MUST NOT somewhere, I think they should be. • DES is already deprecated. [RFC5469] - What about 3DES now? • IDEA's already deprecated. [RFC5469] - Little traction in the wild, due to the (now-expired) patents. • Anything using MD5 - Collided. Kill it off. I'd feel highly uncomfortable keeping this around. • Anything using DSS/DSA certs - The Nonce Problem. RFC 6979 fixes this, but... - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? ¬_¬ • ECDSA without RFC6979? - Because of The Nonce Problem. - Remember to avoid timing attacks in RFC6979. - I don't know where that stands regarding FIPS-compliance, for those that need it: but as far as I'm concerned, if FIPS is incompatible with RFC6979, FIPS needs fixing because it's encouraging extremely fragile implementations. - ECDSA makes me uneasy now. It shares DSA's characteristics of being fragile as hell. I can't help but worry it was intentionally designed that way. - We will need a new scheme soon; EdDSA or a very similar Schnorr-style derivative? I'd like EdDSA swapping SHA-256 for SHA-3, perhaps? A discussion for the future (and/or CFRG, etc). • Anything using SHA-1? - Already deprecated by NIST, and by CAs and vendors in certificates due to ~2^61 being expensive but practical. - An attack is harder in a MAC scenario - but it's only a matter of time; it's downhill all the way from here. - Thoughts? - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and down? • DH_anon? - Subject to thoughts about possible opportunistic encryption, although this definitely isn't the way you _want_ to do that. • Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why? • RSA without forward security - Seems like we're heading broadly in the direction of requiring forward-security, which means deprecating plain old RSA in TLSv1.3 negotiations? Thoughts? • DHE - Given the complexities noted surrounding DHE parameters and lack of ability to negotiate them, would we be better off dropping conventional DHE for TLSv1.3? - Favour ECDHE over secp256r1 and/or Curve25519 (where the latter is not forbidden by FIPS-compliance, with 25519 being preference) as baseline instead? I do realise that's a strongly aggressive proposed unused-feature or not-best-practice cull, largely for reasons of complexity reduction. Perhaps others will be able to moderate my opinions. :-) - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTwXdAAoJEOyEjtkWi2t6fGkP/3C1+/o7QOSU2Gu0wdiYnsZ7 6zKCszf954w0mYIugZdwkKI6ZxlgjcybWz9ZFRPoXaf9XFlJgFRK+YysgmGFlmmO qJNsv/ur14JSWMClUuD/BH5EKpDlY9jOAFt44k6RIf8dZN7B1CO9yhjUMnlwdh8J MZuGLywu7She9JfIbhcBGVfXMYlExy7nI857K7YkbAu0LZdWNNV3Ut0VEYBq2feB tyMuuSq3Jdv00A52PfMjT5INEAHZGOH3yKbaY0yPY7HDhpcMGjD1YmeVN++wHD8X 1jOlxS6wWWP59ifRmsLIRH7oZvCGXs4oM0RO0T22Ou2424g73Uwccmqhc9jDebdz 0E/srZ3W4gan4kkvBgNwAEBxiQ/rxg0Haab6vnvusBpkO4n78Dy41dt046V/tEWn 1W44nVZ+wNRM+78xlKD+72k2BG3k3nOpszQfS+b024PaIhLGMLAbd3no/V9EQVsc vvN3tMM4wTVQm3ZyUHetxn1BqBrxRYeydsnGiGjDKWA7YLTC79S2E6ADLYv7OeT8 6cc33QLKogoSlm/KfUqH7FAZKr0uNbkf3zKVwuKLSlqFAl6l6AMlGhnP+FyekXIQ vp27MxZyFX1V8PLjHFzUlrRfeg02GrsXjl3wcsh4/OTftGA3clPw5GH0U9Apy3Zr F4DoDtMHy88ukdTKybKc =gD5B -----END PGP SIGNATURE----- From nobody Wed Apr 16 15:53: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 61B251A02E8 for ; Wed, 16 Apr 2014 15:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxjUdMH0T_aA for ; Wed, 16 Apr 2014 15:53:10 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 548281A023A for ; Wed, 16 Apr 2014 15:53:10 -0700 (PDT) Message-ID: <534F09D6.1060308@akr.io> Date: Wed, 16 Apr 2014 23:53:10 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MHbOE_XJPNScjkCiRF4r4jtQAKk Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 22:53:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/04/2014 01:46, Trevor Perrin wrote: > Maybe this argues for Adam Langley's earlier suggestion (also > endorsed by a few others) that we focus on a TLS 1.3 that is a > "tidying up" of 1.2, and push the larger goals (e.g. redesigning > handshake for lower-latency or more encryption) to a TLS 2.0? On reflection, I think I may favour this approach, yes: • Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint removed, bugs fixed and downgrade protection, and getting that out fairly promptly; and, • Following that with a TLSv2.0 process in which we look at the far more radical and challenging changes: handshake improvements, ClientHello/SNI encryption, perhaps a complete redesign. If both are faster and higher-performing, that might help avoid delay in adoption. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTwnWAAoJEOyEjtkWi2t6bmcP+gJk6W8wgrFY0l1I0sHYII+4 oTdjfeiIFzVl1nkXTksW2A8dsomfM2BE8MibHXXRJHXWLQ8dNuNM18TOPTG21YON nT3wmB1QwhiIzqscusTe9rv4Y18aSajR65zWXfuEf3+PtF36/y+9nSt9mgk2Njbi gmAC+CzJTC1omABNnQU3v+4HvTtD2onDzVQXtAvNeHtpwts0S8jF3LOvsOQCxhGw WofCMKWw1ImQcO4246isk9rIDXiBc0DhLK/1IBIxAK1HZV99HBl1xB9dRJRwp0In TjWANVx/cBNvbzdFAQ6s0LunNa4CV3kQNolWwEFF7Bw8BDw8yvxQBrCwjZ63MdjH b5rFJQLyOoJftZTV7HxWxxDOqV4inVyUQqZSsZwKSZX3Zv3fCUUuD1xRxNDDUeQx FVGgHgQFGxAQ2Aj9L1JOgRbI7PqFUfMFNgCMh4GZEN7MaYdvhDcXJd22vywglnIp SjiroTK/hp3CnE22mED5r6NfyHppExfB5YMkh9N3Tfb5kHPuz63twLedYz8GC83w QG8EirKEyRmYGyiKcmS0LD98qYVJUUKapW5R8J89CtPv6vNqYd84QOiqav7OcvNl JxWeAyU1LvKFLvZLiVJAerE9DbIsXLz2sub/0Id0gJgSS+AnfBp3V7e/SlQhrPn+ LI1gQi5OxXY9nFiktoyz =ll+R -----END PGP SIGNATURE----- From nobody Wed Apr 16 15:54: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 9B0291A0382 for ; Wed, 16 Apr 2014 15:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmIxYiKmAvQx for ; Wed, 16 Apr 2014 15:54:42 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 565E71A02E8 for ; Wed, 16 Apr 2014 15:54:42 -0700 (PDT) Message-ID: <534F0A33.9070408@akr.io> Date: Wed, 16 Apr 2014 23:54:43 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R11rfMA5LDrKqMkYiYxaRuR5ROU Subject: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 22:54:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/04/2014 21:34, Jacob Appelbaum wrote: > […] and that often results in say, a forged TCP RST packet. Which, incidentally, we should consider something to address, especially if we do indeed have a bakeoff of some form for a fancier TLSv2.0. NSA calls this technique QUANTUMSKY (one of their less catchy cover names) but it's been around for aeons (most famously in the Chinese 'Golden Shield'): any man-on-the-side can simply RST your TCP connections if they don't like the way they smell, and this is (by far) the cheapest and easiest way for a nation state adversary (or malicious coffee shop WiFi) to selectively disrupt, or censor, communications. Could we plug that hole in a future version of TLS? The obvious way involves UDP, and baking transport control (and multiplexing?) inside that layer, within the encryption. In fact it's so obvious, everyone likes to cook up their own recipe: lots of people have done something in that general area already in different ways, and discovered interesting things about it (Google's QUIC being one notable recent foray into the field). UDP is also notably better for connections through NAT and suchlike. (I've even done my own experiments in that general direction, although delicious and moist as they seem to be, they're simply experiments and I'm not yet ready to serve them to guests, let alone strangers!) It also results in something that probably looks more like DTLS than anything we have now, or something even stranger, or like nothing anyone can recognise. It may, or very well may not, be a good idea (gleefully gratuitously rampant layering violation/wheel reinvention vs. avoiding unnecessary insecure layers vulnerable to a real, deployed attack/square wheel), but I'd be interested (with no particular hurry) if anyone had had any thoughts in that direction. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTTwoyAAoJEOyEjtkWi2t6/eoQAKlvRCFsqyZI3pwWG1929+5u zn23iFhpZBo7Yna9ATUpdGGXUAGr6r3SC2gemyezNlyRsKWG7HPWq1dBbseT+Ubp fRVsCS2qsCty6v7ZB/uMxs9uxEucRudZN6ibJ0J9IoC22TsC8O/2NuXr5uuvVahd +Dk8k2dgXmf9NFXgjLmweneX+lI7rjVctSfJM5OmkJ9sz5GKzpxkaR0k7rwLHu23 L1sKyUGOJjam7LsA8wGOgQyCx3wCfqcFwtVECn5P+xpLaOfFznulvD56aXm+MGNO nM4OVAzErrqtYNJJL48YgR3XCrQ+6fU1Gu1A3KNS2uCzrnJO9nTBLS3uR4FEvxLL XrLxeol8+Csh+QQjvX3x/sGDZBX3jUhoNchqUP+u5Vl/+ca6T85k1A5GNI5tY5yG kMec1vLcpsVTYvi9CDV8HjhTnCU5tsueyVkpNWW141UtbNF8VxdGnqSqj7VBysPh cAAc4AOb2GuD7c5RdYsUvp3vEeuUgnewkOLDLW2W+uBbLHh3hDB4egy3B2HlxGFN /jlK2ZXgba4pcReI9PU7c4QSQjpdFB213B1WLt3rGen9aUlTAr1HESbMt0PIxpyQ hEu7uYIaxjj/n/j/R1A2FiIhkFY9K07WqXSIjAdPRQU2cAiyljBZ76Yg9tQwYKXj EzCJFwn2UX1OzVhmhaG6 =aDNf -----END PGP SIGNATURE----- From nobody Wed Apr 16 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 519981A0387 for ; Wed, 16 Apr 2014 16: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 gEO3Br3GXszb for ; Wed, 16 Apr 2014 16:01:36 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id DADDD1A038D for ; Wed, 16 Apr 2014 16:01:35 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so2133723wib.8 for ; Wed, 16 Apr 2014 16:01:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9jLSpCmY8g3oWz4T3aoLH92jB2eEYsAMRjtVpQA82Ik=; b=d3sg3SUh5TJ7pdnTm3Io1WYpCa5wVng2IZHcpuah0IJHU1hm8XcugoE9LqepJIJP1U pwWF5c1l6fQ+M/vD0HMqa6JpsXZlXEArPE6OQnTDnDIuJu/Wt6hy9I9lNGuXOLY1lq/G nJ3ELWmypv6OpVuXhfzQzkTDWjdiwNEADENgZxOnr0DICCJ6zDlVPItaLGrwsYP1piAb ZkvklFxBvTalFTEEA6w4Oe957znqQf6Vte+jU31d/ac5kMpBSh7/imDGIzNINaf2o9my hgjmF/wkfJopENv0Fne+T4dwP22NKd41Eb/M5JsWv3Qms756wMROJ1DVkdfW0mHinf8j sELg== X-Gm-Message-State: ALoCoQmMrvVfbnEc0aUnh8pNLmX072o0p+77oXtc1FDjFsGeDF5w5h16kuy3hj80GwGmzLXoZkf5 X-Received: by 10.180.212.76 with SMTP id ni12mr9438982wic.49.1397689292157; Wed, 16 Apr 2014 16:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Wed, 16 Apr 2014 16:00:52 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <534F0A33.9070408@akr.io> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <534F0A33.9070408@akr.io> From: Eric Rescorla Date: Wed, 16 Apr 2014 16:00:52 -0700 Message-ID: To: Alyssa Rowan Content-Type: multipart/alternative; boundary=001a11c351a4c3f91d04f730e5e0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JF7_hsXQt6VejMjZsTn1xWaSZH0 Cc: "tls@ietf.org" Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 23:01:40 -0000 --001a11c351a4c3f91d04f730e5e0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 16, 2014 at 3:54 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16/04/2014 21:34, Jacob Appelbaum wrote: > > > [...] and that often results in say, a forged TCP RST packet. > > Which, incidentally, we should consider something to address, > especially if we do indeed have a bakeoff of some form for a fancier > TLSv2.0. > > NSA calls this technique QUANTUMSKY (one of their less catchy cover > names) but it's been around for aeons (most famously in the Chinese > 'Golden Shield'): any man-on-the-side can simply RST your TCP > connections if they don't like the way they smell, and this is (by > far) the cheapest and easiest way for a nation state adversary (or > malicious coffee shop WiFi) to selectively disrupt, or censor, > communications. > > Could we plug that hole in a future version of TLS? > My sense is that this is out of scope for TLS proper, though (D)TLS could certainly be part of the solution, as in: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03 Which is used in WebRTC data channels. (Which reminds me, I promised to review this too so I need to get on it...) Best, -Ekr --001a11c351a4c3f91d04f730e5e0 Content-Type: text/html; charset=ISO-8859-1



On Wed, Apr 16, 2014 at 3:54 PM, Alyssa Rowan <akr@akr.io> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 16/04/2014 21:34, Jacob Appelbaum wrote:

> […] and that often results in say, a forged TCP RST packet.

Which, incidentally, we should consider something to address,
especially if we do indeed have a bakeoff of some form for a fancier
TLSv2.0.

NSA calls this technique QUANTUMSKY (one of their less catchy cover
names) but it's been around for aeons (most famously in the Chinese
'Golden Shield'): any man-on-the-side can simply RST your TCP
connections if they don't like the way they smell, and this is (by
far) the cheapest and easiest way for a nation state adversary (or
malicious coffee shop WiFi) to selectively disrupt, or censor,
communications.

Could we plug that hole in a future version of TLS?

My sense is that this is out of scope for TLS proper, though (D)TLS could
certainly be part of the solution, as in:


Which is used in WebRTC data channels.

(Which reminds me, I promised to review this too so I need to get on it...)

Best,
-Ekr


--001a11c351a4c3f91d04f730e5e0-- From nobody Wed Apr 16 16:22: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 BA7E21A03D6 for ; Wed, 16 Apr 2014 16:22:06 -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 PpUXLBe20kGG for ; Wed, 16 Apr 2014 16:22:01 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 938841A02E2 for ; Wed, 16 Apr 2014 16:22:01 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so11429659wgg.21 for ; Wed, 16 Apr 2014 16:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5aaPBmUhZIe7ev1QHWXuabx9HoBA7msZGOw1EiNsMoQ=; b=mdFvl5B7MPFN2Dv+RNDPQ6e4rh9nlXB21eK44b+uxhmQ647yLmJ3VgVcrxsgo3HuLD UhQlQPWRMGkxYOMjoLqS3BgPxNZKvxub++lfVfK751WAO9OQ4toxqk1JzaP2/VGAgzyk EzscJ2sv4R3GuIs/SSqlhcUTuND67vElv1G5scfL//Q0cibxD3GEjYoVVKX7wcIDR5Td hDs3u30uyDiwpKfo0ijulaBjXxFZYJlDwHamPhovYikfiYHlwsu4ZkghRwQTa1t4zNyU c7j58mVpiOOfS3OI1JSjvttA9ZMJrZUPcQWQfj7wdIFtFQt1kUw82rAP5PzKOxNEN+Co MDTg== X-Gm-Message-State: ALoCoQkrmpgbB3dufpJ6meKu9khU+iUm4XDhWXvbOiM88im4GTUYb0n4f+W0EeqF5yBoErUEeKDv MIME-Version: 1.0 X-Received: by 10.180.106.132 with SMTP id gu4mr8887361wib.26.1397690517814; Wed, 16 Apr 2014 16:21:57 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 16 Apr 2014 16:21:57 -0700 (PDT) X-Originating-IP: [173.11.71.217] In-Reply-To: <534F09D6.1060308@akr.io> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> Date: Wed, 16 Apr 2014 16:21:57 -0700 Message-ID: From: Trevor Perrin To: Alyssa Rowan Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pjqb-MvtENjxtQciXE7adAPz_gw Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 23:22:06 -0000 On Wed, Apr 16, 2014 at 3:53 PM, Alyssa Rowan wrote: > > On 16/04/2014 01:46, Trevor Perrin wrote: > >> Maybe this argues for Adam Langley's earlier suggestion (also >> endorsed by a few others) that we focus on a TLS 1.3 that is a >> "tidying up" of 1.2, and push the larger goals (e.g. redesigning >> handshake for lower-latency or more encryption) to a TLS 2.0? > > On reflection, I think I may favour this approach, yes: > > * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure > baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint > removed, bugs fixed and downgrade protection, and getting that out > fairly promptly; > > and, > > * Following that with a TLSv2.0 process in which we look at the far > more radical and challenging changes: handshake improvements, > ClientHello/SNI encryption, perhaps a complete redesign. Perhaps we could do both in parallel? - * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down profile of TLS 1.2, without major handshake changes or new features, aiming to finish in a few months. * Place a call for proposals for TLS 2.0, with the intent of choosing one as a WG item within 4-6 months. --- I hear the concern that people don't want a "clean-slate" or "revolutionary" redesign of TLS, they just want to quickly make the "minimal" changes to 5246 that meet our charter. I'd encourage such people to re-read the charter, and look at Eric's 1.3 draft. The goals and designs being considered are *already* a radical break from your parent's TLS. We'll have complex, difficult debates involving competing visions for TLS regardless of what process we choose. Having different proposals is not going to create this problem. But it will help us navigate it, by making it easier to compare the implications of inter-related design decisions. Here's an example of the questions we have to resolve, and which I think will be hard to handle with individual consensus calls if we don't have a holistic picture of what we're choosing: (1) Can pre-delivered public keys (via DNS? html? other?) be used to encrypt the handshake or even app data (e.g. Andy Lutomirski's "handshake keys" for protecting SNI, or "semi-static public keys" for 0-RTT initial connections)? (2) Should 0-RTT reconnection be achieved via a traditional session-ticket flow, or through a new flow based on caching a semi-static public key? (3) For either sort of zero-RTT reconnection, how do we design an "anti-replay" capability which is practical and scaleable, and doesn't leak tracking info? (4) For zero-RTT cases, should we overlay an additional DH exchange on the 1st RT to increase forward secrecy for subsequent data? Or should this be accomplished by a more general re-handshake capability? (5) Assuming we go with the zero-RTT semi-static key approach for reconnection, should we also re-implement the initial handshake in terms of it (i.e. spend the 1st RT to retrieve the semi-static key), which makes things simpler but otherwise is less optimal than retrieving a fresh ephemeral? (6) Should we stick with a signed-DH key agreement, or consider alternatives (e.g. SKEME, MQV, NTor, TripleDH, other?). (7) Should client auth be integrated into the handshake or moved to a post-handshake, channel-bound layer? (8) Should the protocol be integrated (somehow) with TCP or a TCP replacement (e.g. QUIC, MinimaLT, TCPcrypt)? (9) What should be done to minimize tracking / info-leaks in the protocol (e.g. remove / randomize session tickets / SessionIDs, remove other options, Elligator-type indistinguishability, more padding)? (10) Stylistic decisions: - choice of ciphersuites? - preserve TLS message formats or replace them? - larger extension spaces? (end the 16-bit suffering!) etc.... Trevor From nobody Wed Apr 16 16:34: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 769E31A0420 for ; Wed, 16 Apr 2014 16:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.573 X-Spam-Level: X-Spam-Status: No, score=-13.573 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_24=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 FSxpJG2Dj7Iv for ; Wed, 16 Apr 2014 16:33:58 -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 11E5B1A0422 for ; Wed, 16 Apr 2014 16:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6037; q=dns/txt; s=iport; t=1397691235; x=1398900835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sG7E28IMgw/rQCM1KQi/MmVY+jhQHaaCXA4UhItWNJc=; b=X4+Hsz4f46D2cOGf5ZaWbktwWo/R2HqU17OIAjcWuYBpOj8+lPYb57ze 3WAjBfVz2eaq5gRUy6YOZ12tuPaMJACweDmdkuh62t1DVM6+vEZZJAQ69 evFguML0y6qjmwNvTzFdSq9cG0Wqx+AKT6rxDT6s9CHmhkBK1yoMe3Iod g=; X-Files: signature.asc : 495 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEcST1OtJV2Y/2dsb2JhbABZgwY7V7t/hziBIRZ0giUBAQEDAQEBARpRCwULAgEIDgouJwslAgQOBQ6HZggNyXwTBIk9hSUHgySBFASQZ4E2hkmSSYMxgiuBAQEBBA X-IronPort-AV: E=Sophos;i="4.97,875,1389744000"; d="asc'?scan'208";a="318126293" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 16 Apr 2014 23:33:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3GNXs4w027687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 23:33:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 18:33:54 -0500 From: "Joseph Salowey (jsalowey)" To: Alyssa Rowan Thread-Topic: [TLS] Deprecating more (DSA?) Thread-Index: AQHPWcRK8V34rxwfJE2oz5iBRqYbFJsVOOgA Date: Wed, 16 Apr 2014 23:33:52 +0000 Message-ID: References: <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> In-Reply-To: <534F05DD.5010906@akr.io> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.220] Content-Type: multipart/signed; boundary="Apple-Mail=_5A7F7FCD-179F-4BD5-B1E4-F2E472F32861"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0DRR4_v7k48UqGVlbiyZo0JyYYI Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 23:34:00 -0000 --Apple-Mail=_5A7F7FCD-179F-4BD5-B1E4-F2E472F32861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I'm not to crazy about deprecating DSA in the same fashion as RC4. I'd = be fine with leaving DSA/DSS out of TLS 1.3 if there is support for = that. I like the list below, some comments inline: On Apr 16, 2014, at 3:36 PM, Alyssa Rowan wrote: > Signed PGP part > It looks like RC4 is rapidly heading for the chopping block, with > basically unanimous consensus. Good. >=20 > In the meantime... >=20 > On 15/04/2014 14:34, Hanno B=F6ck wrote: >=20 > > What other algorithms exist in the TLS spec that should see > > deprecation? [=85] E.g. what about deprecating DSA? >=20 > I actually favour, for reasons of complexity and weakness, potentially > deprecating pretty much everything that falls in the following lists, > if of course it isn't already deprecated, subject to discussion: >=20 > =95 Anything with NULL anything > - An accident waiting to happen (on purpose). >=20 [Joe] Many cipher suites with NULL encryption have been added in the = recent past. I think we'll need to have more discussion on that. I = don't not currently have data on how widely they are used.=20 > =95 Anything EXPORT > - Bad old days. Kill them with fire. TLSv1.1 deprecated them but > didn't forbid them in TLSv1.0; if they're not already a MUST NOT > somewhere, I think they should be. >=20 [Joe] yup. =20 > =95 DES is already deprecated. [RFC5469] > - What about 3DES now? >=20 [Joe] not sure about this one. I think the argument in keeping 3DES = around is as a fallback to AES. Not sure I buy into this, especially if = we have a better alternative, perhaps CHaCha. =20 > =95 IDEA's already deprecated. [RFC5469] > - Little traction in the wild, due to the (now-expired) patents. >=20 > =95 Anything using MD5 > - Collided. Kill it off. I'd feel highly uncomfortable keeping this > around. >=20 > =95 Anything using DSS/DSA certs > - The Nonce Problem. RFC 6979 fixes this, but... > - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? = =AC_=AC >=20 [Joe] yes to the above. Perhaps there still is DSS in use, but I really = would expect that to move to ECDSA. =20 > =95 ECDSA without RFC6979? > - Because of The Nonce Problem. > - Remember to avoid timing attacks in RFC6979. > - I don't know where that stands regarding FIPS-compliance, for = those > that need it: but as far as I'm concerned, if FIPS is incompatible > with RFC6979, FIPS needs fixing because it's encouraging extremely > fragile implementations. > - ECDSA makes me uneasy now. It shares DSA's characteristics of = being > fragile as hell. I can't help but worry it was intentionally > designed that way. > - We will need a new scheme soon; EdDSA or a very similar > Schnorr-style derivative? I'd like EdDSA swapping SHA-256 for > SHA-3, perhaps? A discussion for the future (and/or CFRG, etc). >=20 [Joe] I think I'd like to bring ECDH and ECDSA into the core spec in = 1.3. We could make some of these changes as part of that. =20 > =95 Anything using SHA-1? > - Already deprecated by NIST, and by CAs and vendors in certificates > due to ~2^61 being expensive but practical. > - An attack is harder in a MAC scenario - but it's only a matter of > time; it's downhill all the way from here. > - Thoughts? > - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and = down? >=20 [Joe] yup > =95 DH_anon? > - Subject to thoughts about possible opportunistic encryption, > although this definitely isn't the way you _want_ to do that. >=20 [Joe] Why not?=20 > =95 Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why? >=20 [Joe] Not sure. =20 > =95 RSA without forward security > - Seems like we're heading broadly in the direction of requiring > forward-security, which means deprecating plain old RSA in TLSv1.3 > negotiations? Thoughts? >=20 [Joe] I didn't see much objection to removing plain old RSA in the call = for consensus.=20 > =95 DHE > - Given the complexities noted surrounding DHE parameters and lack = of > ability to negotiate them, would we be better off dropping > conventional DHE for TLSv1.3? > - Favour ECDHE over secp256r1 and/or Curve25519 (where the latter > is not forbidden by FIPS-compliance, with 25519 being preference) > as baseline instead? >=20 [Joe] So, at this point I'd rather see 1.3 have a way to negotiate = parameters than deprecate DHE entirely. I'm not sure that I have a = really good reason to keep DHE around other than I'm more comfortable = with it. =20 > I do realise that's a strongly aggressive proposed unused-feature or > not-best-practice cull, largely for reasons of complexity reduction. > Perhaps others will be able to moderate my opinions. :-) >=20 > -- > /akr >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_5A7F7FCD-179F-4BD5-B1E4-F2E472F32861 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 - http://gpgtools.org iQEcBAEBAgAGBQJTTxNfAAoJEHDh2NpbGbjALhsH/jIpZqFovFtOHik7pt2ZNKqY Kq+AaWswFnPbWpeSkgDIYn/kvpsSeC/bbbXnpmMHURr4E7CTp6+Ns49bw4DeE9bT 3KOBWjSoxfokPUFBHoIIQ/SmQ+1UE74XHgfU157OVG2PTZxg5XRS3duTapEo8ygr tr52ftRiVVFZUA+D8IyLWdByvSZd/8ljyXOwzAc5iwUe1gNeByLbYrJgQeSXKp2B Xz247BrPdF4SpJzQIQkvzdQPnOojAd0rBNIIBtyL4O/r9X47NdvpbjMMUVMZPpDo A+LjR20X/vftOZv0H3iVBB8xTUSOyG30Uxez7xS5UFHiqGBGS3gYXGHpvb3xX8E= =xbjT -----END PGP SIGNATURE----- --Apple-Mail=_5A7F7FCD-179F-4BD5-B1E4-F2E472F32861-- From nobody Wed Apr 16 16:45: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 A5A251A0427 for ; Wed, 16 Apr 2014 16:45: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 i1jflkFiginw for ; Wed, 16 Apr 2014 16:45:26 -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 05DDA1A0425 for ; Wed, 16 Apr 2014 16:45:25 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so2163217wib.5 for ; Wed, 16 Apr 2014 16:45: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=eFx9nsnaCGsGuJZsPUIHUQGwz4+MXKOFSJRzINs+kZI=; b=AsJHLtyyf0yv3M9TPe9XMzIcwdnVxNLrSlEj5YynMbu5uTcfdG1eAoC9YAr1cfpFRD i4CpNH/PDwso4EZM/qbMh4vkg6pAwUQpe2IUMqCfWm4gZQ5H51FxelsNxh7v+6d3vR2D fndWBS8XfNCqBFnY9HqbwGZnqo8OkiWpoSQ7V6Uhi6IkNVmpy0zrWXkNxP+oor10eKmJ RZ9tZyOA4kxMMPabiUXET2mQK3zckRWgdIZ5RAIm1oE6f+gdmVIlQNFlyuYD/m22P0/C E05hFsXbdHhkZIJXnHp1aIr96EtEsWwQysmYUvcaYDeMiK2O5FB9fTRk7XkezdIPJeco HmZw== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr9299017wic.58.1397691922241; Wed, 16 Apr 2014 16:45:22 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Wed, 16 Apr 2014 16:45:22 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> Date: Wed, 16 Apr 2014 16:45:22 -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/PQd_9H9O1-bCxp1RlYPi5CpCBw4 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Apr 2014 23:45:27 -0000 On 16 April 2014 16:21, Trevor Perrin wrote: > * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down > profile of TLS 1.2, without major handshake changes or new features, > aiming to finish in a few months. I want a pony too, but since the latency improvements are the main reason we have people interested in TLS 1.3, I'm pretty sure that a plan like this won't have the desired effect. It might reduce the volume of mail I get from this list, which is one advantage I suppose. From nobody Wed Apr 16 17:07: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 6C21D1A0048 for ; Wed, 16 Apr 2014 17:07:45 -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 7AzNgLy8WiWI for ; Wed, 16 Apr 2014 17:07:40 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 267121A02E7 for ; Wed, 16 Apr 2014 17:07:39 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD7A022E257; Wed, 16 Apr 2014 20:07:28 -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: Date: Thu, 17 Apr 2014 10:08:50 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QBH9mW4Qiv3JVq77UhM2crxvoUk Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:07:45 -0000 I strongly agree with the notion that bakeoffs are, at best, = inadvisable.=20 The IETF isn't set up to do this sort of thing; the best way to get = traction here is to get implementation experience / buy-in. Working on TLS 2 at the same time as TLS 1.3 is in active development is = asking for both to fail, IMO. Regards, On 17 Apr 2014, at 9:21 am, Trevor Perrin wrote: > On Wed, Apr 16, 2014 at 3:53 PM, Alyssa Rowan wrote: >>=20 >> On 16/04/2014 01:46, Trevor Perrin wrote: >>=20 >>> Maybe this argues for Adam Langley's earlier suggestion (also >>> endorsed by a few others) that we focus on a TLS 1.3 that is a >>> "tidying up" of 1.2, and push the larger goals (e.g. redesigning >>> handshake for lower-latency or more encryption) to a TLS 2.0? >>=20 >> On reflection, I think I may favour this approach, yes: >>=20 >> * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, = forward-secure >> baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint >> removed, bugs fixed and downgrade protection, and getting that out >> fairly promptly; >>=20 >> and, >>=20 >> * Following that with a TLSv2.0 process in which we look at the far >> more radical and challenging changes: handshake improvements, >> ClientHello/SNI encryption, perhaps a complete redesign. >=20 >=20 > Perhaps we could do both in parallel? - >=20 > * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down > profile of TLS 1.2, without major handshake changes or new features, > aiming to finish in a few months. >=20 > * Place a call for proposals for TLS 2.0, with the intent of choosing > one as a WG item within 4-6 months. >=20 > --- >=20 > I hear the concern that people don't want a "clean-slate" or > "revolutionary" redesign of TLS, they just want to quickly make the > "minimal" changes to 5246 that meet our charter. >=20 > I'd encourage such people to re-read the charter, and look at Eric's > 1.3 draft. The goals and designs being considered are *already* a > radical break from your parent's TLS. We'll have complex, difficult > debates involving competing visions for TLS regardless of what process > we choose. >=20 > Having different proposals is not going to create this problem. But > it will help us navigate it, by making it easier to compare the > implications of inter-related design decisions. >=20 > Here's an example of the questions we have to resolve, and which I > think will be hard to handle with individual consensus calls if we > don't have a holistic picture of what we're choosing: >=20 >=20 > (1) Can pre-delivered public keys (via DNS? html? other?) be used to > encrypt the handshake or even app data (e.g. Andy Lutomirski's > "handshake keys" for protecting SNI, or "semi-static public keys" for > 0-RTT initial connections)? >=20 > (2) Should 0-RTT reconnection be achieved via a traditional > session-ticket flow, or through a new flow based on caching a > semi-static public key? >=20 > (3) For either sort of zero-RTT reconnection, how do we design an > "anti-replay" capability which is practical and scaleable, and doesn't > leak tracking info? >=20 > (4) For zero-RTT cases, should we overlay an additional DH exchange on > the 1st RT to increase forward secrecy for subsequent data? Or should > this be accomplished by a more general re-handshake capability? >=20 > (5) Assuming we go with the zero-RTT semi-static key approach for > reconnection, should we also re-implement the initial handshake in > terms of it (i.e. spend the 1st RT to retrieve the semi-static key), > which makes things simpler but otherwise is less optimal than > retrieving a fresh ephemeral? >=20 > (6) Should we stick with a signed-DH key agreement, or consider > alternatives (e.g. SKEME, MQV, NTor, TripleDH, other?). >=20 > (7) Should client auth be integrated into the handshake or moved to a > post-handshake, channel-bound layer? >=20 > (8) Should the protocol be integrated (somehow) with TCP or a TCP > replacement (e.g. QUIC, MinimaLT, TCPcrypt)? >=20 > (9) What should be done to minimize tracking / info-leaks in the > protocol (e.g. remove / randomize session tickets / SessionIDs, remove > other options, Elligator-type indistinguishability, more padding)? >=20 > (10) Stylistic decisions: > - choice of ciphersuites? > - preserve TLS message formats or replace them? > - larger extension spaces? (end the 16-bit suffering!) >=20 > etc.... >=20 > Trevor >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham http://www.mnot.net/ From nobody Wed Apr 16 17:16: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 5960A1A02E7 for ; Wed, 16 Apr 2014 17:16:08 -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 x4MRjLlwdfQX for ; Wed, 16 Apr 2014 17:16:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 635EC1A0057 for ; Wed, 16 Apr 2014 17:16:01 -0700 (PDT) Received: from BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) by BY2PR03MB427.namprd03.prod.outlook.com (10.141.141.146) with Microsoft SMTP Server (TLS) id 15.0.918.8; Thu, 17 Apr 2014 00:15:56 +0000 Received: from BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) by BY2PR03MB427.namprd03.prod.outlook.com ([10.141.141.146]) with mapi id 15.00.0918.000; Thu, 17 Apr 2014 00:15:56 +0000 From: Andrei Popov To: Mark Nottingham , Trevor Perrin Thread-Topic: [TLS] Bakeoffs Thread-Index: AQHPWMkaHaZIlY6FukqwHAPbha5IFZsS5rMAgAA6UgCAAEf1gIABcroAgAAIC4CAAA0aAIAAAIXw Date: Thu, 17 Apr 2014 00:15:56 +0000 Message-ID: <24681e8ff01e405f98436c165ed7c52f@BY2PR03MB427.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> 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: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(479174003)(13464003)(377454003)(189002)(199002)(24454002)(2656002)(15202345003)(92566001)(86612001)(79102001)(81542001)(81342001)(87936001)(31966008)(85852003)(74502001)(83072002)(74662001)(15975445006)(86362001)(77982001)(80022001)(46102001)(20776003)(33646001)(80976001)(76576001)(19580395003)(83322001)(561944002)(50986999)(76482001)(19580405001)(4396001)(77096999)(76176999)(54356999)(99396002)(99286001)(74316001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB427; H:BY2PR03MB427.namprd03.prod.outlook.com; FPR:8E18F134.9BFADF48.BFE3B07B.4E37ED71.20613; 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/8Qn3yhCOVmmfOV5kIK7bSGL68zE Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:16:09 -0000 I agree with Mark: designing and implementing two new TLS versions in paral= lel seems overly ambitious. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Wednesday, April 16, 2014 5:09 PM To: Trevor Perrin Cc: tls@ietf.org Subject: Re: [TLS] Bakeoffs I strongly agree with the notion that bakeoffs are, at best, inadvisable.=20 The IETF isn't set up to do this sort of thing; the best way to get tractio= n here is to get implementation experience / buy-in. Working on TLS 2 at the same time as TLS 1.3 is in active development is as= king for both to fail, IMO. Regards, On 17 Apr 2014, at 9:21 am, Trevor Perrin wrote: > On Wed, Apr 16, 2014 at 3:53 PM, Alyssa Rowan wrote: >>=20 >> On 16/04/2014 01:46, Trevor Perrin wrote: >>=20 >>> Maybe this argues for Adam Langley's earlier suggestion (also=20 >>> endorsed by a few others) that we focus on a TLS 1.3 that is a=20 >>> "tidying up" of 1.2, and push the larger goals (e.g. redesigning=20 >>> handshake for lower-latency or more encryption) to a TLS 2.0? >>=20 >> On reflection, I think I may favour this approach, yes: >>=20 >> * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster,=20 >> forward-secure baseline of fast, constant-time ECDHE and AEADs,=20 >> legacy/broken lint removed, bugs fixed and downgrade protection, and=20 >> getting that out fairly promptly; >>=20 >> and, >>=20 >> * Following that with a TLSv2.0 process in which we look at the far =20 >> more radical and challenging changes: handshake improvements, =20 >> ClientHello/SNI encryption, perhaps a complete redesign. >=20 >=20 > Perhaps we could do both in parallel? - >=20 > * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down=20 > profile of TLS 1.2, without major handshake changes or new features,=20 > aiming to finish in a few months. >=20 > * Place a call for proposals for TLS 2.0, with the intent of choosing=20 > one as a WG item within 4-6 months. >=20 > --- >=20 > I hear the concern that people don't want a "clean-slate" or=20 > "revolutionary" redesign of TLS, they just want to quickly make the=20 > "minimal" changes to 5246 that meet our charter. >=20 > I'd encourage such people to re-read the charter, and look at Eric's > 1.3 draft. The goals and designs being considered are *already* a=20 > radical break from your parent's TLS. We'll have complex, difficult=20 > debates involving competing visions for TLS regardless of what process=20 > we choose. >=20 > Having different proposals is not going to create this problem. But=20 > it will help us navigate it, by making it easier to compare the=20 > implications of inter-related design decisions. >=20 > Here's an example of the questions we have to resolve, and which I=20 > think will be hard to handle with individual consensus calls if we=20 > don't have a holistic picture of what we're choosing: >=20 >=20 > (1) Can pre-delivered public keys (via DNS? html? other?) be used to=20 > encrypt the handshake or even app data (e.g. Andy Lutomirski's=20 > "handshake keys" for protecting SNI, or "semi-static public keys" for=20 > 0-RTT initial connections)? >=20 > (2) Should 0-RTT reconnection be achieved via a traditional=20 > session-ticket flow, or through a new flow based on caching a=20 > semi-static public key? >=20 > (3) For either sort of zero-RTT reconnection, how do we design an=20 > "anti-replay" capability which is practical and scaleable, and doesn't=20 > leak tracking info? >=20 > (4) For zero-RTT cases, should we overlay an additional DH exchange on=20 > the 1st RT to increase forward secrecy for subsequent data? Or should=20 > this be accomplished by a more general re-handshake capability? >=20 > (5) Assuming we go with the zero-RTT semi-static key approach for=20 > reconnection, should we also re-implement the initial handshake in=20 > terms of it (i.e. spend the 1st RT to retrieve the semi-static key),=20 > which makes things simpler but otherwise is less optimal than=20 > retrieving a fresh ephemeral? >=20 > (6) Should we stick with a signed-DH key agreement, or consider=20 > alternatives (e.g. SKEME, MQV, NTor, TripleDH, other?). >=20 > (7) Should client auth be integrated into the handshake or moved to a=20 > post-handshake, channel-bound layer? >=20 > (8) Should the protocol be integrated (somehow) with TCP or a TCP=20 > replacement (e.g. QUIC, MinimaLT, TCPcrypt)? >=20 > (9) What should be done to minimize tracking / info-leaks in the=20 > protocol (e.g. remove / randomize session tickets / SessionIDs, remove=20 > other options, Elligator-type indistinguishability, more padding)? >=20 > (10) Stylistic decisions: > - choice of ciphersuites? > - preserve TLS message formats or replace them? > - larger extension spaces? (end the 16-bit suffering!) >=20 > etc.... >=20 > Trevor >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham http://www.mnot.net/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 16 17:17: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 E28B81A0057 for ; Wed, 16 Apr 2014 17:17:42 -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 WqxT-bctOVmU for ; Wed, 16 Apr 2014 17:17:41 -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 D611E1A0046 for ; Wed, 16 Apr 2014 17:17:40 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so11471998wgh.0 for ; Wed, 16 Apr 2014 17:17: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:date :message-id:subject:from:to:cc:content-type; bh=Va8foh0YfXsolSCOo3bEjWnlukuz1t43xFKris+OI38=; b=CUT/HbWQYyzfjHHpQub+hrgPH3XZsQNLCPeNXsYoigej1WzNLa2sXlCUmQ+zJ7dXm3 xLLTlvpp5pDUuwTT/L69F3NvOILdi43Gi3auqJEBf64OkX6hl2DXX6ej1AX/uLs648PQ EAhLLKjod4BsXLbBia2SVhhCjH3JCLhUOoRlMSCpynab80abm6737frveZoDCzObvGem O1RSpq5ofxwiUv03G7XU7SQu7Rx6pEaVjh5MdK6Lm8f7JMgvkA/aWHlo8odiGR/yjcVI QBV0+ZCuNZYKpNBJPG19Wrn5ODGX+iakzBZC0JJ+XOA6JBUuAGHmR6S7V0YbACef8Sjl RJAQ== X-Gm-Message-State: ALoCoQlk+glmH6XTAHZP6CCYWSzj6juXuqCTljvA9cCFwo5j82XSM4il5OYu51ZDJh4EilLfY+aM MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr9706178wiw.56.1397693857007; Wed, 16 Apr 2014 17:17:37 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 16 Apr 2014 17:17:36 -0700 (PDT) X-Originating-IP: [173.11.71.217] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> Date: Wed, 16 Apr 2014 17:17:36 -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/EvUEqIbwzadSUvxurRSGFp9UtX4 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:17:43 -0000 On Wed, Apr 16, 2014 at 4:45 PM, Martin Thomson wrote: > On 16 April 2014 16:21, Trevor Perrin wrote: >> * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down >> profile of TLS 1.2, without major handshake changes or new features, >> aiming to finish in a few months. > > I want a pony too, but since the latency improvements are the main > reason we have people interested in TLS 1.3, I'm pretty sure that a > plan like this won't have the desired effect. I wasn't going to bring ponies into this. But since you started - I think the people expecting that the WG can quickly make some "minimal" changes to 5246 that turn it into a 0-RTT, encrypted handshake, more "privacy-friendly" protocol are the ones being unrealistic. If you want a quick update to 5246, then a cleanup is feasible. If you want everything in the charter, then we're designing a new protocol. I think both are valuable, and I disagree with your claim that no-one would be interested in the former. Several people have already expressed interest (Adam Langley, Peter Gutmann, myself, Alyssa). Trevor From nobody Wed Apr 16 17:24:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED381A0059 for ; Wed, 16 Apr 2014 17:24:38 -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 kO-c_JtgFYvD for ; Wed, 16 Apr 2014 17:24:36 -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 B626B1A0046 for ; Wed, 16 Apr 2014 17:24:35 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so11364431wes.4 for ; Wed, 16 Apr 2014 17:24:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rFBHMjm/zDPl+UDmNIJdgT/7ngHDzx+z0SnyjurAGh0=; b=OjK1hSDDlPrCngcRLBCygxC0SlYrDnFk9SZzeSQf7yYUNpi9rsfsrOW/lQXLTZoBVZ KzVUDTHybk1MDWpscShwWoEr7rBsEAVQTxeSNzdfWvJr0QfMG/A7376up4lqTYTyjzCK RGaCbTbRfSbiQnpaQxq9r98auWLmGJ02j006Bp9+fDco3JCPQru/afT+RoJQjEdcCsjH XzR9VaKeXGfDrKaRETd6drCOJLBWPUMFaooM+YFf5ydYpYIR1PIP+4k66MTMhXOxw/W7 eRkgGAGitB65xfP+Q1HVmUBhSypEcUAhrkp7OmVLUrKGyGDIlC0K6rmWm3EjF7fWOA4s EWsw== X-Gm-Message-State: ALoCoQm1/IlQYozlOK6kWKxvK/SQLeIN4VwvJeQcxYP77YyGFFIRamEHI4LvpJV1QI3/fzf6j+6e MIME-Version: 1.0 X-Received: by 10.180.78.41 with SMTP id y9mr8261397wiw.26.1397694271890; Wed, 16 Apr 2014 17:24:31 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 16 Apr 2014 17:24:31 -0700 (PDT) X-Originating-IP: [173.11.71.217] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> Date: Wed, 16 Apr 2014 17:24:31 -0700 Message-ID: From: Trevor Perrin To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zM8EWCUikg01fpdgzKpKXYy5OyI Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:24:38 -0000 On Wed, Apr 16, 2014 at 5:08 PM, Mark Nottingham wrote: > I strongly agree with the notion that bakeoffs are, at best, inadvisable. I think designing complex crypto protocols in the IETF is generally inadvisable. But that's what our charter sets out. > The IETF isn't set up to do this sort of thing; the best way to get traction here is to get implementation experience / buy-in. Agreed, but we don't have an existing 0-RTT protocol to base off (unless people want to start with QUIC). I think soliciting proposals and then choosing one to work on via the WG process is the best way approximate that. > Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO. I don't see why. I think they'd be different efforts attracting different folks - hopefully we could get some implementors and practically-minded people to help clean up 1.3, while researchers / designer-types cook up TLS 2 proposals. Trevor From nobody Wed Apr 16 17:43: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 49E4A1A042F for ; Wed, 16 Apr 2014 17:43:36 -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 tBDsP0sLGht0 for ; Wed, 16 Apr 2014 17:43:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id B5E441A042E for ; Wed, 16 Apr 2014 17:43:31 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.14.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B208922E253; Wed, 16 Apr 2014 20:43:21 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: Date: Thu, 17 Apr 2014 10:44:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> To: Trevor Perrin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z17w0ic2PocVq2G5CmJaLu6-xrc Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:43:36 -0000 On 17 Apr 2014, at 10:24 am, Trevor Perrin wrote: > On Wed, Apr 16, 2014 at 5:08 PM, Mark Nottingham = wrote: >> I strongly agree with the notion that bakeoffs are, at best, = inadvisable. >=20 > I think designing complex crypto protocols in the IETF is generally > inadvisable. But that's what our charter sets out. >=20 >=20 >> The IETF isn't set up to do this sort of thing; the best way to get = traction here is to get implementation experience / buy-in. >=20 > Agreed, but we don't have an existing 0-RTT protocol to base off > (unless people want to start with QUIC). >=20 > I think soliciting proposals and then choosing one to work on via the > WG process is the best way approximate that. >=20 >=20 >> Working on TLS 2 at the same time as TLS 1.3 is in active development = is asking for both to fail, IMO. >=20 > I don't see why. I think they'd be different efforts attracting > different folks - hopefully we could get some implementors and > practically-minded people to help clean up 1.3, while researchers / > designer-types cook up TLS 2 proposals. =46rom an HTTP perspective, the interest in TLS 1.3 is reducing latency; = taking that off the table and pushing it out to a TLS2 that's risky = (both in terms of schedule and viability) isn't workable. Regards, -- Mark Nottingham http://www.mnot.net/ From nobody Wed Apr 16 17:45: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 C3ED41A042E for ; Wed, 16 Apr 2014 17:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IulwGE5rUs02 for ; Wed, 16 Apr 2014 17:45:28 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 096361A0325 for ; Wed, 16 Apr 2014 17:45:27 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id e16so8751962lan.16 for ; Wed, 16 Apr 2014 17:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zgv+4nz1s/rarz3ySoPlajW9FNJyyW00Jy1hQcMyWS8=; b=Jp7Sd4dfUKn/e/mPNbxc5N6WozyrHQyQmdLjY9BEeJnMYoEPCAryBpHMiRmDoNce8B XteANHw+5whGHKJC8WjH01j6Qg1EffVkn3Nsl3cJU7NrAIvRhGXRd+GWKUpihdJHfrKG tOc7VpS9RbWvyPVoEawGn0M9u58wqXG3LuNVITW/SwTTn+X9L+H8KaLGJgObTgUuowKD DtrxMenIUlIpLJTCOPDeQg3D1hmzXKgoc7kqXcPaRkkLGs7DAgngvVyEf2kOXPJoAH/g dBh1JsU6jx1D5i0smHQ61Qi3b9zi50R5kfZ2zmazTHtHdBH7oXIgnptwj6WWE+HSN8zT OGNQ== MIME-Version: 1.0 X-Received: by 10.112.254.163 with SMTP id aj3mr4707056lbd.20.1397695523743; Wed, 16 Apr 2014 17:45:23 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.35.131 with HTTP; Wed, 16 Apr 2014 17:45:23 -0700 (PDT) In-Reply-To: <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> Date: Wed, 16 Apr 2014 17:45:23 -0700 X-Google-Sender-Auth: 2x7f1sKQw1Y-XkDp-r7XYqsLzYQ Message-ID: From: Adam Langley To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iLB_Q5Wd6HDD-8DFCk64A-fJUoA Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 00:45:30 -0000 On Wed, Apr 16, 2014 at 5:44 PM, Mark Nottingham wrote: > taking that off the table and pushing it out to a TLS2 that's risky (both in terms of schedule and viability) isn't workable. I think that any 0-RTT variant of TLS is risky in terms of schedule and viability, whether it's called 1.3 or 2.0. That's the thing that makes it risky! Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Apr 16 18: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 7F4131A02E3 for ; Wed, 16 Apr 2014 18:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_36=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 rEMbkgyuJO9I for ; Wed, 16 Apr 2014 18:13:34 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 035511A0148 for ; Wed, 16 Apr 2014 18:13:33 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id s7so10767456qap.21 for ; Wed, 16 Apr 2014 18:13:30 -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=o7LIKWulk21SGPg3xFXdFIykUT4KkAhFfoH36b2LivM=; b=ctGlhjJd0MhGrrvBMZRHS/hN5NLMqBslnVfWS36VrEJLXiixESL0lWTyaMrHU5qpJ0 WXHT7QwA61NwiR7hgBSbIPhnJSmg8GYaoT1aEDgWijXnMgW5IGXuDeMRcuq+iL5v6GkI OL7SAOZfax3jXLuAj0fjuqMtmsGZLBPtgpP1Egm+D5xl2xvuK8NtTmQb2+yd6EGQySK+ QPr25w9DE87ubQlTzq/cH9fRa5AySH3mkx439JxJ96UU8yz0ngBdLcYAFpTwFpJP7e9d xDToGhNbstZAy6CM1xxfZX12psdJtODl0A+hYnucwiS5EeUN7VJrV51a6rXvTa3GseZz jSlQ== X-Gm-Message-State: ALoCoQkdYER1HYN1WHPC1VUSEP8ITWxtYJfXszxBJXlkEi7h3DT6kVsaDs3h91ICLwZvPi158qX3 X-Received: by 10.224.160.206 with SMTP id o14mr9165921qax.44.1397697210332; Wed, 16 Apr 2014 18:13:30 -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 u59sm30776160qga.8.2014.04.16.18.13.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 18:13:29 -0700 (PDT) Message-ID: <534F2ABB.7060505@nthpermutation.com> Date: Wed, 16 Apr 2014 21:13:31 -0400 From: Michael StJohns 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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z1_qWDktu0a36V47bv2k_lmwYqQ Subject: [TLS] draft-stjohns-tls-tls13-crypto-infra X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 01:13:36 -0000 Hi - I submitted draft-stjohns-tls-tls13-crypto-infra-00.txt last week. I'm hoping to get some discussion started on updating the TLS handshake cryptographic constructs to something that can be implemented in a secure and general manner in hardware. The current constructs have some issues in that its difficult to impossible to use them in a manner that ensures that key material can never be extracted from the hardware. There are two reasons for the current issues: 1) the use of the master secret as both a secret key for a MAC operation, and as key for a key expansion operation; 2) The key expansion function produces both key material (the 4 secret keys for encryption and record mac) and public material (the client and server write IVs). The issues with these became apparent when trying to update the PKCS11 specification to support TLS1.2. Part 1 Issue - Mac vs Key Expansion To understand the issues, let's first compare the MAC function and the key expansion function first and let's assume the PRF is based on HMAC-SHA256. I'm going to use the TLS1.2 definitions, but much of this applies to TLS1.1 and before. The MAC function produces the verify data as > verify_data > PRF(master_secret, finished_label, Hash(handshake_messages)) > [0..verify_data_length-1]; Given that PRF is > PRF(secret, label, seed) = P_(secret, label + seed) and that P_ ends up being (since you only need 12 octets of data) > P_hash(secret, seed) = HMAC_SHA256 (secret, HMAC_SHA256(secret, seed) + seed) But "seed" above is "label + SHA256(handshake_messages)" - or really "label + random data". verify_data = HMAC_SHA256 (master_secret, HMAC_SHA256 (master_secret, seed) + seed); So calculating verify_data, if you didn't restrict how the master_secret was used, could be done using normal implementations of HMAC_SHA256 and SHA_256 and simply passing in processed data for the seed of "label + SHA256(handshake_messages") But now consider how key expansion works: > key_block = PRF(SecurityParameters.master_secret, > "key expansion", > SecurityParameters.server_random + > SecurityParameters.client_random); Which reduces down to (assuming only 32 bytes of key - easier to do the analysis) seed = label + server_random + client_random key_block = HMAC_SHA256 (master_secret, HMAC_SHA256 (master_secret, seed) + seed) which is the same expansion as above - just with different values for the seed. So the only output difference is that the MAC function is supposed to producing public data, while the expansion function is supposed to be producing secret data. But since they both use the same key and same underlying construct, we can't just use a generic HMAC_SHA256 function in hardware. We need to move up a couple of levels. So let's compare this if we define a TLS_PRF function (as was done in PKCS11 v2.20). key_block = PRF (master_secret, label, random_data); // random data is the concatenation of server and client random verify_data = PRF (master_secret, label, random_data); // random data == SHA256 of the handshake messages Still not enforceably cryptographically separate. So finally, we get to building specific functions: verify_data = TLS_MAC (master_secret, handshake_data, clientOrServer); - and - key_block = TLS_KDF (master_secret, client_random, server_random); Where the TLS_PRF is still the underlying function, but is not directly available to the user. The processing specified as above in the verify_data step and the key expansion step is used to provide the two types of data. The value of the label for each of these functions is fixed. But we still have a problem - the TLS master key has to be marked specifically as a TLS master key within the hardware module, otherwise it can be used directly with the HMAC_SHA256 function. So instead of being able to define generic functions to do this, we have to implement specific TLS functions, and to update and change them with each version of TLS. Not ideal, but at least tractable. It has an interesting side effect that you may no longer be able to use the construct for key material exporters. Unfortunately, that leads to the second problem. Part 2 - the Key Expansion Issue > key_block = PRF(SecurityParameters.master_secret, > "key expansion", > SecurityParameters.server_random + > SecurityParameters.client_random); The above construct generates a key stream of length 2* (mac_key_length + enc_key_length + fixed_iv_length), and that key stream is then split into up to six parts, 4 of which are the secret key materials for the mac and encryption keys, but 2 of which are used for the IV - initialization vectors. > client_write_MAC_key[SecurityParameters.mac_key_length] > server_write_MAC_key[SecurityParameters.mac_key_length] > client_write_key[SecurityParameters.enc_key_length] > server_write_key[SecurityParameters.enc_key_length] > client_write_IV[SecurityParameters.fixed_iv_length] > server_write_IV[SecurityParameters.fixed_iv_length What happens if you re-run the derivation using the same master_secret, same label and same random data, but you change the length of the component keys in a manner that keeps the total length of the key stream the same, but ends up with key material moving from the secret part of the stream to the public part of the stream? E.g. consider a suite that requires 32 bytes of mac key, 16 bytes of encryption key, and 16 bytes of IV. The total key stream length is 128 bytes. Re-run the derivation, but instead assign 16 bytes of key material to each mac key, 16 bytes to each encryption key and 32 bytes to each IV. The key material originally used to form the two encryption keys is now the 32 bytes of the client_write_IV. Since IVs are public, an attacker has successfully managed to extract key material. TLS1.1 deprecated the production and use of the IV generated this way, but TLS1.2 added them back in. The solution for this is intractable using the current construct definitions. (Consider that its perfectly acceptable for a suite to not have encryption keys and/or mac keys, so placing minimum values for individual key lengths does not solve the problem). _______________________________ The above would be a good enough reason to readdress these constructs, but the current constructs are also more expensive than they need to be for the security they provide: 1) Perhaps replace the current handshake MAC function with a simple HMAC or CMAC function. Is there any security reason to do a hash of the handshake messages before being MAC'd? 2) The current PRF is recursive which makes it difficult to parallelize. It was based on the original SSL PRF, but wasn't really looked at when the SHA1/MD5 construct was replaced. Instead, use one of the pseudo-random functions from SP800-108 based on counters. That function could be used either with a master key (for key expansion) or with a key of '0' (for pseudo-random data production for things like IVs). From my point of view, I'd really like to eliminate TLS specific constructs and instead define TLS in terms of cryptographic constructs defined and evaluated elsewhere. Mike From nobody Wed Apr 16 18:48: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 9538D1A001A for ; Wed, 16 Apr 2014 18:48:41 -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 2uJn-Yar3HFO for ; Wed, 16 Apr 2014 18:48:40 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6428D1A03B6 for ; Wed, 16 Apr 2014 18:48:40 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id z60so3585992qgd.0 for ; Wed, 16 Apr 2014 18:48:36 -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:content-type; bh=SkEP3Jzz569Zi1Gt0T8C12hnHqqZVXIxr0T9mLDmpD4=; b=mYsO9x2jNTvw2xRXRk3+c2FQURrdakG7DSKCijmoQ2z7IsIZyFun4Y/gENyTb9Sxky gZarwtWg5DafR7CC+zYoPr9vnB+NQ21P7rko6Gq698eSK40TRODrpREUlD7FSjEKIVy7 XsP0srN6CAs4NAn4V3qPTxXFdBte2eKsiF/QtAaWwLS9MdYMZlqJd8pJ/Ww7/jho3ssF SqM3r2/IS6ta36OxmXTneQ12/sXhcnP0ZvBFB9dR+pgzKxW56IAQ5H8XlIidGQDUh8GO aLfIHv1U9SqJD+8K7P2HAcUZEXbRgTo1+XQxDHwzOcmxbsHoIrC+Abz1PYXu1J/55afC 6jXg== MIME-Version: 1.0 X-Received: by 10.140.88.210 with SMTP id t76mr13723189qgd.15.1397699316859; Wed, 16 Apr 2014 18:48:36 -0700 (PDT) Sender: patrick.ducksong@gmail.com Received: by 10.140.93.180 with HTTP; Wed, 16 Apr 2014 18:48:36 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> Date: Wed, 16 Apr 2014 21:48:36 -0400 X-Google-Sender-Auth: 257HgTiRxsZdLpIa2IcFgN89kwo Message-ID: From: Patrick McManus To: "" Content-Type: multipart/alternative; boundary=001a11c134c248c63004f7333bf3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WLBvjgmSRXHzkVR17cJId8XbXjI Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 01:48:41 -0000 --001a11c134c248c63004f7333bf3 Content-Type: text/plain; charset=UTF-8 HI All - I'm the module owner for mozilla's HTTP stack and related things. I am very supportive of the TLS 1.3 charter because I earnestly believe it is largely the latency issues associated with current TLS standards that make it difficult for https to compete with http performance. The result is more plaintext and that sucks for users. I hope addressing that will be the focus of 1.3. There is some urgency in addressing that bottleneck - and that urgency isn't especially compatible with a ground up rework imo . Someone upthread hit the nail on the head for me when they said that what is being discussed isn't really a bake off of competing solutions, but really a CFP of competing ideas. There seems to be general agreement that incremental improvements and standardization of existing technologies are the areas the IETF is able to execute well in. If a non-TLS technology is able to make a meaningful mark in this space and then presents itself for standardization too - then that's a good problem to have. But that is putting the cart in front of the horse by a considerable bit. -Patrick --001a11c134c248c63004f7333bf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI All - I'm the module owner for mozil= la's HTTP stack and related things.

I am very support= ive of the TLS 1.3 charter because I earnestly believe it is largely the la= tency issues associated with current TLS standards that make it difficult f= or https to compete with http performance. The result is more plaintext and= that sucks for users. I hope addressing that will be the focus of 1.3. The= re is some urgency in addressing that bottleneck - and that urgency isn'= ;t especially compatible with a ground up rework imo .

Someone upthread hit the nail on the head for me when they said t= hat what is being discussed isn't really a bake off of competing soluti= ons, but really a CFP of competing ideas. There seems to be general agreeme= nt that incremental improvements and standardization of existing technologi= es are the areas the IETF is able to execute well in.

If a non-TLS technology is able to make a meaningful mark in this= space and then presents itself for standardization too - then that's a= good problem to have. But that is putting the cart in front of the horse b= y a considerable bit.

-Patrick
--001a11c134c248c63004f7333bf3-- From nobody Wed Apr 16 19:29: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 79BEB1A01EE for ; Wed, 16 Apr 2014 19:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp3Kn9_ua1y7 for ; Wed, 16 Apr 2014 19:28:55 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id EC45F1A03E4 for ; Wed, 16 Apr 2014 19:28:53 -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 s3H2SmT2005580; Wed, 16 Apr 2014 19:28:48 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1ka5ear3s4-45 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Apr 2014 19:28:48 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 16 Apr 2014 19:28:43 -0700 From: Paul Lambert To: James Cloos , "tls@ietf.org" Date: Wed, 16 Apr 2014 19:29:09 -0700 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9Z5MBjbk/xnlQIQe+JtE5/srSHYw== Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-17_01:2014-04-16,2014-04-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404170036 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RdpR5kJTjjTLsoKmDu-STQ1DqKc Cc: Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 02:28:59 -0000 On 4/16/14, 11:32 AM, "James Cloos" wrote: >>>>>> "AL" =3D=3D Andy Lutomirski writes: > >AL> US-governement-preferred choice: ECIES/Elligator Squared on P-256, >AL> with AES-128-GCM. > >DJB's parallel paper (http://cr.yp.to/snuffle/bruteforce-20050425.pdf) >implies all should s/AES-128/AES-256/g. Especialy when there is a >significant quantity of traffic available for probabilistic attacks. These type of parallel HW attacks are facilitated by CCM/GCM modes. AES-SIV would not be easily mapped into such a attack. Paul > >(I presume those who like NIST crypto will be happy with >AES256-GCM-SHA384.) > >-JimC >-- >James Cloos OpenPGP: 1024D/ED7DAEA6 > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Wed Apr 16 19:38: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 784C21A00D1 for ; Wed, 16 Apr 2014 19:38:39 -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, FM_FORGED_GMAIL=0.622, GB_SUMOF=1, 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 SSVG3QHBIPsy for ; Wed, 16 Apr 2014 19:38:38 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2D96E1A0035 for ; Wed, 16 Apr 2014 19:38:37 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so8747262lab.38 for ; Wed, 16 Apr 2014 19: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=vwFLIbX/L8hailI2aZMnd7+X6aY31UfBRAtkzRwUqKY=; b=kSryBGebvNdjDDaGhdEIuLzcOH7XH3Lg73fpiL4VVUG9MkIUWpCOfmbbwAYPHvKLwF HCL900g2t6HsjzqGPUMGtTWKox897rqLE9X5wUd33NvlUZKSP/On/KGFXYxWq53V4giQ FFDa8df1al8Wb9OV4iTerns4WZH2ParNSm9f0HjNKR+Xj7cDxtes+eUpZXfD7vvHe2hM 9LBNdVNJqo+0YedVDW6Ckm/A2718lN7GgWWXfeJhveYyMkO56loxpoBsaSsEEVftGeKT Ls9nV/GEJQQT38heeE3gaimaUE72QeTsmr2CRaXPk3Ry+wwxpkKTgD5GVRv66DqNJkbq EaPQ== X-Gm-Message-State: ALoCoQmek/BA2/DAi18FSZsFXmnl9F9Z21fLEzLdw0K6MkFE9hUu3azWCULWENSsWS1HezAEQacV X-Received: by 10.152.18.135 with SMTP id w7mr7708812lad.29.1397702314109; Wed, 16 Apr 2014 19:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 19:38:14 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 19:38:14 -0700 Message-ID: To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yd4W76XEf6mvzgQGpiMVHnjX8Aw Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 02:38:39 -0000 On Wed, Apr 16, 2014 at 7:29 PM, Paul Lambert wrote: > > > On 4/16/14, 11:32 AM, "James Cloos" wrote: > >>>>>>> "AL" == Andy Lutomirski writes: >> >>AL> US-governement-preferred choice: ECIES/Elligator Squared on P-256, >>AL> with AES-128-GCM. >> >>DJB's parallel paper (http://cr.yp.to/snuffle/bruteforce-20050425.pdf) >>implies all should s/AES-128/AES-256/g. Especialy when there is a >>significant quantity of traffic available for probabilistic attacks. > These type of parallel HW attacks are facilitated by CCM/GCM modes. > AES-SIV would not be easily mapped into such a attack. Let's focus on the handshake encryption part, as opposed to the actual selection of cipher suite. After all, I think it's pretty clear that acceptable cipher suites exist, and selecting them won't be terribly hard. FWIW, the chosen AEAD construction needs to be indistinguishable from random, too. GCM should be okay: the tag is the encryption of a plaintext block that should only occur once for the lifetime of a key. Poly1305, at least as it's likely to be instantiated, should be okay for the same reason: the tag is the sum of two effectively independent terms mod 2^128, and one of those terms is indistinguishable from random. --Andy From nobody Wed Apr 16 19:46: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 6EFC31A03D5 for ; Wed, 16 Apr 2014 19:46:53 -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 JWpuYXdcuHon for ; Wed, 16 Apr 2014 19:46:49 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3BA1A03D4 for ; Wed, 16 Apr 2014 19:46:49 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so11517095veb.41 for ; Wed, 16 Apr 2014 19:46:45 -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=QYP98ylSYHHsUzT73Cy7Tdt1EGh9Aq4ugFnM37y41C4=; b=qkUVU4X5c4g+QMDN3kBXh6ZqvnDpstFUmOzhjjeXUKE1i+cGYdRAuXwQO+N163fHSX 7UVMIN1qhrGlR56IGt6XaDLMPSLRR786kzVaZP5EMcecz7NMNsBsxYRDOMDX89EwWWNq 7TQmgHKwI+T4mSxJoGnTgoVbLxLw1Ems7Yoy6ttrnCXcFUhP7PMjD9cQ7uE6ZDpRzS3S UdWbC5Z+sgINEl3MGwJu/JazTO5fw5wQX/tAukwMoJ/Mv9sswY54Z9+SqjP6havbpWzN /I7anBWREz0r714VcrSx+qrBu344oksYhRy3GX2ZwP853IitHbfELtxmLdwmfaO8nvsy OUew== MIME-Version: 1.0 X-Received: by 10.58.31.136 with SMTP id a8mr5279724vei.20.1397702805847; Wed, 16 Apr 2014 19:46:45 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Wed, 16 Apr 2014 19:46:45 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> Date: Wed, 16 Apr 2014 22:46:45 -0400 X-Google-Sender-Auth: V_g1QVCwofpFsBLMNZnupWPjXis Message-ID: From: Erik Nygren To: Andy Lutomirski Content-Type: multipart/alternative; boundary=047d7b2e49d03e856604f7340b9c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hRC1kWJPXau7L-5TL-orPhCPP70 Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 02:46:53 -0000 --047d7b2e49d03e856604f7340b9c Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 3:09 PM, Andy Lutomirski wrote: > On Wed, Apr 16, 2014 at 11:56 AM, Erik Nygren > wrote: > > If we do anything with DNS, we need to be very conscious that individual > > records change asynchronously from other records. For example, we can't > > assume that an A/AAAA record and a DANE record refer to the same operator > > (webserver, hosting provider, CDN, etc). In order for anything along > these > > lines to be deployable, it must be possible for everything associated > with a > > particular name->service binding to change together. In addition, > browser > > vendors are extremely wary of doing extra DNS lookups synchronous to a > > request which is one reason that SRV records aren't in-use today for > > HTTP(S). > > You can hack around this by temporarily turning off hello encryption > when switching providers. This is unfortunate, though. > In my experience, anything of this form not designed to be easy to operate, reliably support rotation, and robustly move between providers is likely to fail to be deployable. Errors in this world seems to be a top cause of outages and this sort of thing can be very hard to reason about. Sadly, anything that requires "hack around" as part of its normal operating regime just isn't going to work. I'm not sure exactly what you mean by handshake_token. Do you mean > the anti-replay token? > The handshake token as a way of identifying the service binding in use > seems problematic to me. Wouldn't it be better to just leave it out > entirely? As long as each IP only accepts one or two handshake keys, > then figuring out which one is in use by trial decryption should be > fine. I think that something is wrong if you have an IP with lots of > handshake keys. > > Realistically, you may need up to four handshake keys: old FIPS, new > FIPS, old non-FIPS, new non-FIPS. > Perhaps handshake_key_label would have been a better term. I was referring to what is in PredictedParameters.server_key_label in ekr's tls13-new-flows (which has the same problem if not handled properly, and even if used properly still has risks here which may not have good answers). There are plenty of valid scenarios where you may need considerably more than four. An example given earlier on the list is for VM/cloud hosting providers who need to demultiplex from a small number of IPv4 addresses to different backend servers being run by different entities without mutual trust, each of which having independent different sets of keys. Erik --047d7b2e49d03e856604f7340b9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 16, 2014 at 3:0= 9 PM, Andy Lutomirski <luto@amacapital.net> wrote:
On Wed, A= pr 16, 2014 at 11:56 AM, Erik Nygren <erik+ietf@nygren.org> wrote:
> If we do anything with DNS, we need to be very conscious that individu= al
> records change asynchronously from other records. =C2=A0For example, w= e can't
> assume that an A/AAAA record and a DANE record refer to the same opera= tor
> (webserver, hosting provider, CDN, etc). =C2=A0 In order for anything = along these
> lines to be deployable, it must be possible for everything associated = with a
> particular name->service binding to change together. =C2=A0In addit= ion, browser
> vendors are extremely wary of doing extra DNS lookups synchronous to a=
> request which is one reason that SRV records aren't in-use today f= or
> HTTP(S).

You can hack around this by temporarily turning off hello encryption<= br> when switching providers. =C2=A0This is unfortunate, though.

In my= experience, anything of this form not designed to be easy to operate, reli= ably support rotation, and robustly move between providers is likely to fai= l to be deployable.=C2=A0 Errors in this world seems to be a top cause of o= utages and this sort of thing can be very hard to reason about.=C2=A0 Sadly= , anything that requires "hack around" as part of its normal oper= ating regime just isn't going to work.
=C2=A0


I'm not sure ex= actly what you mean by handshake_token. =C2=A0Do you mean
the anti-replay token?
The handshake token as a way of identifying the service binding in use
seems problematic to me. =C2=A0Wouldn't it be better to just leave it o= ut
entirely? =C2=A0As long as each IP only accepts one or two handshake keys,<= br> then figuring out which one is in use by trial decryption should be
fine. =C2=A0I think that something is wrong if you have an IP with lots of<= br> handshake keys.

Realistically, you may need up to four handshake keys: old FIPS, new
FIPS, old non-FIPS, new non-FIPS.

Perha= ps handshake_key_label would have been a better term.
I was r= eferring to what is in PredictedParameters.server_key_label in ekr's tl= s13-new-flows
(which has the same problem if not handled properly, and even if= used properly still
has risks here which may not have good = answers).=C2=A0

There are plenty of valid scenarios wher= e you may need considerably more than four.
An example given earlier on the list is for VM/cloud hosting pro= viders who need to demultiplex
from a small number of IPv4 addresses to = different backend servers being run by different
entities wit= hout mutual trust, each of which having independent different sets of keys.=

=C2=A0 =C2=A0 =C2=A0 Erik

--047d7b2e49d03e856604f7340b9c-- From nobody Wed Apr 16 19:53: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 585791A03DA for ; Wed, 16 Apr 2014 19:53:54 -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 ODexhUVioGUv for ; Wed, 16 Apr 2014 19:53:53 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8951A03D4 for ; Wed, 16 Apr 2014 19:53:53 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id EB2CD4012D68D for ; Wed, 16 Apr 2014 19:53:49 -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=69EZlARgPqBtCPyR+8Vj d6TkUmM=; b=OaIfiGPRtUT1FuldOVyKFlUwJwpTYwdRy3NwCCPvBWo9N+zoo32w dW+tq9gQIHPjb+v944hPHAn1OISZd0M+wLYdtf6caGOyoPZNUFpCzI2WXsVgm+cr toGvM5lzTYdDu1ACX27HK0SfzyuC8tOPYY5BMq/EkxNNdjuApgRpjjc= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 98A5A4012D68C for ; Wed, 16 Apr 2014 19:53:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so185506wiv.15 for ; Wed, 16 Apr 2014 19:53:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.76.146 with SMTP id k18mr12763953wiw.5.1397703228186; Wed, 16 Apr 2014 19:53:48 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 16 Apr 2014 19:53:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Apr 2014 21:53:48 -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/RlmOFd_6VW3btlAxXsvvy5iPA3E Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 02:53:54 -0000 I've thought more about this and... I've changed my mind. We should remove renegotiation. I'll post separately about how we should cover the uses of renegotiation that we've seen or discussed. Nico -- From nobody Wed Apr 16 20:08: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 BD3981A0052 for ; Wed, 16 Apr 2014 20:08:54 -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 cbU7-3h_C2NN for ; Wed, 16 Apr 2014 20:08:49 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4921A0039 for ; Wed, 16 Apr 2014 20:08:49 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gl10so9055674lab.28 for ; Wed, 16 Apr 2014 20:08:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YTvvCtPEbMJYQwNUp78rFFuJgUnrOG8EuJJvbR5cQg8=; b=hDr+n/dorlb8dgMDMznz0TkY0xAcYuO9REvUl6qXh/jm75TqOsoPc7UqxodZaX/HiX 0TISX80eFLdlN7tPvmjiRyNqAOcivrE/b62gi/Uf1Qe8ZQeu5kLzcQGApL5Gh/2IQNBK tL++fn5YOAUj/4pXp3yRIhadNaZgjEON72dTjXmRRPJq5/dIJILyZzU0GcwejmySAwcY 75162XZRZX3B+BJgFx6HbXXYGjnGpb6C3crFHZZd2VwN2u9qV974iTX7aTbO+mZFo53e bVFOTqdzhVrcJL/lH9xAijFm8zOi7HDgFm/RCaLo2pM642topIWTsQIHbm5jIqmOyaix M63w== X-Gm-Message-State: ALoCoQnIWxri0EAHmC2t1cF4Q6ywKjgPN1RAZPXX2FcT9eagifKV9XHD1kipWbT2+fVq1enCdpwI X-Received: by 10.152.6.2 with SMTP id w2mr7865335law.28.1397704125059; Wed, 16 Apr 2014 20:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Wed, 16 Apr 2014 20:08:24 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> From: Andy Lutomirski Date: Wed, 16 Apr 2014 20:08:24 -0700 Message-ID: To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jB2Ku5P_Jv2Lrjzc7q22kfPOHcs Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 03:08:55 -0000 On Wed, Apr 16, 2014 at 7:46 PM, Erik Nygren wrote: > > On Wed, Apr 16, 2014 at 3:09 PM, Andy Lutomirski > wrote: >> >> On Wed, Apr 16, 2014 at 11:56 AM, Erik Nygren >> wrote: >> > If we do anything with DNS, we need to be very conscious that individual >> > records change asynchronously from other records. For example, we can't >> > assume that an A/AAAA record and a DANE record refer to the same >> > operator >> > (webserver, hosting provider, CDN, etc). In order for anything along >> > these >> > lines to be deployable, it must be possible for everything associated >> > with a >> > particular name->service binding to change together. In addition, >> > browser >> > vendors are extremely wary of doing extra DNS lookups synchronous to a >> > request which is one reason that SRV records aren't in-use today for >> > HTTP(S). >> >> You can hack around this by temporarily turning off hello encryption >> when switching providers. This is unfortunate, though. > > > In my experience, anything of this form not designed to be easy to operate, > reliably support rotation, and robustly move between providers is likely to > fail to be deployable. Errors in this world seems to be a top cause of > outages and this sort of thing can be very hard to reason about. Sadly, > anything that requires "hack around" as part of its normal operating regime > just isn't going to work. > I agree. Using "bindings" as you suggested is better. It also adds no extra round trips. > > >> I'm not sure exactly what you mean by handshake_token. Do you mean >> the anti-replay token? >> >> The handshake token as a way of identifying the service binding in use >> seems problematic to me. Wouldn't it be better to just leave it out >> entirely? As long as each IP only accepts one or two handshake keys, >> then figuring out which one is in use by trial decryption should be >> fine. I think that something is wrong if you have an IP with lots of >> handshake keys. >> >> Realistically, you may need up to four handshake keys: old FIPS, new >> FIPS, old non-FIPS, new non-FIPS. > > > Perhaps handshake_key_label would have been a better term. > I was referring to what is in PredictedParameters.server_key_label in ekr's > tls13-new-flows > (which has the same problem if not handled properly, and even if used > properly still > has risks here which may not have good answers). > > There are plenty of valid scenarios where you may need considerably more > than four. > An example given earlier on the list is for VM/cloud hosting providers who > need to demultiplex > from a small number of IPv4 addresses to different backend servers being run > by different > entities without mutual trust, each of which having independent different > sets of keys. > You still only need four. Remember that my ClientHello key is completely independent of the key associated with the server certificate, and that it can be stripped. Suppose that there are a thousand domains, all sharing a few IPv4 addresses, but actually served by 100 mutually distrustful backend servers. You would configure all thousand domains to share the same ClientHello key. The devices that own the IPv4 addresses would know the private key. Whenever a connection comes in, they decrypt the ClientHello, read the SNI, and forward the decrypted ClientHello to the appropriate backend. That backend server does not know the ClientHello private key, but it doesn't need to. Similarly, the thing that owns the IPv4 address does not need to know the backend server's private key. So you still only need one or two keys under normal circumstances and two or four while rotating ClientHello keys. --Andy From nobody Wed Apr 16 20:24: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 53A2F1A0024 for ; Wed, 16 Apr 2014 20:24: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 zHT96RosC_xH for ; Wed, 16 Apr 2014 20:24:48 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB01A007B for ; Wed, 16 Apr 2014 20:24:47 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f73so11660164yha.13 for ; Wed, 16 Apr 2014 20:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1urbsak5N7KG9ETyCltIXQVISZipC3twMnOSPcNPpR8=; b=uovVT/y6EDJbOXIFGxpCkmszrSabHa7SBrZE/jp0WZiOzEI4W+vJV2dVawO5RGmL3V 7g5w8TMLbOghSwF2ag6yZz1QR+EoDHN9zAg/G+bFhShb5YZgIeFtinABPOlLyainAI/w 8+kNdtd+HzAPbPnUEVu1lpj8T6eepDdAAcYXjARvV1g9FsoqMG1+VmNmipgzWvED36Bc cvVfFFaVPqzKOj6Inz4eoHlRv7Iavyj4EWPf8ahooXV3wDSpEaKaweHnBSec2rajBEFH MC+aLhyuc8B1k6vbVjvjwFOnOLV0fa7tpaJ0wEjJt2IdvqoUoT/Szrht4DFTBRffhmEd Ibug== MIME-Version: 1.0 X-Received: by 10.236.39.72 with SMTP id c48mr18458594yhb.89.1397705084419; Wed, 16 Apr 2014 20:24:44 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 16 Apr 2014 20:24:44 -0700 (PDT) In-Reply-To: References: <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> Date: Wed, 16 Apr 2014 20:24:44 -0700 Message-ID: From: Watson Ladd To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/refZRCOH8tjze-F6-qgWXm8c_t4 Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 03:24:49 -0000 Dear all, I support most of the removal ideas. I would like to note in particular that 3DES has a 64-bit block, which limits the transferable data to 2^32 blocks, and so as a backup to AES it is painful. (We would also need to fix the EtM problem with it: a lot of work that we don't have to do). I think DHE will fall before ECDHE, but they are similar enough ECDSA is a complicated story. Yes, it makes unnecessary use of a random number generator during signing. It is much safer to add 32 bytes to the secret key, hash that with the message, take that key, stretch to twice as long as the group order with the hash function. The inversion of k serves no purpose now that Schnorr's patent has expired. It cannot be batched. However, it is still very secure. I would like to see more performant alternatives develop, but from a security perspective it's fine. FIPS can do it however they can, and non-FIPS people will do it the right way. I don't think removal is the right decision at this juncture. Sincerely, Watson Ladd From nobody Wed Apr 16 20:43: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 A07081A0433 for ; Wed, 16 Apr 2014 20:43:20 -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_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 c0K8tYzWRJLz for ; Wed, 16 Apr 2014 20:43:16 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id 486EA1A00CD for ; Wed, 16 Apr 2014 20:43:16 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 19so10818422ykq.25 for ; Wed, 16 Apr 2014 20:43: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=cjxBv3JynBQHfcgGA911suiNc2/NqNz/OmQIIEvZ9qg=; b=WAXKdusVtmbgnGbDaS1mkAwwauk1+3+CZeXChnCFGSbn5U3AmfhZYNsh1IbXqH/KP1 bdzbmuyYTTnTB8sr0i7jcvALrcy2RtPY4mw9oJgFseIjkQmgkjXWbjsm5Yt6Q1n1Hrls 7OB0Vc4+plemEKdtyL2jrTn+dkcqmnOddIBL0qSndUdqq4Fbd8I5OY66UYEkbyyStp6Y aawZ7w50mcBUUMBjc5s3MEL/t0hA74ByRFvOT5ZM5Muo0k9yXKmLgpBSTIkXWbr5ja+l qEq9s6QIzmGHU0NNrWEsEkkVP1JJP1l6bRPHnVs6ulZk08h2F99c3lZrpPDV+jMjD3qt wp+w== MIME-Version: 1.0 X-Received: by 10.236.112.39 with SMTP id x27mr18506931yhg.103.1397706192731; Wed, 16 Apr 2014 20:43:12 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 16 Apr 2014 20:43:12 -0700 (PDT) In-Reply-To: <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> Date: Wed, 16 Apr 2014 20:43:12 -0700 Message-ID: From: Watson Ladd To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lm1I3GlU0IjYhOhRcAdkodGdGkI Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 03:43:20 -0000 On Wed, Apr 16, 2014 at 5:44 PM, Mark Nottingham wrote: > > On 17 Apr 2014, at 10:24 am, Trevor Perrin wrote: > >> On Wed, Apr 16, 2014 at 5:08 PM, Mark Nottingham wrote: >>> I strongly agree with the notion that bakeoffs are, at best, inadvisable. >> >> I think designing complex crypto protocols in the IETF is generally >> inadvisable. But that's what our charter sets out. >> >> >>> The IETF isn't set up to do this sort of thing; the best way to get traction here is to get implementation experience / buy-in. >> >> Agreed, but we don't have an existing 0-RTT protocol to base off >> (unless people want to start with QUIC). >> >> I think soliciting proposals and then choosing one to work on via the >> WG process is the best way approximate that. >> >> >>> Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO. >> >> I don't see why. I think they'd be different efforts attracting >> different folks - hopefully we could get some implementors and >> practically-minded people to help clean up 1.3, while researchers / >> designer-types cook up TLS 2 proposals. > > From an HTTP perspective, the interest in TLS 1.3 is reducing latency; taking that off the table and pushing it out to a TLS2 that's risky (both in terms of schedule and viability) isn't workable. Huh. Here I thought the fact that the MTI cipher suite is not secure would be of interest. We already have the cleaned up TLS 1.2 implemented: it's the first three ciphersuites most browsers are offering today+Chacha and 25519. The challenge is in documenting these changes, so that we can have stripped down code that only offers and supports these suites, and have interop without risky suites. (It's hard because of the install base, but we need to start somewhere). Remember, of the four issues TLS has today, only one (encrypt-then-mac) has a WG draft that has been LC'd. RC4 prohibition is en route, but no one has written a draft explaining 1/(n-1) record splitting. Oh, and I forgot anti-downgrade. We need that too because browsers will happily fall back to SSLv3, where BEAST works. That seems to be coming along fine. 0-RTT is not an easy feature. It has substantial impact on replay protection and forward secrecy. There are fundamental theoretical limitations in play. Furthermore, it is a misnomer: TLS happens over TCP, which has one round trip in opening a connection already. The best we can do on a short timescale is probably 1-RTT, by doing an ECDH exchange where the client guesses what the server wants to see. Sincerely, Watson Ladd > > Regards, > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > 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 Apr 16 20:50: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 1DC041A0444 for ; Wed, 16 Apr 2014 20:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 b60t3dLR_KVI for ; Wed, 16 Apr 2014 20:50:17 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 270461A043E for ; Wed, 16 Apr 2014 20:50:17 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id D77B226C063 for ; Wed, 16 Apr 2014 20:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=RtKIwv4cLfAPSmjxe4Lu/xkjBt0=; b=ibojUbKXvaI rK5guaaER/2dhvu4snO+0U2c8uf/BLZcFsYOHFBWtqeBrLKZE1Z2UZOBtgmMedNq M/rB0l9bLZOiB43071xTWmBKwHnwTTl85/QKD+yTHiUrzo5YRdSQanlcu/pPjjXQ J5tx59u6KBE4A6YT26Ugelaw+hEWyb20= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id A277426C05E for ; Wed, 16 Apr 2014 20:50:13 -0700 (PDT) Date: Wed, 16 Apr 2014 22:50:13 -0500 From: Nico Williams To: tls@ietf.org Message-ID: <20140417035011.GA25499@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/12gxtfXiPNyU1ARKLM6sBQ_9juA Subject: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 03:50:21 -0000 Real, supposed, and proposed uses of renegotiation: - rekeying - authenticate the client when needed rather than always at handshake time - privacy protection for the client's identity - privacy protection for the server's identity - privacy protection for the server identity desired by the client Supposing we ditch renegotiation we'll need replacements for these. My proposals: - For rekeying just introduce a CCS-like record whose purpose is to indicate that the sender is changing to new keys on the send side. The new keys are derived from the same master secret as the preceding keys, in the same way, but with a counter appended to the "key expansion" salt. There's no need to synchronize, but DTLS requires retransmission of such messages else when dropped the recipient will not be able to decrypt any subsequent messages. For DTLS we'll need an ACK message (huh?! DTLS doesn't have such a thing? nope. Weid!) - For authentication other than that provided by the initial handshake I propose application-specific solutions. Note that for authentication with public keys there's no need for extra round trips. For SASL applications we should define one or two SASL mechanisms to replace TLS' PKI-based client and server authentication. For HTTP see below. There are two patterns here: - server wants client to authenticate In a protocol like HTTP that'd be a 401 indicating what methods the client can choose from... Standard stuff. We'd add a public key / PKI method whereby the client sends a signature of the TLS channel binding, along with any cert chain, OCSP responses, ... - client wants server to authenticate E.g., the initial handshake selected an anon ECDHE ciphersuite. In a protocol like HTTP the client might assert its desire for the server to authenticate using a new request header. The authentication -again a signature of the TLS connection's channel binding- would return in a response header. This replaces the SNI protection use of renegotiation. Nico -- From nobody Wed Apr 16 21:38: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 6B3EB1A0454 for ; Wed, 16 Apr 2014 21:38:50 -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 Yxe20kjuUqDW for ; Wed, 16 Apr 2014 21:38:48 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88B1A0452 for ; Wed, 16 Apr 2014 21:38:48 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so11277049wes.8 for ; Wed, 16 Apr 2014 21:38: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=zuK0Nc2VIDVgTk/kl3E1hCbmZZMvpoOxH6dCS4sl1dE=; b=jXhdUICqqjLTVpYxyF10lsnBY7pS0LPDYwCbWgawVKiYxXhoUsokPV0ypHML7+KSiL WwvOtxEdvWtAl2R/l/kLomHXMfrzPyfte4hWvuyFKB2EYu9hSN+un7opy0wGXVioYejG 51RbanP1r/BZwQfMVuTdXACzJh2UaU7LyNoUmpxGkihEVjqu/EvvsF/2wpHh4kV3oQhj 8eL5R+1/wogI06W1A5lwpOpFD588ttQpEkwoXNTZ4sZRDm13Bc1ZiEDc+gMDRJ7SHJ5h E6AV6qHJutZWRVwPcYHSH8y+Mpq5viV5ajR5Tv3XIe1MtemPHFY+zg3Qweh2+ne5dMtI 1+wg== X-Gm-Message-State: ALoCoQkui72wXHQfwl50h1rpXOY6rbkb4ufUzylL3oqmIwHQiLQGq49lX/9BnHmUPq+XCn/C2F8p MIME-Version: 1.0 X-Received: by 10.194.201.73 with SMTP id jy9mr123681wjc.51.1397709524378; Wed, 16 Apr 2014 21:38:44 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Wed, 16 Apr 2014 21:38:44 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> Date: Wed, 16 Apr 2014 21:38:44 -0700 Message-ID: From: Trevor Perrin To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LqIC34uj-itnnFDjziZ2hWtgRLg Cc: "" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 04:38:50 -0000 On Wed, Apr 16, 2014 at 6:48 PM, Patrick McManus wrote: > HI All - I'm the module owner for mozilla's HTTP stack and related things. > > I am very supportive of the TLS 1.3 charter because I earnestly believe it > is largely the latency issues associated with current TLS standards that > make it difficult for https to compete with http performance. The result is > more plaintext and that sucks for users. I hope addressing that will be the > focus of 1.3. There is some urgency in addressing that bottleneck - and that > urgency isn't especially compatible with a ground up rework imo . Unfortunately, charter goals like (encrypted handshake, 0-RTT reconnect, privacy-friendly) do require a major rework of the TLS handshake. See Eric's proposal for one example [1]. Of course, there's other ways to do these things (e.g. session tickets instead of semi-static keys for 0-RTT reconnects; TLS-inside-TLS or renegotiation instead of semi-static keys for handshake encryption). So I think it's worth taking the time to consider all these, instead of rushing to paint ourselves into one corner of the design space. Trevor [1] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01 From nobody Wed Apr 16 22:42: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 8204E1A004A for ; Wed, 16 Apr 2014 22:42:04 -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 mEEJ3vnUG5SC for ; Wed, 16 Apr 2014 22:41:59 -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 74BF11A002A for ; Wed, 16 Apr 2014 22:41:59 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so11682910yho.4 for ; Wed, 16 Apr 2014 22:41:55 -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=WCxIz+G9KbjG6ypPGPWfMC0JzYdkQ3Bd50BF5Ccw7QM=; b=H/oajUpI2KAcc6ISCG/eFyF7rBzm5Sbj/IO+MfuUOoh5srRedB4FpEg2sWXWzHJDuY oyFgceH7Dv1XkPw3sMvF27DLFFruzJXYccVH7TfL6y9pbVAfaT/SBR25Bn1jksRz7D1A 3M7YGZCzJbI5lfn5S7sIZk5DbnVEAiL9TouGfrHR9Y68wsBaiFCchJucbphjxPg8OQX/ z6wNpDvEyEqnw42aOIINwHHIJwFlRdktefeFhWXzBmggG9VoHNwXd8vVY1g6czek/crl 4vHsygyNaA7i80mwFYefqQNgP98A01Gy4olglaN7E9nY6rioGAPGq7OOlbEr3kA3W3nx iFIg== MIME-Version: 1.0 X-Received: by 10.236.85.45 with SMTP id t33mr18824853yhe.74.1397713315848; Wed, 16 Apr 2014 22:41:55 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 16 Apr 2014 22:41:55 -0700 (PDT) Date: Wed, 16 Apr 2014 22:41:55 -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/1yGMGfFbsCt4plQMfdClxvfyqhY Subject: [TLS] Dr-Ing. thesis on attacking SSL X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 05:42:04 -0000 Dear all, I would highly suggest reading the following. http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/MeyerChristopher/diss.pdf Some of these attacks are new, some are old. A patch has been released to Java for some of these issues, but other implementations should go through and check. Of particular interest is the advanced fingerprinting capability displayed, due to variant behavior between crypto stacks. In addition weakness in random number generation go beyond Dual_EC. Furthermore, the Million Message Attack continues to be useful. From my brief glance through it looks like this is about it. Sincerely, Watson Ladd From nobody Wed Apr 16 22:44: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 01FC91A03E8 for ; Wed, 16 Apr 2014 22:44:03 -0700 (PDT) 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 J8zXPpPByNyK for ; Wed, 16 Apr 2014 22:44:01 -0700 (PDT) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id 268B11A002A for ; Wed, 16 Apr 2014 22:44:00 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP for ; Thu, 17 Apr 2014 07:40:56 +0200 (CEST) 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 0F9C91DE66 for ; Thu, 17 Apr 2014 07:43:55 +0200 (CEST) Message-ID: <534F6A06.6090508@streamsec.se> Date: Thu, 17 Apr 2014 07:43:34 +0200 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: <20140417035011.GA25499@localhost> In-Reply-To: <20140417035011.GA25499@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vdJEGPdx_wFpykyPiQpyA4dtfhY Subject: Re: [TLS] Doing without renegotiation 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: Thu, 17 Apr 2014 05:44:03 -0000 On 2014-04-17 05:50, Nico Williams wrote: > My proposals: > > - For rekeying just introduce a CCS-like record whose purpose is to > indicate that the sender is changing to new keys on the send side. > The new keys are derived from the same master secret as the preceding > keys, in the same way, but with a counter appended to the "key > expansion" salt. > > There's no need to synchronize, but DTLS requires retransmission of > such messages else when dropped the recipient will not be able to > decrypt any subsequent messages. This might be an option if the purpose of the renegotiation is just to reduce the risk of state collisions in the bulk encryption cipher, but it is no replacement for renegotiation of DHE/ECDHE sessions in order to refresh the perfect forward secrecy. From nobody Thu Apr 17 00:11: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 DE6DF1A0075 for ; Thu, 17 Apr 2014 00:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 DBzxJS1QN3cB for ; Thu, 17 Apr 2014 00:11:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1111E1A00DD for ; Thu, 17 Apr 2014 00:11:38 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3H7BXbj005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Apr 2014 03:11:34 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3H7BVgm012593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 03:11:32 -0400 Message-ID: <1397718691.12647.37.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Patrick McManus Date: Thu, 17 Apr 2014 09:11:31 +0200 In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1t0_N3WuMMdBzx_oUFAImR7cTUA Cc: "" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 07:11:40 -0000 On Wed, 2014-04-16 at 21:48 -0400, Patrick McManus wrote: > I am very supportive of the TLS 1.3 charter because I earnestly > believe it is largely the latency issues associated with current TLS > standards that make it difficult for https to compete with http > performance. The result is more plaintext and that sucks for users. I > hope addressing that will be the focus of 1.3. There is some urgency > in addressing that bottleneck - and that urgency isn't especially > compatible with a ground up rework imo . > Someone upthread hit the nail on the head for me when they said that > what is being discussed isn't really a bake off of competing > solutions, but really a CFP of competing ideas. There seems to be > general agreement that incremental improvements and standardization of > existing technologies are the areas the IETF is able to execute well > in. The issue is that we don't have any solutions, no other examples of other IETF cryptographic protocols with smaller round-trip to copy from (there is PKINIT Kerberos but that comes with issues), and there have not been many ideas presented to reduce latency in TLS. Thus asking the working group to produce a _new_ cryptographic protocol in a short time frame, without any input from experts e.g., from academia, on the topic, is not a good design practice (see WEP). Note that IETF typically takes an existing protocol that solves a particular problem into action. In that case, judging from Eric's presentation on the topic, it seems that this working group is asked to invent a new one. regards, Nikos From nobody Thu Apr 17 00:15: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 4C85E1A00F2 for ; Thu, 17 Apr 2014 00:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.174 X-Spam-Level: X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 KpixkHv5JwpD for ; Thu, 17 Apr 2014 00:15:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D759E1A0075 for ; Thu, 17 Apr 2014 00:15:49 -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 s3H7Fi3d008613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Apr 2014 03:15:44 -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 s3H7FfkP032594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 03:15:43 -0400 Message-ID: <1397718941.12647.41.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Trevor Perrin Date: Thu, 17 Apr 2014 09:15:41 +0200 In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> 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/pt_oy2tz5aLRetHiv0wgTTCcMn0 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 07:15:52 -0000 On Wed, 2014-04-16 at 16:21 -0700, Trevor Perrin wrote: > > On reflection, I think I may favour this approach, yes: > > > > * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure > > baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint > > removed, bugs fixed and downgrade protection, and getting that out > > fairly promptly; > > > > and, > > > > * Following that with a TLSv2.0 process in which we look at the far > > more radical and challenging changes: handshake improvements, > > ClientHello/SNI encryption, perhaps a complete redesign. > > > Perhaps we could do both in parallel? - > > * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down > profile of TLS 1.2, without major handshake changes or new features, > aiming to finish in a few months. > > * Place a call for proposals for TLS 2.0, with the intent of choosing > one as a WG item within 4-6 months. I agree that they should be separated as activities since the more radical and challenging changes require a different approach. 4-6 months for proposals may be too short though. > I hear the concern that people don't want a "clean-slate" or > "revolutionary" redesign of TLS, they just want to quickly make the > "minimal" changes to 5246 that meet our charter. > > I'd encourage such people to re-read the charter, and look at Eric's > 1.3 draft. The goals and designs being considered are *already* a > radical break from your parent's TLS. We'll have complex, difficult > debates involving competing visions for TLS regardless of what process > we choose. Indeed, I believe that the most voices heard for a fast-to-be-issued TLS 1.3 that includes all the points in the charter either underestimate the issues involved, or are unaware of them. regards, Nikos From nobody Thu Apr 17 00:48: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 AB2E81A004D for ; Thu, 17 Apr 2014 00:48:06 -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 IWZ4jjK-fS-o for ; Thu, 17 Apr 2014 00:48:02 -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 237501A0011 for ; Thu, 17 Apr 2014 00:48:01 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so416599wib.4 for ; Thu, 17 Apr 2014 00:47:58 -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=ItZTcAKsvQ1w+KFyfwtVo14HFd278mdz92YNCmnJTb4=; b=rPYDtO++RvW38EMfE+RmLXM3p/z6wJlmZfzrYl+8hAWRHa0k4M3X5sNFenft/+wEsr KBuq0IfC4A/QmOgOmTVDKRY6auhI2hyXVgNPq1uQpDC4/Sau11zhqmaTps9a+2LmO8W4 IfyNMVX2baECLFQK17wa6BELLObIvm5+UXOWbOEoLHLCKuWnXksU0W5urR0pRy3WX9OK 1zNxKUGDOktOOlxw/l/gciWkIVwDnLW2A/PDiMiE6e+HBGZahcVW2Xy/b8aWc4fgl+sP ozzLBOPgO0JtkHB9K8cN8C0IoO4uyH3rFclzV06/ZRfHLrE4VtTLQxSzkal9BSpviIeF ifKQ== X-Received: by 10.180.76.146 with SMTP id k18mr13722674wiw.5.1397720878115; Thu, 17 Apr 2014 00:47:58 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gc2sm3281638wic.3.2014.04.17.00.47.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 00:47:57 -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: <20140417035011.GA25499@localhost> Date: Thu, 17 Apr 2014 10:47:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2763DE41-00D1-4C86-8982-A11B3A77D40C@gmail.com> References: <20140417035011.GA25499@localhost> To: Nico Williams X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z46MZNHs0gZ4Rl8c0YHlym6m7ak Cc: tls@ietf.org Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 07:48:06 -0000 On Apr 17, 2014, at 6:50 AM, Nico Williams = wrote: >=20 > - authenticate the client when needed rather than always at handshake = time > - For authentication other than that provided by the initial handshake > I propose application-specific solutions. > - server wants client to authenticate >=20 > In a protocol like HTTP that'd be a 401 indicating what methods > the client can choose from... Standard stuff. We'd add a public > key / PKI method whereby the client sends a signature of the TLS > channel binding, along with any cert chain, OCSP responses, =85 Do you mean something like Martin=92s proposal ([1][2]) or doing the = whole thing in HTTP as a new HTTP authentication method? Yoav [1] http://tools.ietf.org/html/draft-thomson-httpbis-catch-00 [2] http://tools.ietf.org/html/draft-thomson-tls-care-00 From nobody Thu Apr 17 01:13: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 3D43D1A00FD for ; Thu, 17 Apr 2014 01:13: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, 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 5VmG-pp-kwNk for ; Thu, 17 Apr 2014 01:13:48 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 72D641A00F9 for ; Thu, 17 Apr 2014 01:13:48 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 17 Apr 2014 09:13:33 +0100 To: tls@ietf.org Message-ID: <9c61cc29-1f0d-4bd9-970c-3ee811004ee7@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tpMGc9SJLloHVZ2PQcPG3ZucXTc Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 08:13:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I don't have much time today, but really briefly, to cover this point: On 17 April 2014 00:33:52 BST, "Joseph Salowey (jsalowey)" wrote: >> [akr] • DH_anon? >> - Subject to thoughts about possible opportunistic encryption, >> although this definitely isn't the way you _want_ to do that. >> > [Joe] Why not? Here's (very briefly) why not: • Alice: "I'm fine with RSA, ECDSA or DH_anon…" • Mallory: . o O ( A-ha! Alice is probably being opportunistic and won't catch me! ) • "Bob" (Mallory): "What a coincidence, I'm fine with DH_anon too! :D" • /mitm'd. :( - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTT40tGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6j8wQAJqOm4H4Yt6BizKWEU8slkRaEAuD9r0fmlJr8y5wSASHu+TIfk8Y c6BECOBUx8Sk4gUjvZr0wMUJyeJ/F06EmzII9BxwUMrJ4FZBu1R3Dx+Nkiolwr6R fdQK7zDBgRtJhbJs5NFJ8nQEawQeMeMhMb5npOCxQffkS41Vt/watUyfZUYPkui9 Ve/4OFAxKQx08GgMg61XZ0DzYW2IHGNI/5wgVJdkMUILt9Ep/mztYToNoh11uo8k XaN2JhTIOY22KsuftqxgDmEeA6gR4rD0ZadcayK2ujWWZgBSEjGGyXnS/Nz3zHc+ WnJfmTuQX79IVy6vyJnT5wAdK1giAAwB35eIOjfohNR2jNePbefzA2WMQiPBLnVT 3Ix314IBgg5b8wGj5nwN1ZuIL214YnrJkufAWhWhQ9+QJPGOE2UH8OdORp2H9nkc A681ZgOF7NsFVIldWaurkvi5nx3AiSQ+2e3OuXKH37xx1ZYn2Qm7dF+WXCWCKLVL UEJimdHxl/kO2EYkMaqpFsO2JsatZpPTXCCvDGtFvDC4p4xrjdKJKyG1n1uMo5kb PGv8uw/SMoBAm/Vb5J5seqvib9ls0IjdMhajhTpxa/qJFnXxsl1nO/BgiGaooU/l R/GflgA3pxsjlg0QDKWzJrDihmtpAimwoaCBVIQNut5zLgweh/4M1eVJ =j4Gg -----END PGP SIGNATURE----- From nobody Thu Apr 17 01:27: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 407A11A0299 for ; Thu, 17 Apr 2014 01:27: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 03MWkCZ8Ixoq for ; Thu, 17 Apr 2014 01:27:28 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 21C521A01FA for ; Thu, 17 Apr 2014 01:27:27 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so127662wes.17 for ; Thu, 17 Apr 2014 01:27:24 -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=o1SUlN7y2mF2mLZYETEUI8Uu+Vitw3ChkmrGSCX280Q=; b=yQsDY/TeBe8F3kR1x5GDmMukNrwf2Ay3Ckz89esK12NYZNuHsZ3S+0MUWK5S4Uri9n z+Zx5Q7b6o9YM/Zy5CDB/fMHLqMsetoCCkKa+WjatnfvW6g/iX1gd2xCeWLV2c2Lcsd1 bQrKmexboLwVBQHjoA9s5FKkqJCMi/+CnGv6mppaMCoKLqPo5PElhjnAtGv+zdJIgC+0 JVRSNdmneiOytL4SX+LSRook1HA0/XAfjRPy/tL+OsL/0EoNJl8mfjSMiifUeJ5jzmqu BMqh2sXpWydcFJVoGw20G40bqeAVkBDgesGdXq9rTREGJL/UA+u8wKjfJbuRiL0ujq8b L37g== X-Received: by 10.180.91.114 with SMTP id cd18mr11224663wib.28.1397723244220; Thu, 17 Apr 2014 01:27:24 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ez5sm38000520wjd.9.2014.04.17.01.27.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 01:27:23 -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: <534F0A33.9070408@akr.io> Date: Thu, 17 Apr 2014 11:27:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <534F0A33.9070408@akr.io> To: Alyssa Rowan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O6EsjmkoqbnrLyhTsy4bDBDxcaY Cc: tls@ietf.org Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 08:27:33 -0000 On Apr 17, 2014, at 1:54 AM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 16/04/2014 21:34, Jacob Appelbaum wrote: >=20 >> [=85] and that often results in say, a forged TCP RST packet. >=20 > Which, incidentally, we should consider something to address, > especially if we do indeed have a bakeoff of some form for a fancier > TLSv2.0. >=20 > NSA calls this technique QUANTUMSKY (one of their less catchy cover > names) but it's been around for aeons (most famously in the Chinese > 'Golden Shield'): any man-on-the-side can simply RST your TCP > connections if they don't like the way they smell, and this is (by > far) the cheapest and easiest way for a nation state adversary (or > malicious coffee shop WiFi) to selectively disrupt, or censor, > communications. >=20 > Could we plug that hole in a future version of TLS? We=92re at the wrong layer to fix an attack against TCP. The right = place to protect TCP is either in TCP itself, or by using IPsec. > The obvious way involves UDP, and baking transport control (and > multiplexing?) inside that layer, within the encryption. In fact it's > so obvious, everyone likes to cook up their own recipe: lots of people > have done something in that general area already in different ways, > and discovered interesting things about it (Google's QUIC being one > notable recent foray into the field). Those who won=92t use TCP are doomed to re-create it. To get a UDP-based = protocol to replace TCP for the web you=92d need all of reliable = delivery through (selective?) retransmissions, bandwidth detection, = replay protection, a whole lot of things that took the transport = community years to get right. Yes, there have been many attempts, but = there=92s a reason TCP is still the protocol everyone uses for pretty = much any type of bulk transfer. And this is before we even begin to talk = about middleboxes dropping unrecognized UDP services. > UDP is also notably better for > connections through NAT and suchlike. (I've even done my own > experiments in that general direction, although delicious and moist as > they seem to be, they're simply experiments and I'm not yet ready to > serve them to guests, let alone strangers!) UDP is connectionless. As such, NAT devices don=92t know when it=92s = done. So NAT mappings need to linger a lot longer after the last packet. = TCP works better with NAT. > It also results in something that probably looks more like DTLS than > anything we have now, or something even stranger, or like nothing > anyone can recognise. >=20 > It may, or very well may not, be a good idea (gleefully gratuitously > rampant layering violation/wheel reinvention vs. avoiding unnecessary > insecure layers vulnerable to a real, deployed attack/square wheel), > but I'd be interested (with no particular hurry) if anyone had had any > thoughts in that direction. It would require an explanation about why this new wheel would be better = than TCP in IPsec. Yoav From nobody Thu Apr 17 05:19: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 718AD1A0126 for ; Thu, 17 Apr 2014 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 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_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 lx636OHX1dzb for ; Thu, 17 Apr 2014 05:19:23 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECB91A0118 for ; Thu, 17 Apr 2014 05:19:23 -0700 (PDT) MIME-version: 1.0 Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4600400CPC6900@local.mail-out.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 05:19:19 -0700 (PDT) Received: from relay6.apple.com ([17.128.113.90]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4600155CVPZ950@local.mail-out.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 05:19:19 -0700 (PDT) X-AuditID: 1180715a-f79cb6d00000168c-cc-534fc6c7e69e Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 44.33.05772.7C6CF435; Thu, 17 Apr 2014 05:19:19 -0700 (PDT) Received: from [17.153.54.238] (unknown [17.153.54.238]) by cilantro.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N460095DCW57U20@cilantro.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 05:19:19 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_37B34340-1FDE-42EE-B7CB-EBEE2AB0794C"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Thu, 17 Apr 2014 08:19:17 -0400 Message-id: <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> To: Martin Thomson X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FAspHv8mH+wwZcDMhafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/qZHuaCU/YVPc+vsTcwbrPpYuTkkBAwkfiyYCsThC0mceHe erYuRi4OIYGJTBK/D+1mB0kICcxjkpjzHqxBWEBa4uaETcwgNq+AnsSZs7/YQRqYBaYwSkz8 u5oFJMEmoCbxe1IfK4jNKRAssfrBXUYQm0VAVeLE+kdgNcwCThLLLh5lhRhkI/Ho5VRGiM27 mSU+zHsNViQioCux6OwDdojzZCUefWhimcDIPwvJ8lnIls8CG6wtsWzha+ZZjBxAto7E5IWM EGFTiSdvt7NB2NYSP+c8goorSkzpfsi+gJF9FaNAUWpOYqWZXmJBQU6qXnJ+7iZGcBAXRu1g bFhudYhRgINRiYeX47dfsBBrYllxZe4hRhWgEY82rL7AKMWSl5+XqiTC27zeP1iINyWxsiq1 KD++qDQntfgQozQHi5I4rx4zUEogPbEkNTs1tSC1CCbLxMEp1cDocMDsv4K71KSbFSKxFR1u nNdNrUP2Wc50m7wheuLGnmfZf6fOYt+XVmV89Yi793+O/kD+LTLr9mnFBOyZI5zWvXZlZuPh sy9yLb0f2R1do7lRiIFh3cusp3xVjazTnbfxSr6NnJ7g+dwpScNE1vdxfWxk2O8357MnlUvO 2Jj772Kxl/gSHkMlluKMREMt5qLiRAAUjzTQagIAAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=apple.com; s=mailout2048s-14-01; t=1397737159; bh=Z9HCN35oxfOgPrEHi9FYXZcX1ayGcCibICow4zKHxo0=; h=Subject:From:In-reply-to:Date:Cc:References:To; b=SIklIb+OoWjD8FXdhg6hiSnQkc0qFRETxRnCkhP1oqiDIbH3Kx7v9a28BYWjNGgBD x3eDUbo++RAW4w9wWiCzHKi6Gq+njWwIyorBFesJ+t9SAZLMw0rijbtOkTNDOFeBu+ oYp0QWlfIiRGG6d+s0ifM/rW4xUaFv7k2/CDMtrsnb67Y1kGFcBABLDbNJesh9hbFa gSZ6wWbRduGLMqYhWIzGYporxMpnDu/zwSFqm9FRP6WwDUu9v3QOX+t6QTmgIqavR4 LMlVJLXl3xMm/Cv4qRu0l73hNU8RJ07rk6sPPtatkDIJdG0dGouD583UZypX6meUha A5YlrbQyw9jdQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/azF6EhYDEsHu54iGI2Exthr29ig Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 12:19:27 -0000 --Apple-Mail=_37B34340-1FDE-42EE-B7CB-EBEE2AB0794C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FWIW, 1-RTT latency is mainly an issue when you have a browser making a = dozen connections to a secure site. With HTTP/2 that particular problem = goes away... On Apr 16, 2014, at 7:45 PM, Martin Thomson = wrote: > On 16 April 2014 16:21, Trevor Perrin wrote: >> * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down >> profile of TLS 1.2, without major handshake changes or new features, >> aiming to finish in a few months. >=20 > I want a pony too, but since the latency improvements are the main > reason we have people interested in TLS 1.3, I'm pretty sure that a > plan like this won't have the desired effect. It might reduce the > volume of mail I get from this list, which is one advantage I suppose. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_37B34340-1FDE-42EE-B7CB-EBEE2AB0794C 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 9w0BCQUxDxcNMTQwNDE3MTIxOTE4WjAjBgkqhkiG9w0BCQQxFgQUCNMtnCUi541axw/QwgN4zJJf DoUwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQCwCLD9ztMK4GRKSpTFkqYoN5AIu/x7koD7wigYklzxwCLlxbefef6HigAswHvWk5ilfDV2Mjiu kpuy2/iBNxEQ/S4M4U35pkaVtTcnMkKaM0eQ/SyjxT72YZWTzECYMb0d6Q9fwYIQMYddWhZ6Kjbo vBeHiY5Upd7693XUBaQl4FfZENK74BtmYe3ofNdOuFDSJTRLwqrp4kZrkUacl1Ym9BQvvziQ+JLI FP2K8cJUjYkQUJKj+M2zSOyuu1mqPRPePAwBQ7yDdeSoccQek0YZD/UjUj8iWB7FH06AVLN5rFyg xVLD9noxuM9YIt3+9sPqPlajuJnLS2LgN4hiTHPJAAAAAAAA --Apple-Mail=_37B34340-1FDE-42EE-B7CB-EBEE2AB0794C-- From nobody Thu Apr 17 06:17: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 218541A015B for ; Thu, 17 Apr 2014 06:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FIEv0n4kraC for ; Thu, 17 Apr 2014 06:16:59 -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 601D61A014D for ; Thu, 17 Apr 2014 06:16:59 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BA01F48153; Thu, 17 Apr 2014 13:16:55 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id AEEE248148; Thu, 17 Apr 2014 13:16:55 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 975CC1E043; Thu, 17 Apr 2014 13:16:55 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 17 Apr 2014 09:16:54 -0400 From: "Sniffen, Brian" To: Andy Lutomirski Date: Thu, 17 Apr 2014 09:16:53 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9aP02MVywvSNijSny1UKNsUnRIMw== Message-ID: <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a1tm5Y1V1iWbeXr01Ma9u4RC0JQ Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:17:04 -0000 On Apr 16, 2014, at 10:08 PM, "Andy Lutomirski" wrote= : >=20 > You still only need four. Remember that my ClientHello key is > completely independent of the key associated with the server > certificate, and that it can be stripped. Do I understand that you intend one for normal operation, one more during r= otations---and then for my example that different people want different cry= pto, another operation/rotation pair? I can imagine that working well in 2015. I think in 2020 we'll surely find= it too tight and chafing. Maybe that is enough. -Brian= From nobody Thu Apr 17 06: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 B11B61A016D for ; Thu, 17 Apr 2014 06:41:12 -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 hh9rMyzsPnYA for ; Thu, 17 Apr 2014 06:41:11 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF81A015A for ; Thu, 17 Apr 2014 06:41:11 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q107so422190qgd.11 for ; Thu, 17 Apr 2014 06:41:07 -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=a/kFzcjgfNN9YfgVwdT0o2ZFqqnZZY4nKlu7xx4bA2s=; b=LGsQ6rgG9abHvsALdQ93bjRu63PcKFeq5DxP+eqdtyHg8yiW2o/DDoHDiARc1/tUVc oVWYVPlPx8DgV6m/2B2u+GyirrwwJkBXueALdliLNglxnkwt3hneY+WQZoL07Q29KEg2 mK4bDWvfArIpQ5YNBod/QwC4Flr+WqrvzWmVYqf2+xY5il8zDh13vIIA8XGhHZ+vyYnY FdPVybK2W124BZ4XRERsyDfoppDNsLI4MzToB3pz8N2zWA7LPu6mxmoLpwfMb3NNdiQk cnH0Y4flf+t9TZ4hLLPmSnTxs+7QosEFf+YC6rUjkkOX4i5eS3MiRvtiYRQvjI56XL/Y bBWA== MIME-Version: 1.0 X-Received: by 10.229.17.69 with SMTP id r5mr11678583qca.7.1397742067556; Thu, 17 Apr 2014 06:41:07 -0700 (PDT) Sender: patrick.ducksong@gmail.com Received: by 10.140.93.180 with HTTP; Thu, 17 Apr 2014 06:41:07 -0700 (PDT) In-Reply-To: <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> Date: Thu, 17 Apr 2014 09:41:07 -0400 X-Google-Sender-Auth: zlruobiJQbqCXO8iYCYKqkBb0X8 Message-ID: From: Patrick McManus To: Michael Sweet Content-Type: multipart/alternative; boundary=001a1133c9386ca87f04f73d2fa7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CUK18QOgLiH0KDXjXNF5t-Luslc Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 13:41:12 -0000 --001a1133c9386ca87f04f73d2fa7 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 8:19 AM, Michael Sweet wrote: >> FWIW, 1-RTT latency is mainly an issue when you have a browser making a dozen connections to a secure site. With HTTP/2 that particular problem goes away... As a browser guy I'll say I really disagree with that. HTTP/2 is important stuff, and helps hide part of the problem, but the latency issue continues to be an issue for HTTP over TLS use cases. Time to first byte of course, but also to each different referenced origin (the cdn, the third-party ad network, the identity provider, etc..). Often things that block layout are on that cdn (e.g. stylesheets, some javascript) so the time to perform 2 http transactions on 2 serialized tls terminated connections is often the same as time to first screen draw. Its considerably worse in mobile environments where RTT can be out of control. Establishing TLS is noticeably slow, and that's a problem for the browser use case where https often competes against http for developer mind share. As a natural result, some content providers choose to run plaintext http which we can all agree is an undesirable outcome. Shrinking that gap will help. _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > --001a1133c9386ca87f04f73d2fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 17, 2014 at 8:19 AM, Michael Sweet <m= sweet@apple.com> wrote:
>> FWIW, 1-RTT latency is mainly an issue when you have a browser making a dozen connections to a secure site. =C2=A0With HTTP/2 that particular problem go= es away...

As a browser guy I'll say I really disagree with that.

HTTP/2 is= important stuff, and helps hide part of the problem, but the latency issue= continues to be an issue for HTTP over TLS use cases. Time to first byte o= f course, but also to each different referenced origin (the cdn, the third-= party ad network, the identity provider, etc..). Often things that block la= yout are on that cdn (e.g. stylesheets, some javascript) so the time to per= form 2 http transactions on 2 serialized tls terminated connections is ofte= n the same as time to first screen draw. Its considerably worse in mobile e= nvironments where RTT can be out of control.

Establishing TLS is noticeably slow, and that's a problem for the b= rowser use case where https often competes against http for developer mind = share. As a natural result, some content providers choose to run plaintext = http which we can all agree is an undesirable outcome. Shrinking that gap w= ill help.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--001a1133c9386ca87f04f73d2fa7-- From nobody Thu Apr 17 07:11: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 9F0CA1A0322 for ; Thu, 17 Apr 2014 05:58:57 -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 Gq3eVmH8XopG for ; Thu, 17 Apr 2014 05:58:53 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06F1A02BE for ; Thu, 17 Apr 2014 05:58:53 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so457228veb.9 for ; Thu, 17 Apr 2014 05:58:50 -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=4VoLJFesh+MdNK+51koVDhK0W5QYtYy/ItQ4GoSn9w8=; b=ozXn1RpsEbxNNwX1avNcewTq6WMv9cRZN7cfpGRGYvirqMVaqUUTIkY14ajhgdrnED 4e+mPnq5B6v9EbdB6BiPyoBWA1z7vQpXEFLZy0c9Q6gQfh4vX00IfhR2ArahoEtQVeOx +fQI3qc8cU7gKNjZg7da2RNwjRQCMa4h9gmc3I0EXdbG2xPoSVlYaVYfbFaF31jSJABZ BUnMFhrqar1EPwjGIvYgwgLvQEnbkUVb6lmieBGBsQ9PO2MjHYGk+HIaMQcWQX51zvOj hZQExG/K3+7e7PhxxRo6icrusiY6qdbgPw99apa7XJ/bMiwjT8jxj4kn7j/XEg4iWWSZ uOsw== MIME-Version: 1.0 X-Received: by 10.220.92.135 with SMTP id r7mr8543055vcm.11.1397739529871; Thu, 17 Apr 2014 05:58:49 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Thu, 17 Apr 2014 05:58:49 -0700 (PDT) Received: by 10.221.18.70 with HTTP; Thu, 17 Apr 2014 05:58:49 -0700 (PDT) In-Reply-To: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <534F0A33.9070408@akr.io> <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> Date: Thu, 17 Apr 2014 08:58:49 -0400 X-Google-Sender-Auth: IUL9gv6cY0VxqIKxrUwn4638hy4 Message-ID: From: Erik Nygren To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b66f5fb2aa66a04f73c9851 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ncg_-YxL2v0DBajpVlPt8YQr7ME X-Mailman-Approved-At: Thu, 17 Apr 2014 07:11:22 -0700 Cc: tls@ietf.org Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:58:57 -0000 --047d7b66f5fb2aa66a04f73c9851 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some of this ties directly into the tcpcrypt discussions. It may be worth having a discussion somewhere in the IETF on which protections belong in which layers and how we make sure they can compose safely. It may be that protecting the handshake from passive attacks also belongs in the tcp layer. See my previous post on this topic: http://www.ietf.org/mail-archive/web/tls/current/msg11693.html Erik On Apr 17, 2014 4:27 AM, "Yoav Nir" wrote: > > On Apr 17, 2014, at 1:54 AM, Alyssa Rowan wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 16/04/2014 21:34, Jacob Appelbaum wrote: > > > >> [=E2=80=A6] and that often results in say, a forged TCP RST packet. > > > > Which, incidentally, we should consider something to address, > > especially if we do indeed have a bakeoff of some form for a fancier > > TLSv2.0. > > > > NSA calls this technique QUANTUMSKY (one of their less catchy cover > > names) but it's been around for aeons (most famously in the Chinese > > 'Golden Shield'): any man-on-the-side can simply RST your TCP > > connections if they don't like the way they smell, and this is (by > > far) the cheapest and easiest way for a nation state adversary (or > > malicious coffee shop WiFi) to selectively disrupt, or censor, > > communications. > > > > Could we plug that hole in a future version of TLS? > > We=E2=80=99re at the wrong layer to fix an attack against TCP. The right= place to > protect TCP is either in TCP itself, or by using IPsec. > > > The obvious way involves UDP, and baking transport control (and > > multiplexing?) inside that layer, within the encryption. In fact it's > > so obvious, everyone likes to cook up their own recipe: lots of people > > have done something in that general area already in different ways, > > and discovered interesting things about it (Google's QUIC being one > > notable recent foray into the field). > > Those who won=E2=80=99t use TCP are doomed to re-create it. To get a UDP-= based > protocol to replace TCP for the web you=E2=80=99d need all of reliable de= livery > through (selective?) retransmissions, bandwidth detection, replay > protection, a whole lot of things that took the transport community years > to get right. Yes, there have been many attempts, but there=E2=80=99s a r= eason TCP > is still the protocol everyone uses for pretty much any type of bulk > transfer. And this is before we even begin to talk about middleboxes > dropping unrecognized UDP services. > > > UDP is also notably better for > > connections through NAT and suchlike. (I've even done my own > > experiments in that general direction, although delicious and moist as > > they seem to be, they're simply experiments and I'm not yet ready to > > serve them to guests, let alone strangers!) > > UDP is connectionless. As such, NAT devices don=E2=80=99t know when it=E2= =80=99s done. So > NAT mappings need to linger a lot longer after the last packet. TCP works > better with NAT. > > > It also results in something that probably looks more like DTLS than > > anything we have now, or something even stranger, or like nothing > > anyone can recognise. > > > > It may, or very well may not, be a good idea (gleefully gratuitously > > rampant layering violation/wheel reinvention vs. avoiding unnecessary > > insecure layers vulnerable to a real, deployed attack/square wheel), > > but I'd be interested (with no particular hurry) if anyone had had any > > thoughts in that direction. > > It would require an explanation about why this new wheel would be better > than TCP in IPsec. > > Yoav > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b66f5fb2aa66a04f73c9851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Some of this ties directly into the tcpcrypt discussions.=C2= =A0 It may be worth having a discussion somewhere in the IETF on which prot= ections belong in which layers and how we make sure they can compose safely= .=C2=A0 It may be that protecting the handshake from passive attacks also b= elongs in the tcp layer.=C2=A0 See my previous post on this topic:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.iet= f.org/mail-archive/web/tls/current/msg11693.html

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

On Apr 17, 2014 4:27 AM, "Yoav Nir" &l= t;ynir.ietf@gmail.com> wrote:=

On Apr 17, 2014, at 1:54 AM, Alyssa Rowan <akr@akr.io> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 16/04/2014 21:34, Jacob Appelbaum wrote:
>
>> [=E2=80=A6] and that often results in say, a forged TCP RST packet= .
>
> Which, incidentally, we should consider something to address,
> especially if we do indeed have a bakeoff of some form for a fancier > TLSv2.0.
>
> NSA calls this technique QUANTUMSKY (one of their less catchy cover > names) but it's been around for aeons (most famously in the Chines= e
> 'Golden Shield'): any man-on-the-side can simply RST your TCP<= br> > connections if they don't like the way they smell, and this is (by=
> far) the cheapest and easiest way for a nation state adversary (or
> malicious coffee shop WiFi) to selectively disrupt, or censor,
> communications.
>
> Could we plug that hole in a future version of TLS?

We=E2=80=99re at the wrong layer to fix an attack against TCP. =C2=A0The ri= ght place to protect TCP is either in TCP itself, or by using IPsec.

> The obvious way involves UDP, and baking transport control (and
> multiplexing?) inside that layer, within the encryption. In fact it= 9;s
> so obvious, everyone likes to cook up their own recipe: lots of people=
> have done something in that general area already in different ways, > and discovered interesting things about it (Google's QUIC being on= e
> notable recent foray into the field).

Those who won=E2=80=99t use TCP are doomed to re-create it. To get a UDP-ba= sed protocol to replace TCP for the web you=E2=80=99d need all of reliable = delivery through (selective?) retransmissions, bandwidth detection, replay = protection, a whole lot of things that took the transport community years t= o get right. Yes, there have been many attempts, but there=E2=80=99s a reas= on TCP is still the protocol everyone uses for pretty much any type of bulk= transfer. And this is before we even begin to talk about middleboxes dropp= ing unrecognized UDP services.

> UDP is also notably better for
> connections through NAT and suchlike. (I've even done my own
> experiments in that general direction, although delicious and moist as=
> they seem to be, they're simply experiments and I'm not yet re= ady to
> serve them to guests, let alone strangers!)

UDP is connectionless. As such, NAT devices don=E2=80=99t know when it=E2= =80=99s done. So NAT mappings need to linger a lot longer after the last pa= cket. TCP works better with NAT.

> It also results in something that probably looks more like DTLS than > anything we have now, or something even stranger, or like nothing
> anyone can recognise.
>
> It may, or very well may not, be a good idea (gleefully gratuitously > rampant layering violation/wheel reinvention vs. avoiding unnecessary<= br> > insecure layers vulnerable to a real, deployed attack/square wheel), > but I'd be interested (with no particular hurry) if anyone had had= any
> thoughts in that direction.

It would require an explanation about why this new wheel would be better th= an TCP in IPsec.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--047d7b66f5fb2aa66a04f73c9851-- From nobody Thu Apr 17 07:18: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 80C831A007D for ; Thu, 17 Apr 2014 07:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHsWrPV1sd2O for ; Thu, 17 Apr 2014 07:17:54 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE41A0063 for ; Thu, 17 Apr 2014 07:17:54 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B89B81E118; Thu, 17 Apr 2014 14:17:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1397744269; bh=OW1wvdAhP46bLrlbBaEpYSP0CI3aA3oiXKiyzi+qLqQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SP7t2s6CuHAD90OA039j8DZrBqPsEoUtoemAZmS8/rTMs7OTz7pEInWlaxs4DrJhQ +6Wy7jRL+7T49rFS3hhXQ+AXXKbyjpI4ggpNYImvx0UuR7OQNZtH11555YedgiM2nr WdhxYIHqx1OeslADP/IOV/8Qt7GxS0ownM2LTBpM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 78AF76001D; Thu, 17 Apr 2014 14:13:51 +0000 (UTC) From: James Cloos To: In-Reply-To: (Andy Lutomirski's message of "Wed, 16 Apr 2014 19:38:14 -0700") References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 17 Apr 2014 10:13:51 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140417:tls@ietf.org::2dSpaloTmqLab5zz:0000TA5d1 X-Hashcash: 1:30:140417:luto@amacapital.net::r7nw0UaUz76FYxOE:000000000000000000000000000000000000000005I+mK X-Hashcash: 1:30:140417:paul@marvell.com::PnMYYgt6+OtzC+UU:lF+7q Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Aaq_ZThfwXuvyejQhptT-Ut4pa4 Cc: Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:17:58 -0000 >>>>> "AL" == Andy Lutomirski writes: AL> Let's focus on the handshake encryption part, Good point. Equal(-ish :) strength seems like a good plan, though. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nobody Thu Apr 17 07:30: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 23C201A0130 for ; Thu, 17 Apr 2014 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFs6k-kKwPjT for ; Thu, 17 Apr 2014 07:30:51 -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 12A0E1A0120 for ; Thu, 17 Apr 2014 07:30:51 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 52DD0285A4; Thu, 17 Apr 2014 14:30:47 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4129A28544; Thu, 17 Apr 2014 14:30:47 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 0956680047; Thu, 17 Apr 2014 14:30:47 +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, 17 Apr 2014 10:30:46 -0400 From: "Salz, Rich" To: Trevor Perrin , Patrick McManus Date: Thu, 17 Apr 2014 10:30:46 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9Z9u+1F62AmppTTmW0GtA6FS11sAAUn8SQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A1C@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eZRJpg6kkzCe5z7nRIJWqIdAsHI Cc: "" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 14:30:52 -0000 > Unfortunately, charter goals like (encrypted handshake, 0-RTT reconnect, = privacy-friendly) do require a major rework of the TLS handshake. See Eric= 's proposal for one example [1]. And if it turns out that it's more work than we want to do, and that certai= n goals are not meant, that's okay. " When the facts change, I change my m= ind. What do you do, sir?" -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Apr 17 07:32: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 B76E41A0130 for ; Thu, 17 Apr 2014 07:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POpCPbA8kYBd for ; Thu, 17 Apr 2014 07:32:27 -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 5CFF91A0120 for ; Thu, 17 Apr 2014 07:32:27 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A1165165560; Thu, 17 Apr 2014 14:32:23 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 95E99165531; Thu, 17 Apr 2014 14:32:23 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 7E2901E05C; Thu, 17 Apr 2014 14:32:23 +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, 17 Apr 2014 10:32:22 -0400 From: "Salz, Rich" To: "Salz, Rich" , Trevor Perrin , Patrick McManus Date: Thu, 17 Apr 2014 10:32:21 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9Z9u+1F62AmppTTmW0GtA6FS11sAAUn8SQAAAQxyA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A24@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A1C@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A1C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cE4BmOhbod5wlhYbUdtKw0YDsgs Cc: "" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 14:32:28 -0000 I want to clarify that I wasn't personally addressing Trevor with the quote= . I was saying that we had an original goal, and as we went along it seems mo= re complicated than we want to do, that's okay. -- =20 Principal Security Engineer Akamai Technology Cambridge, MA -----Original Message----- From: Salz, Rich [mailto:rsalz@akamai.com]=20 Sent: Thursday, April 17, 2014 10:31 AM To: Trevor Perrin; Patrick McManus Cc: Subject: Re: [TLS] Bakeoffs > Unfortunately, charter goals like (encrypted handshake, 0-RTT reconnect, = privacy-friendly) do require a major rework of the TLS handshake. See Eric= 's proposal for one example [1]. And if it turns out that it's more work than we want to do, and that certai= n goals are not meant, that's okay. " When the facts change, I change my m= ind. What do you do, sir?" -- =20 Principal Security Engineer Akamai Technology Cambridge, MA _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 17 07:36: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 E7D131A011E for ; Thu, 17 Apr 2014 07:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ywXnCmzno8K for ; Thu, 17 Apr 2014 07:36:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BE9881A016E for ; Thu, 17 Apr 2014 07:36:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BDF5BEB1; Thu, 17 Apr 2014 15:36:22 +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 c5xDDvRJClfT; Thu, 17 Apr 2014 15:36:21 +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 D0186BEB0; Thu, 17 Apr 2014 15:36:21 +0100 (IST) Message-ID: <534FE6E5.4000509@cs.tcd.ie> Date: Thu, 17 Apr 2014 15:36:21 +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: Erik Nygren , Yoav Nir References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <534F0A33.9070408@akr.io> <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> 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/vHZsT5JqXPV0mPEUIlejZYlU_k4 Cc: tls@ietf.org Subject: Re: [TLS] Forged RST X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 14:36:39 -0000 Hiya, On 04/17/2014 01:58 PM, Erik Nygren wrote: > Some of this ties directly into the tcpcrypt discussions. Yes, noting though that the TCP encryption/tcpcrypt work is at a far earlier stage than TLS. (Its good stuff though, or will be, I hope.) > It may be worth > having a discussion somewhere in the IETF on which protections belong in I'd quibble with "belong" there. I think to some extent our (the IETF, not the TLS WG) job is to define protocols that get implemented so that whoever is deploying can turn on the security they want. Its a big old Internet out there after all, and I'm not sure our best guess at which-layer-does-what-best is likely to be right for all time for all places. > which layers and how we make sure they can compose safely. That part I definitely do agree with. And with having a more general discussion, which I'd hope will feed into our nascent plans to add to BCP 72 in a while. This is not the right list for that discussion of course, but if you (or someone) wanted to write a draft and get a discussion going on saag that would be good. (I suspect that might be more useful when the TLS and tcpcrypt discussions are a little further along though, maybe in/after the summer.) Cheers, S. > It may be that > protecting the handshake from passive attacks also belongs in the tcp > layer. See my previous post on this topic: > http://www.ietf.org/mail-archive/web/tls/current/msg11693.html > > Erik > On Apr 17, 2014 4:27 AM, "Yoav Nir" wrote: > >> >> On Apr 17, 2014, at 1:54 AM, Alyssa Rowan wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 16/04/2014 21:34, Jacob Appelbaum wrote: >>> >>>> […] and that often results in say, a forged TCP RST packet. >>> >>> Which, incidentally, we should consider something to address, >>> especially if we do indeed have a bakeoff of some form for a fancier >>> TLSv2.0. >>> >>> NSA calls this technique QUANTUMSKY (one of their less catchy cover >>> names) but it's been around for aeons (most famously in the Chinese >>> 'Golden Shield'): any man-on-the-side can simply RST your TCP >>> connections if they don't like the way they smell, and this is (by >>> far) the cheapest and easiest way for a nation state adversary (or >>> malicious coffee shop WiFi) to selectively disrupt, or censor, >>> communications. >>> >>> Could we plug that hole in a future version of TLS? >> >> We’re at the wrong layer to fix an attack against TCP. The right place to >> protect TCP is either in TCP itself, or by using IPsec. >> >>> The obvious way involves UDP, and baking transport control (and >>> multiplexing?) inside that layer, within the encryption. In fact it's >>> so obvious, everyone likes to cook up their own recipe: lots of people >>> have done something in that general area already in different ways, >>> and discovered interesting things about it (Google's QUIC being one >>> notable recent foray into the field). >> >> Those who won’t use TCP are doomed to re-create it. To get a UDP-based >> protocol to replace TCP for the web you’d need all of reliable delivery >> through (selective?) retransmissions, bandwidth detection, replay >> protection, a whole lot of things that took the transport community years >> to get right. Yes, there have been many attempts, but there’s a reason TCP >> is still the protocol everyone uses for pretty much any type of bulk >> transfer. And this is before we even begin to talk about middleboxes >> dropping unrecognized UDP services. >> >>> UDP is also notably better for >>> connections through NAT and suchlike. (I've even done my own >>> experiments in that general direction, although delicious and moist as >>> they seem to be, they're simply experiments and I'm not yet ready to >>> serve them to guests, let alone strangers!) >> >> UDP is connectionless. As such, NAT devices don’t know when it’s done. So >> NAT mappings need to linger a lot longer after the last packet. TCP works >> better with NAT. >> >>> It also results in something that probably looks more like DTLS than >>> anything we have now, or something even stranger, or like nothing >>> anyone can recognise. >>> >>> It may, or very well may not, be a good idea (gleefully gratuitously >>> rampant layering violation/wheel reinvention vs. avoiding unnecessary >>> insecure layers vulnerable to a real, deployed attack/square wheel), >>> but I'd be interested (with no particular hurry) if anyone had had any >>> thoughts in that direction. >> >> It would require an explanation about why this new wheel would be better >> than TCP in IPsec. >> >> Yoav >> >> _______________________________________________ >> 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 Thu Apr 17 07:37: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 469601A0196 for ; Thu, 17 Apr 2014 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnsraiP-LGyL for ; Thu, 17 Apr 2014 07:37:12 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 66F361A016E for ; Thu, 17 Apr 2014 07:36:47 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 689791A009B; Thu, 17 Apr 2014 16:36:43 +0200 (CEST) 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 BA-G2HnWFqhV; Thu, 17 Apr 2014 16:36:34 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id D4C921A0097; Thu, 17 Apr 2014 16:36:34 +0200 (CEST) Received: from [10.53.40.204] (port=17541 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1WanQY-0002eL-67; Thu, 17 Apr 2014 16:36:34 +0200 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.181.6; Thu, 17 Apr 2014 16:36:33 +0200 Message-ID: <534FE6F1.9090100@secunet.com> Date: Thu, 17 Apr 2014 16:36:33 +0200 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: Watson Ladd , "Joseph Salowey (jsalowey)" References: <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6gmgO7epyZW2XYJoAYxpl0k2eTM Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:37:16 -0000 Watson Ladd wrote on 17.04.2014 05:24: > Dear all, > I support most of the removal ideas. I would like to note in > particular that 3DES has a 64-bit block, which limits the transferable > data to 2^32 blocks, and so as a backup to AES it is painful. (We > would also need to fix the EtM problem with it: a lot of work that we > don't have to do). I think DHE will fall before ECDHE, but they are > similar enough > > ECDSA is a complicated story. Yes, it makes unnecessary use of a > random number generator during signing. It is much safer to add 32 > bytes to the secret key, hash that with the message, take that key, > stretch to twice as long as the group order with the hash function. > The inversion of k serves no purpose now that Schnorr's patent has > expired. It cannot be batched. > > However, it is still very secure. I would like to see more performant > alternatives develop, but from a security perspective it's fine. FIPS > can do it however they can, and non-FIPS people will do it the right > way. I don't think removal is the right decision at this juncture. > I second that. There are ECDSA implementations out there using sound RNG/PRNG, which are not easily modified. E.g. FIPS certified HW devices. -- Johannes From nobody Thu Apr 17 07:43: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 85DA51A010F for ; Thu, 17 Apr 2014 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMP25btUsJlN for ; Thu, 17 Apr 2014 07:43:04 -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 38A0D1A0088 for ; Thu, 17 Apr 2014 07:43:04 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5E2F028650 for ; Thu, 17 Apr 2014 14:43:00 +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 4579E2861C for ; Thu, 17 Apr 2014 14:43:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 394FBFE054 for ; Thu, 17 Apr 2014 14:43:00 +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; Thu, 17 Apr 2014 10:42:59 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 17 Apr 2014 10:42:59 -0400 Thread-Topic: Re: Bakeoffs Thread-Index: Ac9aSyq5duSMnvQiS+aG1o/AlPwmag== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-Lhe6jqtz7YucRm90jFVGGocXc0 Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 14:43:05 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I got some questions off-list about my comments on "not meeting the charter= ." I should clarify. It's okay if we aren't able to meet all the goals of the charter. I could = charter a WG to solve the four-color map problem and prove P=3DNP, and conc= lude with only one goal met. :) /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I got some quest= ions off-list about my comments on “not meeting the charter.”&n= bsp; I should clarify.

 =

It’s okay if we aren’t able to meet al= l the goals of the charter.  I could charter a WG to solve the four-co= lor map problem and prove P=3DNP, and conclude with only one goal met. = ; J

 

    =             /r$=

 

--=  

Principal Security Engineer=

Akamai Technology

Cambridge, MA

 =

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30USMBX1msgcorp_-- From nobody Thu Apr 17 07:52: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 2B9F31A0179 for ; Thu, 17 Apr 2014 07:52:45 -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 1gz8hjq2WCGC for ; Thu, 17 Apr 2014 07:52:41 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0341C1A0240 for ; Thu, 17 Apr 2014 07:52:40 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so460190lab.41 for ; Thu, 17 Apr 2014 07:52:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nXO9c9CjVVz3vKxBGKv03TRna7I28i8JGFOgPlDv+4Q=; b=nLo3hOHw5q26CAouSt+vqd0LTtRFmT7pImhmkHqClk0buTelM6sCpzlGFls+MygMrx DVR9ve4+XiNTzLHotgA7DZXXmquYEXmhKwdbe8rRgfjVYoLZkxTer8TeBuOgsAgEAOtV zAJmKm3gcX6pmuxVT94vbTZDovDrCKPA0k58rCy4/MLeh9G+/63uj114AaV84ROffYQT Qqbt6XHSLyLjV7J5HAUIlRvNF0NWeESnOkgKIb/vDkgIHQ5mGqMmYiFjcZOV9ncq3+FP DJC0suMmT0IYZg1/Vy8FbNfoTJcm8vV9fgkfgSiZKzIjnVh6A5U3fRTxjlNmuDf0hmFH 1tEg== X-Gm-Message-State: ALoCoQkIwNvnITHoxnM2tn8UZ7E+Mbsrug4lAwnnXY6cQlaWoN/kyrVQImp1Dcd/ej+WWOhY3nsj X-Received: by 10.112.150.162 with SMTP id uj2mr1581632lbb.52.1397746356797; Thu, 17 Apr 2014 07:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Thu, 17 Apr 2014 07:52:16 -0700 (PDT) In-Reply-To: <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> From: Andy Lutomirski Date: Thu, 17 Apr 2014 07:52:16 -0700 Message-ID: To: "Sniffen, Brian" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L3kW90YiSKLY6SLrb_YGEIO7jHc Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:52:45 -0000 On Thu, Apr 17, 2014 at 6:16 AM, Sniffen, Brian wrote: > On Apr 16, 2014, at 10:08 PM, "Andy Lutomirski" wrote: >> >> You still only need four. Remember that my ClientHello key is >> completely independent of the key associated with the server >> certificate, and that it can be stripped. > > Do I understand that you intend one for normal operation, one more during rotations---and then for my example that different people want different crypto, another operation/rotation pair? Yes. > > I can imagine that working well in 2015. I think in 2020 we'll surely find it too tight and chafing. Maybe that is enough. > I'd much rather allow an unlimited number of keys, but it's not obvious to me that it's possible to do that. I think that we need a protocol in which Bob knows N private keys, Alice knows one of those keys, Alice can encrypt a message to Bob using that key, Bob can decrypt it in time t(N), and an eavesdropper who does not know any of the private keys can't distinguish the message from random? My protocol has t(N) linear in N -- Bob does tries decrypting with each key. Does anyone know of a protocol that scales better? If we're willing to lose a bunch of the nice properties, we could just include a short has of the public key. To me, that seems like a tradeoff that we'd be better off without. --Andy From nobody Thu Apr 17 08: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 8C4811A0240 for ; Thu, 17 Apr 2014 08:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sqSs4YHFChm for ; Thu, 17 Apr 2014 08:04:48 -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 476AD1A023F for ; Thu, 17 Apr 2014 08:04:39 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 93406165560; Thu, 17 Apr 2014 15:04:35 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 88A92165558; Thu, 17 Apr 2014 15:04:35 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 7151A1E05C; Thu, 17 Apr 2014 15:04:35 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 17 Apr 2014 11:04:34 -0400 From: "Salz, Rich" To: Nico Williams Date: Thu, 17 Apr 2014 11:04:33 -0400 Thread-Topic: [TLS] Renegotation redux Thread-Index: Ac9Z6EVCBlheiHNpTEWBmRdlfLZD6gAZdkOg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A57@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/7jQmgDqiTQfhKg-zb-bSudIiA2w Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotation redux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 15:04:49 -0000 > I've thought more about this and... I've changed my mind. Regardless of the topic, this doesn't seem to happen often. This is exampl= e we all (myself included!) should take to heart. /r$=20 -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Apr 17 08:05: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 D7D961A0257 for ; Thu, 17 Apr 2014 08:05:21 -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 ZlYNIN9hsKIk for ; Thu, 17 Apr 2014 08:05:20 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82E1A01E2 for ; Thu, 17 Apr 2014 08:05:20 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so619931vcb.6 for ; Thu, 17 Apr 2014 08:05:16 -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=D382aLi57IkXsbcHilMw2c1WUHWDqY/7ynAoH14T8Pg=; b=WfY8Q0zlnBV+R8sKX6MFzQVFbqQ4fXI28BII++ermULRWNcxbDXhkHfQ3WjRoepf0v 4sF2vWzbiiVu0UqAO1iLs7hvnIoCdJ3vihCC7OYvpIsNigHiBU6/KGnPY4nfskG/ScNu IwywDpF6+QWAPMBH/1dOvzoMnuPI+DMWeacpqW867m1wixZDeGc8wQqwUozjUBGc2cvB 4X5gg4jlgVnUFahRmwYK1dZhl6zKgscUMGYHkw9asELbc5tDNPuqQeSfiE/dRlAmucJ+ dPngbi/Wb4UfQE3DTRCOGdflQwu3DVFklBnqb4Vw8LqHueJ/9y09IL0EvtWSXyPPP9zD UvrA== MIME-Version: 1.0 X-Received: by 10.52.166.102 with SMTP id zf6mr7483408vdb.2.1397747116449; Thu, 17 Apr 2014 08:05:16 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.18.70 with HTTP; Thu, 17 Apr 2014 08:05:16 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> Date: Thu, 17 Apr 2014 11:05:16 -0400 X-Google-Sender-Auth: p1P95_LPUN_qJegH_XP40o57TPI Message-ID: From: Erik Nygren To: Andy Lutomirski Content-Type: multipart/alternative; boundary=001a11c361dc5ca76a04f73e5cee Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xUwHJ4LieXBegR86S9i7iQL0iZA Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:05:22 -0000 --001a11c361dc5ca76a04f73e5cee Content-Type: text/plain; charset=UTF-8 If Alice sends a plaintext key label along with the message, the options seem to be: 1) Don't send any key label resulting in t(N) 2) Send a small key label (eg, a value from 1-M) allowing for t(N/M) but providing a passive listener additional visibility based on the size of M 3) Send a medium-sized key label (same as above) which seems like the worst of all worlds since while this might allow for t(1) it also means a large M 4) Send a long byte-string key label which allows the server to pack in enough information to allow it to be time-variant (eg, a timestamp plus an encrypted version of the timestamp and more detailed routing information) It seems like 4 and 2 are the most desirable options here? Erik On Thu, Apr 17, 2014 at 10:52 AM, Andy Lutomirski wrote: > On Thu, Apr 17, 2014 at 6:16 AM, Sniffen, Brian > wrote: > > On Apr 16, 2014, at 10:08 PM, "Andy Lutomirski" > wrote: > >> > >> You still only need four. Remember that my ClientHello key is > >> completely independent of the key associated with the server > >> certificate, and that it can be stripped. > > > > Do I understand that you intend one for normal operation, one more > during rotations---and then for my example that different people want > different crypto, another operation/rotation pair? > > Yes. > > > > > I can imagine that working well in 2015. I think in 2020 we'll surely > find it too tight and chafing. Maybe that is enough. > > > > I'd much rather allow an unlimited number of keys, but it's not > obvious to me that it's possible to do that. > > I think that we need a protocol in which Bob knows N private keys, > Alice knows one of those keys, Alice can encrypt a message to Bob > using that key, Bob can decrypt it in time t(N), and an eavesdropper > who does not know any of the private keys can't distinguish the > message from random? > > My protocol has t(N) linear in N -- Bob does tries decrypting with > each key. Does anyone know of a protocol that scales better? > > If we're willing to lose a bunch of the nice properties, we could just > include a short has of the public key. To me, that seems like a > tradeoff that we'd be better off without. > > --Andy > --001a11c361dc5ca76a04f73e5cee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If Alice sends a plaintext key label along with the m= essage, the options seem to be:

1) Don't send any key= label resulting in t(N)
2) Send a small key label (eg, a val= ue from 1-M) allowing for t(N/M) but providing a passive listener additiona= l visibility based on the size of M
3) Send a medium-sized key label (same as above) which seems lik= e the worst of all worlds since while this might allow for t(1) it also mea= ns a large M
4) Send a long byte-string key label which allow= s the server to pack in enough information to allow it to be time-variant (= eg, a timestamp plus an encrypted version of the timestamp and more detaile= d routing information)

It seems like 4 and 2 are the most desirable options here?= =C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Erik




<= div class=3D"gmail_quote">On Thu, Apr 17, 2014 at 10:52 AM, Andy Lutomirski= <luto@amacapital.net> wrote:
On Thu, Apr 17, 2014 at 6:16= AM, Sniffen, Brian <bsniffen@aka= mai.com> wrote:
> On Apr 16, 2014, at 10:08 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>
>> You still only need four. =C2=A0Remember that my ClientHello key i= s
>> completely independent of the key associated with the server
>> certificate, and that it can be stripped.
>
> Do I understand that you intend one for normal operation, one more dur= ing rotations---and then for my example that different people want differen= t crypto, another operation/rotation pair?

Yes.

>
> I can imagine that working well in 2015. =C2=A0I think in 2020 we'= ll surely find it too tight and chafing. Maybe that is enough.
>

I'd much rather allow an unlimited number of keys, but it's n= ot
obvious to me that it's possible to do that.

I think that we need a protocol in which Bob knows N private keys,
Alice knows one of those keys, Alice can encrypt a message to Bob
using that key, Bob can decrypt it in time t(N), and an eavesdropper
who does not know any of the private keys can't distinguish the
message from random?

My protocol has t(N) linear in N -- Bob does tries decrypting with
each key. =C2=A0Does anyone know of a protocol that scales better?

If we're willing to lose a bunch of the nice properties, we could just<= br> include a short has of the public key. =C2=A0To me, that seems like a
tradeoff that we'd be better off without.

--Andy

--001a11c361dc5ca76a04f73e5cee-- From nobody Thu Apr 17 08: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 82A231A027F for ; Thu, 17 Apr 2014 08:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 ZwnEl4eacW0k for ; Thu, 17 Apr 2014 08:31:00 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC5F1A025D for ; Thu, 17 Apr 2014 08:30:58 -0700 (PDT) MIME-version: 1.0 Received: from mail-out.apple.com by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) id <0N4600F00LILQO00@local.mail-out.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 08:30:45 -0700 (PDT) Received: from relay2.apple.com ([17.128.113.67]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N4600DAHLR5PQR0@local.mail-out.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 08:30:45 -0700 (PDT) X-AuditID: 11807143-f79f66d0000015d3-07-534ff3a5eacc Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id B1.91.05587.5A3FF435; Thu, 17 Apr 2014 08:30:45 -0700 (PDT) Received: from [17.153.49.162] (unknown [17.153.49.162]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0N4600LOGLR7QJ50@sesame.apple.com> for tls@ietf.org; Thu, 17 Apr 2014 08:30:45 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_93F75697-B4CD-4104-A2E2-47ACB631AD46"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Thu, 17 Apr 2014 11:30:43 -0400 Message-id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> To: Patrick McManus X-Mailer: Apple Mail (2.1874) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FDcoLv0s3+wwdGJ2hafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/Hqx0wF0/MrLk06y9LAeC+li5GTQ0LARKJ37hdGCFtM4sK9 9WwgtpBAH5PEt8XiXYxcQPYsJolJ3x6ygCSEBaQlbk7YxAxi8wroSZw5+4sdpIhZYAqjRNeD Q2CT2ATUJH5P6mMFsTkFgiXu7L0OFmcRUJWY3fUUbBCzgI/E76arUINsJCbevsIOsW0ri8SM axvAikQEtCSOLp3IDnGerMSjD00sExj5ZyFZPgvZ8llgg5MkWhvfskPY2hLLFr5mnsXIAWTr SExeyIgqDGF/PH+ECcI2lXjydjsbhG0t8XPOI6h6RYkp3Q/ZFzByrWIUKErNSaw00kssKMhJ 1UvOz93ECI6GQucdjMeWWR1iFOBgVOLh5fjtFyzEmlhWXJl7iFEFaMSjDasvMEqx5OXnpSqJ 8Lo89g8W4k1JrKxKLcqPLyrNSS0+xCjNwaIkzqvHDJQSSE8sSc1OTS1ILYLJMnFwSjUwJqef Tv40peKzzZHDZqXiFpavDeMvPDr9/vUCjpi5di/Y7k1Y+nvuR3Xe3wvqLnrff31mm1KOt7e8 9GWnkiXJ0suWbdMIe3szn3XtS6mtB6ZJqv1Unr9R+fPdy5oT66/yuSQtndr0ct9u+8/VN56+ WCxoU/0k69bSwLyu6J4Jx75GXemzXhQtKq7EUpyRaKjFXFScCAD0/3lAjgIAAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=apple.com; s=mailout2048s-14-01; t=1397748645; bh=q6daZVYcAF4jUzMrdGo72B4VGLq2vUbpQ/5HUux/ayw=; h=Subject:From:In-reply-to:Date:Cc:References:To; b=aWHAw0WIJccUNwbCaVyWFTdLcWWCQT6eADcZvtzgzoe0g0oQ32VRrfYo7dRZ319Qi BPiVy7f6hybOGl1K9dnCpKGNsFXeYwMrrhDdU1V8IMqrySD/9en1Oc+hgL7wQ4Tac0 9hNZRwxJmO5UtBxHwky1iOFfYh7vqrrU6rWob63jsTaBr+220B6IjUdSBF2OCSr9nr hHEwThDYNaGmgjR51yLuTxzIeHke5uL0g7Z5Isn6rgRMtuMd4NzOQlQq+hmathbAYN zOQzDjIIqgFv7k7Nsjluntb8iz5ThvvwE4D6rwwIZ5M5r0uP+B7M9/TABPzp8GzQMQ 3c9RC4yg2crSA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pW8J4dYjL3v-0axZSqDCYLH9R2Y Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 15:31:02 -0000 --Apple-Mail=_93F75697-B4CD-4104-A2E2-47ACB631AD46 Content-Type: multipart/alternative; boundary="Apple-Mail=_11A9CD14-4BC7-419A-AEAF-D614E3F1BC66" --Apple-Mail=_11A9CD14-4BC7-419A-AEAF-D614E3F1BC66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Patrick, On Apr 17, 2014, at 9:41 AM, Patrick McManus = wrote: >=20 > On Thu, Apr 17, 2014 at 8:19 AM, Michael Sweet = wrote: > >> FWIW, 1-RTT latency is mainly an issue when you have a browser = making a dozen connections to a secure site. With HTTP/2 that = particular problem goes away... >=20 > As a browser guy I'll say I really disagree with that. As a printer guy, I can definitely say that browsers opening dozens of = connections is a major source of latency, since the printer's ability to = respond to so many simultaneous connections is limited. It's even worse = when you tunnel connections over USB (IPP USB protocol) and have to = multiplex requests over a limited number of channels (2 in most cases). I'll grant that many web sites pull content from multiple = servers/domains, in particular to support advertising, however it is = uncommon (at least in my experience) to find all of a page's resources = spread to different servers. > HTTP/2 is important stuff, and helps hide part of the problem, but the = latency issue continues to be an issue for HTTP over TLS use cases. Time = to first byte of course, but also to each different referenced origin = (the cdn, the third-party ad network, the identity provider, etc..). = Often things that block layout are on that cdn (e.g. stylesheets, some = javascript) so the time to perform 2 http transactions on 2 serialized = tls terminated connections is often the same as time to first screen = draw. Its considerably worse in mobile environments where RTT can be out = of control. Indeed, especially when you are opening dozens of connections before = even doing a TLS handshake. > Establishing TLS is noticeably slow, and that's a problem for the = browser use case where https often competes against http for developer = mind share. As a natural result, some content providers choose to run = plaintext http which we can all agree is an undesirable outcome. = Shrinking that gap will help. Based on the push back in the HTTP/2 discussions on that subject, I = don't think you'll get unanimous agreement on that. TLS has its place, = and it is important for us to have a solid protocol to support = confidential communications, but there are significant costs associated = with TLS - performance, maintenance, power, money, etc. - that prevent = it from being adopted wholesale today. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_11A9CD14-4BC7-419A-AEAF-D614E3F1BC66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Patrick,

On Apr 17, 2014, at 9:41 = AM, Patrick McManus <pmcmanus@mozilla.com> = wrote:

On Thu, = Apr 17, 2014 at 8:19 AM, Michael Sweet <msweet@apple.com> wrote:
>> = FWIW, 1-RTT latency is mainly an issue when you have a browser making a dozen connections to a secure site.  With HTTP/2 that particular problem = goes away...

As a browser guy I'll say I really disagree with = that.

As a printer guy, I can = definitely say that browsers opening dozens of connections is a major = source of latency, since the printer's ability to respond to so many = simultaneous connections is limited.  It's even worse when you = tunnel connections over USB (IPP USB protocol) and have to multiplex = requests over a limited number of channels (2 in most = cases).

I'll grant that many web sites pull = content from multiple servers/domains, in particular to support = advertising, however it is uncommon (at least in my experience) to find = all of a page's resources spread to different = servers.

HTTP/2 is important stuff, and helps hide part of the = problem, but the latency issue continues to be an issue for HTTP over = TLS use cases. Time to first byte of course, but also to each different = referenced origin (the cdn, the third-party ad network, the identity = provider, etc..). Often things that block layout are on that cdn (e.g. = stylesheets, some javascript) so the time to perform 2 http transactions = on 2 serialized tls terminated connections is often the same as time to = first screen draw. Its considerably worse in mobile environments where = RTT can be out of = control.

Indeed, especially = when you are opening dozens of connections before even doing a TLS = handshake.

Establishing TLS is noticeably slow, and that's a problem for the = browser use case where https often competes against http for developer = mind share. As a natural result, some content providers choose to run = plaintext http which we can all agree is an undesirable outcome. = Shrinking that gap will = help.

Based on the push = back in the HTTP/2 discussions on that subject, I don't think you'll get = unanimous agreement on that. TLS has its place, and it is important for = us to have a solid protocol to support confidential communications, but = there are significant costs associated with TLS - performance, = maintenance, power, money, etc. - that prevent it from being adopted = wholesale today.

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

= --Apple-Mail=_11A9CD14-4BC7-419A-AEAF-D614E3F1BC66-- --Apple-Mail=_93F75697-B4CD-4104-A2E2-47ACB631AD46 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 9w0BCQUxDxcNMTQwNDE3MTUzMDQ0WjAjBgkqhkiG9w0BCQQxFgQUeRVDQHTKd1afzcROcgxGpdKA 51cwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQB97OOtSZ6R34gXcLn8HQbwMB3yTHv2bzYN2KI32qa/DDWJehqccARGXp9wBwFTMMCBDyNcHPSy GdJ3yL6VjDrb/wZVPjtflJOIf2o/DuwD+R9FA1+7DiZv+XmmKfV7LBpJ6rLEceX0V/oCQhgcA8de ZXScqOQwBR+NBCPSGc3LbgdiMldVrzi0XP5Pom5eKEX0f3/aeyGZQjYKK+1ghz7G4XwHI1J5cze1 DBP2y1b5oXC87EV6VDyJOpHYy8Ra2j2wQpMoEClnjkQ5MT+ovZ2zcMuoqbt8V3/Kga9PK82KMnGG BVE+q0wmJE8R/l0lCcNMrokH8h12XEcQv/hhYi34AAAAAAAA --Apple-Mail=_93F75697-B4CD-4104-A2E2-47ACB631AD46-- From nobody Thu Apr 17 09:03: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 658271A01BB for ; Thu, 17 Apr 2014 09:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 6_TraUAJdxBe for ; Thu, 17 Apr 2014 09:03:29 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A07921A00A3 for ; Thu, 17 Apr 2014 09:03:29 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 436321B4059 for ; Thu, 17 Apr 2014 09:03:26 -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=5NtTDQizbj1dXa4rQXacM1HOdcw=; b=HCG94B6TGLv FFVuoSH+8Z5BKKED4csoxJlLEs2C6C6/9nJik3K1xdx1NGir5fmJJdIdqcx535qp F1OM+BWKSZd4GoxyuMx1Q3O4orggAdABDM0zB6snI1Xn6khUlkXsWusJwEiey4l4 aGW3TB5mihtUme8l+STcU8A7Cp5211wI= 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-a28.g.dreamhost.com (Postfix) with ESMTPSA id E724B1B4058 for ; Thu, 17 Apr 2014 09:03:25 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so1047517wib.5 for ; Thu, 17 Apr 2014 09:03:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr24798150wib.39.1397750604729; Thu, 17 Apr 2014 09:03:24 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:03:24 -0700 (PDT) In-Reply-To: <534F6A06.6090508@streamsec.se> References: <20140417035011.GA25499@localhost> <534F6A06.6090508@streamsec.se> Date: Thu, 17 Apr 2014 11:03:24 -0500 Message-ID: From: Nico Williams 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/yFFsjgabYS3oY4UpJijrdhBM5B8 Cc: "tls@ietf.org" Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:03:33 -0000 On Thu, Apr 17, 2014 at 12:43 AM, Henrick Hellstr=C3=B6m wrote: > On 2014-04-17 05:50, Nico Williams wrote: >> - For rekeying just introduce a CCS-like record whose purpose is to >> indicate that the sender is changing to new keys on the send side. >> The new keys are derived from the same master secret as the precedin= g >> keys, in the same way, but with a counter appended to the "key >> expansion" salt. >> >> There's no need to synchronize, but DTLS requires retransmission of >> such messages else when dropped the recipient will not be able to >> decrypt any subsequent messages. > > > This might be an option if the purpose of the renegotiation is just to > reduce the risk of state collisions in the bulk encryption cipher, but it= is Yes, much like SSHv2 recommends rekeying after 2^L/4 packets, where L is the cipher's block length (sadly no reference is given for this). > no replacement for renegotiation of DHE/ECDHE sessions in order to refres= h > the perfect forward secrecy. This could be done with a single round trip, no need for a full handshake. The payloads containing the ephemeral keys for rekeying could be sent opportunistically when the application writes. Nico -- From nobody Thu Apr 17 09: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 DA68E1A00E6 for ; Thu, 17 Apr 2014 09:16:01 -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 gGJ1ftKqpEVV for ; Thu, 17 Apr 2014 09:15:58 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 03BF11A00DD for ; Thu, 17 Apr 2014 09:15:58 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 81D149406B for ; Thu, 17 Apr 2014 09:15:54 -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=kPztaJkz4xh3QzPTC3gpwoyyRbs=; b=lof2Aor+5dc 5iDobExOfjBxw78M7zbGZ+slh1gbKZxU9izz81kbISbHB0v1XGkUaWGpiKJShU4J VlqEzA/aVDFpBsQtBTaWdcamqafFkhdeKOli2mKK9trXK5E3Qbe8D5Euzv3cb67k oXgwCqLShViTehQjA/yNC7SqqaI3P5gY= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 3405794065 for ; Thu, 17 Apr 2014 09:15:54 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so636237wgh.0 for ; Thu, 17 Apr 2014 09:15:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr13009523wib.42.1397751353044; Thu, 17 Apr 2014 09:15:53 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:15:52 -0700 (PDT) In-Reply-To: <2763DE41-00D1-4C86-8982-A11B3A77D40C@gmail.com> References: <20140417035011.GA25499@localhost> <2763DE41-00D1-4C86-8982-A11B3A77D40C@gmail.com> Date: Thu, 17 Apr 2014 11:15:52 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/46IveDV25aEmE7lLJ37KpEg6u7c Cc: "tls@ietf.org" Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:16:02 -0000 On Thu, Apr 17, 2014 at 2:47 AM, Yoav Nir wrote: > On Apr 17, 2014, at 6:50 AM, Nico Williams wrote: >> - For authentication other than that provided by the initial handshake >> I propose application-specific solutions. > > Do you mean something like Martin=E2=80=99s proposal ([1][2]) or doing th= e whole thing in HTTP as a new HTTP authentication method? The latter. When using PK/PKI or PSK there's no need for more than one round trip, so for HTTP it's pretty simple as there'd be no impact on statelessness. For SASL applications we'd need new SASL mechanisms (although ISTR that there is a SASL mechanism for using PK/PKI). That covers a large number of Internet applications that use TLS! Nico -- From nobody Thu Apr 17 09:16: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 31A721A00DD for ; Thu, 17 Apr 2014 09:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0crJs6fgn9C for ; Thu, 17 Apr 2014 09:16:06 -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 1D8601A0169 for ; Thu, 17 Apr 2014 09:16:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6BE1E4741E; Thu, 17 Apr 2014 16:16:02 +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 5CAC24740D; Thu, 17 Apr 2014 16:16:02 +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 5373DFE055; Thu, 17 Apr 2014 16:16:02 +0000 (GMT) Received: from Tereva.local (172.19.113.67) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 17 Apr 2014 12:16:01 -0400 From: Brian Sniffen To: Alyssa Rowan , "tls@ietf.org" In-Reply-To: <534F05DD.5010906@akr.io> References: <20140415153435.7f82b3a0@hboeck.de> <534F05DD.5010906@akr.io> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Thu, 17 Apr 2014 11:15:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gI0Csp5JWvn8h172gcolBwgNAnw Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:16:10 -0000 Alyssa Rowan writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > It looks like RC4 is rapidly heading for the chopping block, with > basically unanimous consensus. Good. Agreed, mod Martin's proposal that I understand to ask for a reasonable path by which we strongly deprecate RC4 on clients, then after a client generation ban RC4 on clients and deprecate for servers. > On 15/04/2014 14:34, Hanno B=C3=B6ck wrote: > >> What other algorithms exist in the TLS spec that should see >> deprecation? [=E2=80=A6] E.g. what about deprecating DSA? > > I actually favour, for reasons of complexity and weakness, potentially > deprecating pretty much everything that falls in the following lists, > if of course it isn't already deprecated, subject to discussion: > > =E2=80=A2 Anything with NULL anything > - An accident waiting to happen (on purpose). We have seen between 300 and 400 customers configure eNULL or aNULL ciphers using OpenSSL cipher strings like "HIGH:-MEDIUM:-LOW". None intended it when asked. Agreed without comment on EXPORT, DES, IDEA, MD5, DSS/DSA. 3DES is currently the one cipher supported by old clients and new servers. Its block size is too small, but we need to do more to provide a path out for people currently stuck using it. ECDSA and SHA-1 must both live until ECDSA/RFC6979 or EdDSA (and SHA-2 or SHA-3) are in common use; it doesn't do anyone any favors to churn that faster than new implementations can become common. What's the right time-line for that? > =E2=80=A2 RSA without forward security > - Seems like we're heading broadly in the direction of requiring > forward-security, which means deprecating plain old RSA in TLSv1.3 > negotiations? Thoughts? This will drive performance-sensitive providers of bulk, non-secret data to stick with TLS 1.2 for years. That may be okay. -Brian --=20 Brian Sniffen Information Security Akamai Technologies From nobody Thu Apr 17 09:19: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 979391A0144 for ; Thu, 17 Apr 2014 09:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=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 2lR_vPFHGfm8 for ; Thu, 17 Apr 2014 09:19:24 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id CDAF81A00FB for ; Thu, 17 Apr 2014 09:19:23 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so637255wgg.18 for ; Thu, 17 Apr 2014 09:19:19 -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=PeGkIzK2XAYfa8iYXN1my7DNwOGBNbo7lP1dRGj+Kbk=; b=Wjn5+x2G/Ci4TwVmhb2rxxtiYOC3tT8j3DanJrE/fTBstlBdnERwF2KzaaciVG/G5V TVRHlwJnKN/wE423ce/6nejcSNeb7CWR8y4A4kyjIk5OpxxQhtLh+ffYNyhKtdKCvsJo 2UrGjFSMfRGhjLY+elyTwD2jl7rczz8wxHLN9k7w3ctR2Mw/pldUD4PkigDjGtB2WtGR wdXqrX2NhVjvfCXGKQ0A+ghsTrfdqNRqwzBn7xHQ7aJ/DcUMJ4x3bCnn3sLz6Av19OdQ USIg1/NY0VCcyGSHVxYr4TXrpb+uHDhj4TjFmQKGPeT1bIODGOVf61VyccwVD/XPA+vi ohMA== X-Gm-Message-State: ALoCoQkRapcIMdq8Aj8QJINmAvRFk+ghDreBBb42RlJEB6wW8we1wNSeDYkm0DAmAFA3UkSmWlLw MIME-Version: 1.0 X-Received: by 10.180.78.41 with SMTP id y9mr11546716wiw.26.1397751559767; Thu, 17 Apr 2014 09:19:19 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 17 Apr 2014 09:19:19 -0700 (PDT) X-Originating-IP: [184.23.29.222] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30@USMBX1.msg.corp.akamai.com> Date: Thu, 17 Apr 2014 09:19:19 -0700 Message-ID: From: Trevor Perrin To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-95A4PvPP87tXDHIY-rkaT9qpUA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 16:19:27 -0000 On Thu, Apr 17, 2014 at 7:42 AM, Salz, Rich wrote: > > It's okay if we aren't able to meet all the goals of the charter. I could > charter a WG to solve the four-color map problem and prove P=NP, and > conclude with only one goal met. J Hi Rich, You've argued before that "if we got rid of the SNI encryption :) the number of changes being considered is pretty small in both number and scope." [1]. I don't think that's true. For example, the EKR draft introduces "semi-static" public keys used for 0-RTT as well as handshake encryption. Removing handshake encryption alone wouldn't eliminate this mechanism. Trevor [1] http://www.ietf.org/mail-archive/web/tls/current/msg12037.html From nobody Thu Apr 17 09:23: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 48E4F1A01C2 for ; Thu, 17 Apr 2014 09:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9-cQbRZw5JT for ; Thu, 17 Apr 2014 09:23:20 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id CEA5E1A00DD for ; Thu, 17 Apr 2014 09:23:20 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ED4A92865C; Thu, 17 Apr 2014 16:23:16 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id D8EE22865B; Thu, 17 Apr 2014 16:23:16 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 735BC202D; Thu, 17 Apr 2014 16:23:16 +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; Thu, 17 Apr 2014 12:23:16 -0400 From: "Salz, Rich" To: Trevor Perrin Date: Thu, 17 Apr 2014 12:23:15 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9aWMvT7aDMF27kRTC7hQoFIXN3gQAAHOiA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2AE5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2A30@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mmgUiaSi3UpOvkhseZtBjAQ9FjI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 16:23:22 -0000 You're probably right in that I'm probably wrong, hence my initial smiley. = Just trying to be good-humoured about all this -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Apr 17 09:33: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 ECCDA1A0241 for ; Thu, 17 Apr 2014 09:33:37 -0700 (PDT) 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_05=-0.5, 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 U479ULR8ZIRZ for ; Thu, 17 Apr 2014 09:33:34 -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 DFB191A01FE for ; Thu, 17 Apr 2014 09:33:33 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so532159ykr.17 for ; Thu, 17 Apr 2014 09:33:30 -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=iGOGnI3AoeIUhPiDkX0usRo/7NpVUM7735Q9Iuuo9BU=; b=NnN/ml5NpZnc6TSDqUImfj8qzB8MgTPnxpyJxeKVHBTFpMPr5IXJKE9Rqk27WwQVQa n9rTGnh6djs6kT1/taYutJaPyleMrQLcRGZtr0IxSNIdSRoPOs234yOPUArFbQ8Xfe15 Ifk33keN1K4BZvu9uWGXrQ0olnLb/y4Llfw1k3HzcFb3huOLZCtbmUhCtLiWI57p/uYs dGWPSJNijoMLqG/ReThpx7y+FD8XoJYRUawjOZO/leET0D9bpmRC5shWY8ObH9KO629M uaHemfjpcgA10SNfsz8idku9umOs+tf+98EHbfANNBnu/j9GtlYgGxLppj9ygTF3yZUO g24g== MIME-Version: 1.0 X-Received: by 10.236.179.162 with SMTP id h22mr23588144yhm.107.1397752410092; Thu, 17 Apr 2014 09:33:30 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 17 Apr 2014 09:33:30 -0700 (PDT) In-Reply-To: References: <20140417035011.GA25499@localhost> <534F6A06.6090508@streamsec.se> Date: Thu, 17 Apr 2014 09:33:30 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LaDJJ7PRpI41rL5AlHcy5IntUCA Cc: "tls@ietf.org" Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:33:38 -0000 On Thu, Apr 17, 2014 at 9:03 AM, Nico Williams wrot= e: > On Thu, Apr 17, 2014 at 12:43 AM, Henrick Hellstr=C3=B6m > wrote: >> On 2014-04-17 05:50, Nico Williams wrote: >>> - For rekeying just introduce a CCS-like record whose purpose is to >>> indicate that the sender is changing to new keys on the send side. >>> The new keys are derived from the same master secret as the precedi= ng >>> keys, in the same way, but with a counter appended to the "key >>> expansion" salt. >>> >>> There's no need to synchronize, but DTLS requires retransmission of >>> such messages else when dropped the recipient will not be able to >>> decrypt any subsequent messages. >> >> >> This might be an option if the purpose of the renegotiation is just to >> reduce the risk of state collisions in the bulk encryption cipher, but i= t is > > Yes, much like SSHv2 recommends rekeying after 2^L/4 packets, where L > is the cipher's block length (sadly no reference is given for this). Real or random security. If we instantiate CBC mode with a PRF instead of a PRP the security declines quadratically as we might call the PRF on the same block with birthday bound issues. The PRP->PRF replacement is another quadratic factor. So we get a probability of distinguishing that is quartic in the number of blocks. I don't know if this is an upper bound as well, or if other proof techniques can increase this bound. For CTR mode the only loss is quadratic from PRP->PRF. > >> no replacement for renegotiation of DHE/ECDHE sessions in order to refre= sh >> the perfect forward secrecy. > > This could be done with a single round trip, no need for a full > handshake. The payloads containing the ephemeral keys for rekeying > could be sent opportunistically when the application writes. This actually doesn't work as well as you think it does. Suppose Alice is sending a long message to Bob and needs to rekey in the middle of the message. Alice sends her half of the ephemeral key exchange. Before Bob can read the rest of the long message, he needs to send data to Alice. It's cleaner than renegotiation, but still has the C problem. However, what it does isn't worth doing. PFS means that revelation of the long term keys doesn't compromise a connection made before the revelation. This holds true even if the connection lasts beyond the compromise. If you leak the long term keys and the connection keys, it's game over. If you leak only the connection keys, then we need to reestablish a connection using the long term keys, and can't use the compromised keys for authentication. I do see the issue with letting keys stay in memory that can decrypt lots of communications, but I think a cleaner method is to do the proposed rekeying in such a way that the state transformation is irreversible. Sincerely, Watson Ladd > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Apr 17 09:36: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 BCFE41A025D for ; Thu, 17 Apr 2014 09:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GKHNDGT-j_Y for ; Thu, 17 Apr 2014 09:36:05 -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 675BA1A0180 for ; Thu, 17 Apr 2014 09:36:05 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 72CF54819C; Thu, 17 Apr 2014 16:36:01 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 6788948160; Thu, 17 Apr 2014 16:36:01 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 4FE4698059; Thu, 17 Apr 2014 16:36:01 +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; Thu, 17 Apr 2014 12:36:00 -0400 From: "Sniffen, Brian" To: Andy Lutomirski Date: Thu, 17 Apr 2014 12:35:59 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9aWx1SzqK4vZqjSD+67sCpzCrhlw== Message-ID: <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/le3ixUlZs1wUH6TBMOkGiw0i8qQ Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:36:12 -0000 On Apr 17, 2014, at 9:52 AM, "Andy Lutomirski" wrote: >=20 > , Bob can decrypt it in time t(N), and an eavesdropper > who does not know any of the private keys can't distinguish the > message from random? Surely the eavesdropper can measure the decryption delay, probe himself, an= d discover which key it was---unless every implementation carefully shuffle= s keys? And now an adversary can cause N decryptions per initiated connection. Ouch= . = From nobody Thu Apr 17 09:52: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 26AE31A01D3 for ; Thu, 17 Apr 2014 09:52: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 aiUdKKJvxQZJ for ; Thu, 17 Apr 2014 09:51:59 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 503371A0252 for ; Thu, 17 Apr 2014 09:51:59 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id AF0721B406F for ; Thu, 17 Apr 2014 09:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=BZKnZt8VO9rPHPtf17Ui3MDS+00=; b=gyUWenD6xUr J8e0TXFUk1PfPDOY5uJzxa5tW/k/OhptNFxj4t2uF29Kr5OeL7ebYWSbRBkrpywF qncqagIKJoejYqpk2MQUSZ/RhDj2PnsC5f3dXwnGq4ZChOLXZ4t/OeMNJyWXFZp7 6shAr1TWCr6wHXK7RRTQY6+FGhksnEtM= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 5A4431B4058 for ; Thu, 17 Apr 2014 09:51:55 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so1109467wib.16 for ; Thu, 17 Apr 2014 09:51:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr13042285wic.5.1397753514014; Thu, 17 Apr 2014 09:51:54 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:51:53 -0700 (PDT) In-Reply-To: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <534F0A33.9070408@akr.io> <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> Date: Thu, 17 Apr 2014 11:51:53 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yfzQRuL90jF9Gnc78JlHIVB4mFQ Cc: "tls@ietf.org" Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:52:03 -0000 On Thu, Apr 17, 2014 at 3:27 AM, Yoav Nir wrote: > On Apr 17, 2014, at 1:54 AM, Alyssa Rowan wrote: > We=E2=80=99re at the wrong layer to fix an attack against TCP. The right= place to protect TCP is either in TCP itself, or by using IPsec. Well, yes, but we're well past having clean layers now. I wouldn't _terribly_ mind an option where TLS keying can be used to key a TCP encryption option. That is, I'd not like it very much, but I'd accept it. > Those who won=E2=80=99t use TCP are doomed to re-create it. To get a UDP-= based protocol to replace TCP for the web you=E2=80=99d need all of reliabl= e delivery through (selective?) retransmissions, bandwidth detection, repla= y protection, a whole lot of things that took the transport community years= to get right. Yes, there have been many attempts, but there=E2=80=99s a re= ason TCP is still the protocol everyone uses for pretty much any type of bu= lk transfer. And this is before we even begin to talk about middleboxes dro= pping unrecognized UDP services. Yes, but TCP has issues. See mosh for an example of why one might abandon TCP for UDP. (Briefly: with UDP one gets mobility for free; with TCP one can only get mobility via IP mobility protocols, therefore one doesn't.) >> UDP is also notably better for >> connections through NAT and suchlike. (I've even done my own >> experiments in that general direction, although delicious and moist as >> they seem to be, they're simply experiments and I'm not yet ready to >> serve them to guests, let alone strangers!) > > UDP is connectionless. As such, NAT devices don=E2=80=99t know when it=E2= =80=99s done. So NAT mappings need to linger a lot longer after the last pa= cket. TCP works better with NAT. Yes, but for some application protocols (e.g., mosh) this is not a big deal= . > It would require an explanation about why this new wheel would be better = than TCP in IPsec. Because no one has cared to implement RFC5660 or anything like it. IPsec as it is implemented and deployed does not provide TLS-like guarantees that the peer at the other end remains the same for the life of the connection (assuming local security). This is a major failure of IPsec, and a barely acknowledge failure at that. If you want to use IPsec for end-to-end security then a) some parts of the authentication process must move to higher layers, b) peer continuity MUST be provided. Any discussion of use of IPsec for end-to-end security [outside small networks] without such an acknowledgment of this just isn't credible. Nico -- From nobody Thu Apr 17 09: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 90DAC1A0297 for ; Thu, 17 Apr 2014 09:53:42 -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 gQwe5yqguOLy for ; Thu, 17 Apr 2014 09:53:37 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE2D1A025D for ; Thu, 17 Apr 2014 09:53:37 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id p9so590690lbv.18 for ; Thu, 17 Apr 2014 09:53: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=Z0LDKaM2zd6K0rIu25Yv/vY1DDPJqOXL9JkJQ57lTXk=; b=avEhAC1E0y30ywBcO7iQLgwlz7cE0tRf03f34Ku80KtQPp7r4zD26nKtL907p2FVUS vh78l0b5zNv8M1JpSDG0KuWdazldW5ZwEm7GEMiDVhei7GeiR0a8D8gosX3g/0LjcHob /0wRkmQCgB2aICEqw5mxD0gJFLq567oA48cJPTFAESlTL2dCaiKeTQkJ/bc+lwd40icI 5df/TGqPxGnLvTZdWe0wEpkaSKsLWC7cpeeGEVNDlu++X2frRehfx0BX42V+ViuIaXRe JDKcyiGqRWl1KrE+G3p5bI8KJpbhMgqOGKM14Qt4J+DcVhTfUx5WKimKNTdav5yFycsE jwCg== X-Gm-Message-State: ALoCoQm2YEHuwgmAa7S0UFmsbtoYDRJclI6YovIAhoaNSd3nMW6RdHM9qNrgVQSgM4WFDhH2iTBO X-Received: by 10.112.142.68 with SMTP id ru4mr1957200lbb.49.1397753612936; Thu, 17 Apr 2014 09:53:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.7 with HTTP; Thu, 17 Apr 2014 09:53:12 -0700 (PDT) In-Reply-To: <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> From: Andy Lutomirski Date: Thu, 17 Apr 2014 09:53:12 -0700 Message-ID: To: "Sniffen, Brian" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Swp6cDOM8KZzH7tAXL2pdHDJ474 Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:53:42 -0000 On Thu, Apr 17, 2014 at 9:35 AM, Sniffen, Brian wrote: > On Apr 17, 2014, at 9:52 AM, "Andy Lutomirski" wrote: >> >> , Bob can decrypt it in time t(N), and an eavesdropper >> who does not know any of the private keys can't distinguish the >> message from random? > > Surely the eavesdropper can measure the decryption delay, probe himself, and discover which key it was---unless every implementation carefully shuffles keys? > > And now an adversary can cause N decryptions per initiated connection. Ouch. If N == 4 and the decryption operations are fast, this isn't so bad. I wonder if there's a way to test a large number of private keys at once. If so, then the cost drops to O(log N). Off the top of my head, I can't think of a cryptosystem with that property. For example, there's a way to check a large number of Schnorr signatures at the same time, but you're expecting all of them to be correct. Here you want to check a large number of private keys at once and find out whether any of them can decrypt a given message. I know there are some serious cryptographers on the list. Anyone? --Andy From nobody Thu Apr 17 09:56: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 C33691A02B8 for ; Thu, 17 Apr 2014 09:56: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 xoVy51DT3hZY for ; Thu, 17 Apr 2014 09:56:26 -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 EFBAE1A0180 for ; Thu, 17 Apr 2014 09:56:25 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so3216093wiv.13 for ; Thu, 17 Apr 2014 09:56:21 -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=qGqyIyrbcMHlv81GxsUOaGyadQvVUwZZsSrYOgW4rvs=; b=WEOitoBeRRkgp2t8orXYHYjG7/jeBrppXGYo/Dz0LXLIwNizId751XlMUNjBrKrxGo IhV1XVQMfgVFETkwCUdwpKlkO/nn3El5gfbRB4ThIgzaZjLU7KsGlABGeLm436Hfe/if plC1vunQFOO5gKdcQ2tyw01zUUO4UBZLjXVeX/CxpkOeuGFMHP/gZMfFf0AtkxnTy7yF gRYVZpBMcgA5Gbi6E8ob0UY9Xn7uYkYSi25mFUx0Lq+yDx26ZuUdd2rBA40HV0Xo/LAR ELPvXEfc0pz/kPO3t5/M8WkzgJlW82Jja0f7jnUQR13zgXJVfb4t/68nV4ElZC+G9C2Q MVYQ== MIME-Version: 1.0 X-Received: by 10.180.106.198 with SMTP id gw6mr13157041wib.50.1397753781780; Thu, 17 Apr 2014 09:56:21 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 09:56:21 -0700 (PDT) In-Reply-To: <20140417035011.GA25499@localhost> References: <20140417035011.GA25499@localhost> Date: Thu, 17 Apr 2014 09:56:21 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KBB8U62li_q9YCqOChwjYMxoxQs Cc: "tls@ietf.org" Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:56:31 -0000 On 16 April 2014 20:50, Nico Williams wrote: > There's no need to synchronize, but DTLS requires retransmission of > such messages else when dropped the recipient will not be able to > decrypt any subsequent messages. > > For DTLS we'll need an ACK message (huh?! DTLS doesn't have such a > thing? nope. Weid!) DTLS can probably just rely on retransmission and evidence that the new keying material is in use. A sequence number reset should alleviate most of the need for trial decryption. From nobody Thu Apr 17 09:57: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 92F181A02DF for ; Thu, 17 Apr 2014 09:57: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 mzUk928fKh-L for ; Thu, 17 Apr 2014 09:57:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF61A02DE for ; Thu, 17 Apr 2014 09:57:00 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so669403wes.8 for ; Thu, 17 Apr 2014 09:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7qTdCdpPmFVzB8dAHIE+6BHKwwX1D/KKyJXkNYsEgB8=; b=rHCbDbno7Isi1WpaqzkxeUf6BO4kmI4I71uECfks/073JaaNkTa+W6c7mkZCTO9HYe oCGzbw82SXndZ/TtorgMgWpcwlKFNEcW1rmPFA6ERULuyHKTxtF95bZ3IoYejp7QGpfp jLMZpO7Ovyylw2YeFTTJqU1++mFAp+9bG8+IEjTmpR5fVGzrhcDfZas+h1hPYl05hA/P SDTBwKI5smRN7EzIMGDlfzVPxnscb5oPE+Q1MSQHlK7kSumAwDO4N0SLz2e/pGYJFO41 1lACy9SzK9tPU2CcbfFkkx6C07Zpszxhwi3h9YHAT2p8qWd9a3CaZnMlcPqtTHo3KZCF shvA== MIME-Version: 1.0 X-Received: by 10.194.90.107 with SMTP id bv11mr12791417wjb.11.1397753816812; Thu, 17 Apr 2014 09:56:56 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 09:56:56 -0700 (PDT) In-Reply-To: <534F6A06.6090508@streamsec.se> References: <20140417035011.GA25499@localhost> <534F6A06.6090508@streamsec.se> Date: Thu, 17 Apr 2014 09:56:56 -0700 Message-ID: From: Martin Thomson 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/vhEKZs_N3JiavqRM6GSSkONm7y4 Cc: "tls@ietf.org" Subject: Re: [TLS] Doing without renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:57:05 -0000 On 16 April 2014 22:43, Henrick Hellstr=C3=B6m wrote= : > This might be an option if the purpose of the renegotiation is just to > reduce the risk of state collisions in the bulk encryption cipher, but it= is > no replacement for renegotiation of DHE/ECDHE sessions in order to refres= h > the perfect forward secrecy. I think that a new connection is a better way to address that use case. From nobody Thu Apr 17 09:59: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 9CA241A0180 for ; Thu, 17 Apr 2014 09:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD5TpQTNKtgq for ; Thu, 17 Apr 2014 09:59:39 -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 7FD511A00DD for ; Thu, 17 Apr 2014 09:59:39 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4C06EE329; Thu, 17 Apr 2014 12:59:35 -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=FqzFAcinloxY /x1tIkV3HGcZL30=; b=nF7mDHenATAF+ynipIE+BOnchZuyZbcTNNjygj5tirqT TkVrN6CcbzJLl/rQ/6XxAKh3Z2U7W6EjH1g1eqhp4O2163azEItK6/McrL30RMjF UAAxs9FS9CZ3sKQEus1PhvQL8lryKN8KTUhtHVcNf+R4pzpqqWprLmLEcmJlnO4= 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=W1NH2l cYKgjtdd8lhLoIGpzC0WnAKQIZw1z5oirp9z/lx1H2Og0x4URUURnGUZ+tqPXeSK B8GaiiUxPyxMW0x/ei0sMTMZmwBz9C6iyagKBXH19LhCxOcGZhzidYOMzrwkX+44 AwuDtC2YhIaFwpLT9/xpUC3gRJaNxgDPAgaGU= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 421A4E328; Thu, 17 Apr 2014 12:59:35 -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 B5E4BE327; Thu, 17 Apr 2014 12:59:33 -0400 (EDT) Message-ID: <53500874.8010105@pobox.com> Date: Thu, 17 Apr 2014 09:59:32 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Patrick McManus References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A67FA5A0-C651-11E3-8A10-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qKoXctyDDkcdPCDFIl6xhFMzZo8 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 16:59:43 -0000 Patrick McManus wrote: > > HTTP/2 is important stuff, and helps hide part of the problem, but the > latency issue continues to be an issue for HTTP over TLS use cases. Time > to first byte of course ... Have any server operators tried using a small-ish (somewhat less than 1500 bytes) TLS record size to reduce time-to-first-byte at the browser? What were the results? Mike From nobody Thu Apr 17 10:00: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 A00931A02F2 for ; Thu, 17 Apr 2014 10:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkNeAmdPNCm3 for ; Thu, 17 Apr 2014 10:00:19 -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 57DC21A0304 for ; Thu, 17 Apr 2014 10:00:19 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so3226690wib.8 for ; Thu, 17 Apr 2014 10:00: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=QSHSXo/rfer22W+pTshEe5qtwHNPIkREQ7gAw9xiR4w=; b=kebWwJW/soFkazjGERUclglF5wLveP4fVUKE5KiwPGm8Qwt1h7PeloQhkJxYUbGjAn LTWCD0KQtCxb/LsoaVSrKxufmgAi0VBHt0FyaiX3psGCzeVkwDuiG1fQR5bTb4wLugXg SALcJdXPtRLCHfyPodjZRHfCNfmPCOKZkT4waqz5zKmkXbbOEdvW7v0U9Cog2U4i6Bb9 uV+3kBVKvBA1UhR4i+VmFYp3HQzjFlH575Qs42UnPzqkRrJN8kYKDoqn3h7B9oS/j4yr 1XIWjS5ADK5CnB4jbxD3eWm+bXxEGV8zypCNk55NLc97Gmrn73moEJcp75SNTdpfcNbk hr8g== MIME-Version: 1.0 X-Received: by 10.194.171.198 with SMTP id aw6mr5069258wjc.23.1397754015225; Thu, 17 Apr 2014 10:00:15 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 10:00:15 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> Date: Thu, 17 Apr 2014 10:00:15 -0700 Message-ID: From: Martin Thomson To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UC3TC681RTuYpmNz5dTs80sZkmg Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:00:24 -0000 On 17 April 2014 08:05, Erik Nygren wrote: > 4) Send a long byte-string key label which allows the server to pack in > enough information to allow it to be time-variant (eg, a timestamp plus an > encrypted version of the timestamp and more detailed routing information) Isn't that what draft-ekr-tls-new-flows effectively proposes? From nobody Thu Apr 17 10:53: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 A82C41A01B0 for ; Thu, 17 Apr 2014 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAARraFftti5 for ; Thu, 17 Apr 2014 10:53:16 -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 CA64C1A0194 for ; Thu, 17 Apr 2014 10:53:15 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 13F0F16553C; Thu, 17 Apr 2014 17:53:12 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (unknown [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 09456165533; Thu, 17 Apr 2014 17:53:12 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id E5B031E03E; Thu, 17 Apr 2014 17:53:11 +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, 17 Apr 2014 13:53:11 -0400 From: "Salz, Rich" To: Michael D'Errico Date: Thu, 17 Apr 2014 13:53:10 -0400 Thread-Topic: [TLS] Bakeoffs Thread-Index: Ac9aXm4It1wvSppvRD2Weim4ygrFVwABzvLw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2B7A@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> <7EBCF98B-FFE6-49D3-B899-A297C8AAA463@apple.com> <53500874.8010105@pobox.com> In-Reply-To: <53500874.8010105@pobox.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/pNttUAzyCkkimeD2hSJgo6oEpA0 Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 17:53:20 -0000 Google changed the size to fit into a common TCP packet and found it highly= worthwhile http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-bufferi= ng-latency/ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Thu Apr 17 13:00: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 A315A1A00B9 for ; Thu, 17 Apr 2014 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI0IzIOO27v8 for ; Thu, 17 Apr 2014 12:59:54 -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 E53021A007B for ; Thu, 17 Apr 2014 12:59:53 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2AE1E481A3; Thu, 17 Apr 2014 19:59:50 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 1EF0E4813F; Thu, 17 Apr 2014 19:59:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id EFBD32FD72; Thu, 17 Apr 2014 19:59:49 +0000 (GMT) Received: from Tereva.local (172.19.113.223) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 17 Apr 2014 15:59:48 -0400 From: Brian Sniffen To: Andy Lutomirski In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> User-Agent: Notmuch/0.17~rc2+11~g8a10ca6 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Thu, 17 Apr 2014 14:59:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O7mkTiqN21jYLPB0Tbl28pq3hPs Cc: "tls@ietf.org" Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:59:58 -0000 Andy Lutomirski writes: > On Thu, Apr 17, 2014 at 9:35 AM, Sniffen, Brian wrote: >> On Apr 17, 2014, at 9:52 AM, "Andy Lutomirski" wrote: >>> >>> , Bob can decrypt it in time t(N), and an eavesdropper >>> who does not know any of the private keys can't distinguish the >>> message from random? >> >> Surely the eavesdropper can measure the decryption delay, probe himself, and discover which key it was---unless every implementation carefully shuffles keys? >> >> And now an adversary can cause N decryptions per initiated connection. Ouch. > > If N == 4 and the decryption operations are fast, this isn't so bad. Cryptographic negotiation attacks are already one of the most powerful DDoS techniques available. Making them 4x more effective is lethal. Unless we want to say they're so dangerous as to be no *more* lethal from quadrupling, this isn't okay. I hesitate to ask, but: is it plausible to re-open the proof-of-work conversation, so a server under load can, in the initial opportunistic encryption phase, push back to a client and ask for a puzzle to be solved? > I wonder if there's a way to test a large number of private keys at > once. If so, then the cost drops to O(log N). Off the top of my > head, I can't think of a cryptosystem with that property. I certainly don't expect to find any *pair* of cryptosystems with that property, and continue to maintain that in 3 years we won't find two big organizations willing to use exactly the same crypto. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Thu Apr 17 13:20: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 89F831A00B9 for ; Thu, 17 Apr 2014 13:20:25 -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 ltimYvAprzEv for ; Thu, 17 Apr 2014 13:20:20 -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 695AB1A0088 for ; Thu, 17 Apr 2014 13:20:20 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so902812wes.34 for ; Thu, 17 Apr 2014 13:20:16 -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=8d5dcZLnl1quIVy9yuGSg+sJ4yh7M0HxfKcOHdL3QX8=; b=YXxo48nCozrhvVfK/+y+N9CAUd7ny4d+i64cxynD72UxEYdKs+yH8zEIzIBGVh365E 3VMp0Y9gyexqio4pmCip9l7iLVGSpRUfHYVJv8+K6ta6JXtFMcfcRGZET6otMGGKNgUf sQfUwf/p9LpOZRqUaKwngMzaUYtYxa8zGPef4MqzzEVsjLoGP5iyR0Vd7jTG9PLTZ76e +TAKhePPDyW+RqylrnW2RaULiAg3ECkbZJM9AMyngnhjOm6myoJx7Z0zXNURjqWDaUss UptKcK4Z9R4bHnvMHDWR+sCjqiX0yavvx5DM/mPPFEvc9gygLFCQ8JZu3od88kuwvelz J/+Q== X-Gm-Message-State: ALoCoQnJCGWPeJRFpPgYj7Yw7nxK2Bp9JBzlLwMXbsWHeIYR3p29KtLSUtvd8pBd0Mo/iTMcW+lO X-Received: by 10.180.94.226 with SMTP id df2mr25343198wib.1.1397766016124; Thu, 17 Apr 2014 13:20:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 13:19:36 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> From: Eric Rescorla Date: Thu, 17 Apr 2014 13:19:36 -0700 Message-ID: To: Brian Sniffen Content-Type: multipart/alternative; boundary=f46d04447e61dee40504f742c2e8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wLrYUksxC8ooI_TJ1eVHd0r7Nxc Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:20:25 -0000 --f46d04447e61dee40504f742c2e8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 12:59 PM, Brian Sniffen wrote: > > I hesitate to ask, but: is it plausible to re-open the proof-of-work > conversation, so a server under load can, in the initial opportunistic > encryption phase, push back to a client and ask for a puzzle to be > solved? I don't think it's implausible (though I'm not completely sold yet). One concern I would have is whether we understand the problem well enough to actually specify this. I'm not an expert in this area, but weren't there a bunch of concerns about designing puzzles that were effective without being prohibitively expensive for mobile devices? How would we design a new kind of puzzle (As opposed to messing with the puzzle work factor) and then roll it out? -Ekr > I wonder if there's a way to test a large number of private keys at > > once. If so, then the cost drops to O(log N). Off the top of my > > head, I can't think of a cryptosystem with that property. > > I certainly don't expect to find any *pair* of cryptosystems with that > property, and continue to maintain that in 3 years we won't find two big > organizations willing to use exactly the same crypto. > > -Brian > > -- > Brian Sniffen > Information Security > Akamai Technologies > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04447e61dee40504f742c2e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 12:59 PM, Brian Sniffen <bsniffen@akamai.com&g= t; wrote:
I hesitate to ask, but: is it plausible to re-open the proof-of-work
conversation, so a server under load can, in the initial opportunistic
encryption phase, push back to a client and ask for a puzzle to be
solved?

I don't think it's implausi= ble (though I'm not completely sold yet).

One = concern I would have is whether we understand the problem well
enough to actually specify this. I'm not an expert in this area, but we= ren't
there a bunch of concerns about designing puzzles that = were effective
without being prohibitively expensive for mobile d= evices? How would
we design a new kind of puzzle (As opposed to messing with the puzzle<= /div>
work factor) and then roll it out?

-Ekr<= /div>

> I wonder if there's a way to test a large number of private keys a= t
> once. =A0If so, then the cost drops to O(log N). =A0Off the top of my<= br> > head, I can't think of a cryptosystem with that property.

I certainly don't expect to find any *pair* of cryptosystems with= that
property, and continue to maintain that in 3 years we won't find two bi= g
organizations willing to use exactly the same crypto.

-Brian

--
Brian Sniffen
Information Security
Akamai Technologies

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

--f46d04447e61dee40504f742c2e8-- From nobody Thu Apr 17 13:26: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 6A8CE1A010E for ; Thu, 17 Apr 2014 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob16Fkl9DGsZ for ; Thu, 17 Apr 2014 13:26:44 -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 1D0301A0054 for ; Thu, 17 Apr 2014 13:26:44 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3B78528620; Thu, 17 Apr 2014 20:26:40 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 234B72861D; Thu, 17 Apr 2014 20:26:40 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 1CF2F80047; Thu, 17 Apr 2014 20:26:40 +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, 17 Apr 2014 16:26:39 -0400 From: "Sniffen, Brian" To: Eric Rescorla Date: Thu, 17 Apr 2014 16:26:35 -0400 Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9ae1XvlfNuTjtVQrGRs8khX/e1/g== Message-ID: <5C1699C1-A67E-4CD9-92DA-996451C97B2B@akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/NPufSskzPaQak2R0IyAvCf0Ukkk Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:26:48 -0000 On Apr 17, 2014, at 3:20 PM, "Eric Rescorla" wrote: >=20 > One concern I would have is whether we understand the problem well > enough to actually specify this. I'm not an expert in this area, but were= n't > there a bunch of concerns about designing puzzles that were effective > without being prohibitively expensive for mobile devices? Oh, I expect to deny service to users whose computational power is swamped = by an adversary node's. I don't have a way to fix that. But conventional pu= zzles are enough to convert an adversary who could deny service to everybod= y---by overloading the server---to one who can only deny service to computa= tionally weak clients, or when they overwhelmingly outnumber normal clients= .=20 And if we ever do come to terms on session resumption, that can help mobile= clients a good bit. I understand most mobile clients keep sessions in pers= istent storage to keep them alive as long as possible for this reason. = From nobody Thu Apr 17 13:31: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 EC4F81A0054 for ; Thu, 17 Apr 2014 13:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.12 X-Spam-Level: * X-Spam-Status: No, score=1.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxLN4zs-qN-b for ; Thu, 17 Apr 2014 13:31:01 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id B04791A0045 for ; Thu, 17 Apr 2014 13:31:01 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 021E71C2153 for ; Thu, 17 Apr 2014 22:30:57 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id DA1331FE0598; Thu, 17 Apr 2014 22:30:56 +0200 (CEST) Date: Thu, 17 Apr 2014 22:30:56 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20140417203056.GA14753@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9MBtOpmP-SOPyQT3qNN_TYb5eu0 Subject: [TLS] TLS padding breaks ironport X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:31:06 -0000 I've just been pointed to: http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Kurt From nobody Thu Apr 17 13:41: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 32D541A0193 for ; Thu, 17 Apr 2014 13:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 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, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZfDuQtDCCJh for ; Thu, 17 Apr 2014 13:41:36 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 79E551A0045 for ; Thu, 17 Apr 2014 13:41:36 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id mc6so785752lab.22 for ; Thu, 17 Apr 2014 13:41:32 -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=8jMDQmCL5x91idxUC2bNXpVg9p5SLcw5Cz0p5yloOio=; b=zFcoW9vEC5xg/dZfr0NNmvQjfBw+URv3k91+MgAnQ4vaejCZ3W0EfLkxwkkRXmYYk5 MMDThIk/59DIjQ0cr1V7rjreb9OHrFodzkg8piXh3vQNDvB6Pu0JBRR+GxevZ3ZDNzfg F7bXI14+/yhEzpxNxGoDJe9u4c4IvbHYiIkwSo/8f8TkqFYtx0pQRyGRyYBqodDG2Gec +wwGCmCQDqsPVFM7EuxVrTJ2z2SQa0LuvpXVZXZHcgpBpXkymUrOFwaD9u8V2hdZOFv7 WnZp27HAjzrMnsyu7YszzWIeE+cQjuBnGhPwQFPPxjso5J3+whkw+CAuRNeiTmPUxc3x 5BAg== MIME-Version: 1.0 X-Received: by 10.152.8.161 with SMTP id s1mr30760laa.67.1397767292204; Thu, 17 Apr 2014 13:41:32 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.35.131 with HTTP; Thu, 17 Apr 2014 13:41:32 -0700 (PDT) In-Reply-To: <20140417203056.GA14753@roeckx.be> References: <20140417203056.GA14753@roeckx.be> Date: Thu, 17 Apr 2014 13:41:32 -0700 X-Google-Sender-Auth: m4_aEwnnCvHpN9F72a8iT2zkYko Message-ID: From: Adam Langley To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KRlj1kfXv7slJdh4P41j1YW8m4c Cc: "tls@ietf.org" Subject: Re: [TLS] TLS padding breaks ironport X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:41:41 -0000 On Thu, Apr 17, 2014 at 1:30 PM, Kurt Roeckx wrote: > I've just been pointed to: > http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Thanks for the heads up. SMTP is one of those corners that Chrome 33 didn't manage to shake down for the padding extension. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Apr 17 13:47: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 74CC01A019E for ; Thu, 17 Apr 2014 13:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 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, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoD2tSTHXHxx for ; Thu, 17 Apr 2014 13:47:06 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2731A0045 for ; Thu, 17 Apr 2014 13:47:06 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id m5so862972qaj.6 for ; Thu, 17 Apr 2014 13:47:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KjlzmlMa+Uwxl30uxZ6n1l2u+wOlVpbYYeioy25ByzE=; b=lofV5wJAf7QX79Ck0qNGuCuEwI6NanU725ttkrsVNuyiBDPMqTvEvzh2EmlWtl/9GL 34JhWt8nBuzQZuBXbQo/s4LfNe/OyM+d2Qg5Ywh6lGEnk66x/PjGxa81KDwjF/Il13xW pLN+T4Xwlfgeiwx9KzoRK4ajGr/M98FJWVSnk3LoEt4ZSv51nxCL1U2/oOFuXTzJ7Upk BWt30gU28NUGnX0JiEhUp5VKaiUUeIxVxV4jb+9L9hGLd46Zehhg/tgNjVoVbFODsf7C jd6FG/fvOBGcRIMHU6UO2yonuiys41caUVFLadtwhE2Pru/9IhLRB24vOVENMJ/V5jbu v4Sg== X-Gm-Message-State: ALoCoQlm+MUzNTzmQRbdu5SCocze8cSoeuieV1teoEk3f0iE2Nv8uVyRU+C1b5Xs0LawYFDl3UO2 MIME-Version: 1.0 X-Received: by 10.224.30.70 with SMTP id t6mr15962081qac.30.1397767622755; Thu, 17 Apr 2014 13:47:02 -0700 (PDT) Received: by 10.224.39.18 with HTTP; Thu, 17 Apr 2014 13:47:02 -0700 (PDT) In-Reply-To: <20140417203056.GA14753@roeckx.be> References: <20140417203056.GA14753@roeckx.be> Date: Thu, 17 Apr 2014 13:47:02 -0700 Message-ID: From: Brian Smith To: Kurt Roeckx Content-Type: multipart/alternative; boundary=047d7bdca66aa219ee04f7432279 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AdEYqlGH4RXbqDvMsqgJ0O2V-2I Cc: "" Subject: Re: [TLS] TLS padding breaks ironport X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:47:11 -0000 --047d7bdca66aa219ee04f7432279 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 1:30 PM, Kurt Roeckx wrote: > I've just been pointed to: > > http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html > See also https://bugzilla.mozilla.org/show_bug.cgi?id=989062, which is also about a compatibility issue with the padding extension, and which affects HTTPS, not just email. In particular, some websites break in Firefox 29+ due to this, and those websites result in non-secure TLS version intolerance fallback in some Chrome versions. Wan-Teh Chang found that the server mentioned in the Mozilla bug report is sensitive to the ordering of the extensions in the client hello, and that changing the client hello extension order in NSS got the site working. But, we have yet to figure out what the optimal ordering is for maximizing compatibility with all products globally. It seems like the Mozilla bug report and the OpenSSL bug report may be referring to the same issue in the same server TLS stack. In that case, it may be a good idea for OpenSSL to also consider fixing the issue by changing the ordering of extensions in its ClientHello. And/or, we may try one or both the three following workarounds: (1) If the ClientHello size *without* the session ticket extension included is less than 256 bytes, then don't send the padding extension, even if the ClientHello is in the "danger zone" of 256-512 bytes. The assumption here is that any product using session tickets that would cause the Client Hello size to enter the danger zone would not have the incompatibility that the padding extension works around. (2) If the ClientHello would contain a session ticket *at all*, then don't send the padding extension. The (unverified) assumption here would be that the F5 products that had the compatibility issue with ClientHellos in the danger zone do not support session tickets. (3) Don't use the padding extension at all, and instead include a fake session ticket in the session ticket extension, when the ClientHello size is in the danger zone and there's no session ticket to send. The assumption here, which is almost certainly invalid, is that server implementations all silently discard malformed session tickets sent by the client. Cheers, Brian --047d7bdca66aa219ee04f7432279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 1:30 PM, Kurt Roeckx <kurt@roeckx.be> wrote= :
I've just been pointed to:
http://postf= ix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-intero= p-issue-td66873.html

See also https://bugzilla.mozilla.org/show_bug.cgi?= id=3D989062, which is also about a compatibility issue with the padding= extension, and which affects HTTPS, not just email. In particular, some we= bsites break in Firefox 29+ due to this, and those websites result in non-s= ecure TLS version intolerance fallback in some Chrome versions.

Wan-Teh Chang found that the server mentioned in the Mozilla= bug report is sensitive to the ordering of the extensions in the client he= llo, and that changing the client hello extension order in NSS got the site= working. But, we have yet to figure out what the optimal ordering is for m= aximizing compatibility with all products globally.

It seems like the Mozilla bug report and the OpenSSL bug rep= ort may be referring to the same issue in the same server TLS stack. In tha= t case, it may be a good idea for OpenSSL to also consider fixing the issue= by changing the ordering of extensions in its ClientHello.

And/or, we may try one or both the three following workaroun= ds:

(1) If the ClientHello size *without* the session ticket extensi= on included is less than 256 bytes, then don't send the padding extensi= on, even if the ClientHello is in the "danger zone" of 256-512 by= tes. The assumption here is that any product using session tickets that wou= ld cause the Client Hello size to enter the danger zone would not have the = incompatibility that the padding extension works around.

(2) If the ClientHello would contain a session ticket *at al= l*, then don't send the padding extension. The (unverified) assumption = here would be that the F5 products that had the compatibility issue with Cl= ientHellos in the danger zone do not support session tickets.

(3) Don't use the padding extension at all, and instead = include a fake session ticket in the session ticket extension, when the Cli= entHello size is in the danger zone and there's no session ticket to se= nd. The assumption here, which is almost certainly invalid, is that server = implementations all silently discard malformed session tickets sent by the = client.

Cheers,
Brian

--047d7bdca66aa219ee04f7432279-- From nobody Thu Apr 17 13:58:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7CB1A00E5 for ; Thu, 17 Apr 2014 13:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.331 X-Spam-Level: ** X-Spam-Status: No, score=2.331 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5M0pZfk7yW7 for ; Thu, 17 Apr 2014 13:58:39 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.39.7]) by ietfa.amsl.com (Postfix) with ESMTP id AA9341A0054 for ; Thu, 17 Apr 2014 13:58:39 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 85D2F27D05084; Thu, 17 Apr 2014 15:58:35 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 0F60B27D04F79 for ; Thu, 17 Apr 2014 15:58:35 -0500 (CDT) Received: from [96.231.225.192] (port=53575 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WatOE-0004Pt-00; Thu, 17 Apr 2014 15:58:34 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Thu, 17 Apr 2014 16:58:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> To: Watson Ladd X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WatOE-0004Pt-00 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:53575 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CqBplHdZaayYzeaw7uFACw0D9Pg Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 20:58:40 -0000 On Apr 15, 2014, at 21:19, Watson Ladd wrote: > Fundamentally the question is this: Why will Eric Rescorla do > correctly this time what he failed to do correctly twice before?=20 Watson, Please stop the personal attacks. The IETF published the TLS RFCs after = the IETF consensus process is run. That process includes the WG = reaching consensus (sometimes rough), the wider IETF community reaching = consensus, and the entire IESG reviewing the WG=92s specification. = Ownership of any failings is to be shared by a very wide community. spt (as chair)= From nobody Thu Apr 17 14:16: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 77B131A0119 for ; Thu, 17 Apr 2014 14:16: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 pY-4YzXS84Ev for ; Thu, 17 Apr 2014 14:15:51 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 08DEF1A0054 for ; Thu, 17 Apr 2014 14:15:50 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hm4so50929wib.2 for ; Thu, 17 Apr 2014 14:15: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=GYOL6KH16PPJwybZEiVZq9AmcTmy6ITSh2B/pldwlTw=; b=N9QlVLv2nkYxWsJiIPp2ZdIXUIFygnWzeh7a7Ha/khkjpOSG3d8Ug+Dexh4tIlgZfN dMbJIv/b2dyB3478Noz2CV1lxXvp9xe2Ldoo5V6+MagWUZeSB9AwiKeP8lLPqYGaP0YK sGvpv5zeoRC/m1y6cDp3OIwYMDarAbA+ILjlxpOJDoXT/nS6F2wwhsGpLyJaqYOC1qSn TDYNeS/e4ce8lyZa/gI8xGwzT7Pw1r0gMmp0vx+ASvEjsHcCl56fyTmweLGFVTDwg9tg xdniqjAq3B/GbMkPPOUemGGlSHDQMZXzstdPNK6WMNlyIMhfuchUwXFW5PVV4zn8fdNU PLyQ== MIME-Version: 1.0 X-Received: by 10.194.192.132 with SMTP id hg4mr13712585wjc.28.1397769346955; Thu, 17 Apr 2014 14:15:46 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 14:15:46 -0700 (PDT) In-Reply-To: References: <20140417203056.GA14753@roeckx.be> Date: Thu, 17 Apr 2014 14:15:46 -0700 Message-ID: From: Martin Thomson To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qrj4xxOxOprKBE0JSKhiibzANWI Cc: "" Subject: Re: [TLS] TLS padding breaks ironport X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:16:01 -0000 On 17 April 2014 13:47, Brian Smith wrote: > (3) Don't use the padding extension at all, and instead include a fake > session ticket in the session ticket extension, when the ClientHello size is > in the danger zone and there's no session ticket to send. The assumption > here, which is almost certainly invalid, is that server implementations all > silently discard malformed session tickets sent by the client. Yes, that seems unlikely to work in the extreme, based on the description of the SSL2/TLS length bug we have. The only trigger there is the length of the ClientHello. I think that it might be OK to turn off padding if there is a session ticket. This might be conditional, as you describe, but I'm guessing that the only cases where we enter the 256-511 range is as a result of the session ticket, so there is probably no difference between (1) and (2) in practice. From nobody Thu Apr 17 14:26: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 DDFF31A012A for ; Thu, 17 Apr 2014 14:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.132 X-Spam-Level: *** X-Spam-Status: No, score=3.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwpEbLHM-c7N for ; Thu, 17 Apr 2014 14:26:22 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.139.20]) by ietfa.amsl.com (Postfix) with ESMTP id CE3CE1A0054 for ; Thu, 17 Apr 2014 14:26:22 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 35CAE46D145A4; Thu, 17 Apr 2014 16:26:19 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 1C56546D1455C for ; Thu, 17 Apr 2014 16:26:19 -0500 (CDT) Received: from [96.231.225.192] (port=53676 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Watp4-0006Lk-Bb for tls@ietf.org; Thu, 17 Apr 2014 16:26:18 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 17 Apr 2014 17:26:17 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Watp4-0006Lk-Bb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:53676 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hJ0B6jJgt_rNuKLsRbqhXmUbLts Subject: [TLS] Concluding the TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 21:26:24 -0000 All, Thanks for a vigorous discussion on process. The chairs continue to believe that the process outlined in our previous message [0] represents the way forward most consistent with our chartered direction. Accordingly, we will not be holding a contest for an entirely new protocol but will use RFC 5246 as a starting point. Proposals to modify TLS to meet the charter requirements should be phrased as revisions to RFC 5246. Further discussion of changes to or reinterpretation of the charter are now out out of scope for this working group and should be taken off this mailing list. We already have a number of active discussions of important technical topics: SNI Encryption: http://www.ietf.org/mail-archive/web/tls/current/msg11823.html Making the PRF Compatible with Hardware Modules: http://www.ietf.org/mail-archive/web/tls/current/msg12094.html Renegotiation (or lack thereof): http://www.ietf.org/mail-archive/web/tls/current/msg11966.html Extensive trimming of the cryptographic primitives: http://www.ietf.org/mail-archive/web/tls/current/msg12006.html We encourage WG members to focus their attention on these topics and hope that we can make rapid progress on these on-list or at the f-2-f interim. spt for the chairs [0] http://www.ietf.org/mail-archive/web/tls/current/msg11657.html From nobody Thu Apr 17 14:29: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 E6BF01A012A for ; Thu, 17 Apr 2014 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.132 X-Spam-Level: *** X-Spam-Status: No, score=3.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIfpxMsdHBSd for ; Thu, 17 Apr 2014 14:29:43 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.139.20]) by ietfa.amsl.com (Postfix) with ESMTP id 135751A0054 for ; Thu, 17 Apr 2014 14:29:43 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 8C7DE46D250E0; Thu, 17 Apr 2014 16:29:39 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 71AE546D25050 for ; Thu, 17 Apr 2014 16:29:39 -0500 (CDT) Received: from [96.231.225.192] (port=53750 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WatsI-0003Cb-LJ for tls@ietf.org; Thu, 17 Apr 2014 16:29:38 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 17 Apr 2014 17:28:56 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WatsI-0003Cb-LJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:53750 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g_eB5wUtI2CY4r0g1zJH0Sgufmk Subject: [TLS] github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:29:47 -0000 WG Members, Going forward we will be following the successful example of the HTTPbis WG and using github to organize our work. This means: - The editor will maintain the editor's draft on github in the following repository: https://github.com/tlswg/tls13-spec - Technical changes can be submitted as pull requests and are subject to the usual WG consensus process before being merged. No substantive technical discussion should occur in github. If you cannot submit a pull request, you can send text directly to the list but pull requests are preferred for tracking purposes. The editor may also be tasked by the WG to make technical changes directly, based on WG consensus. - Editorial changes should be submitted as pull requests and the editor may just merge them directly and/or commit editorial changes directly as needed. - If you believe a change has been committed inappropriately, either note this on the list/chairs/editor or if the change is minor, submit your own pull request to back it out. - Revisions will be submitted as internet drafts regularly, and be tagged (see process in [1]). We still maintain a manual change log for major issues, but the commit history is used as a more detailed record. - The git issue tracker will be used to manage outstanding issues, but as above, any substantive discussion should happen on-list. We also will use github for meeting arrangements, agendas and minutes. These will also be posted to the IETF datatracker as usual. The editor has posted a first RFC 5246 bis draft at the following location: https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.txt This draft should not contain any intentional substantive changes and is just a baseline for future change tracking. I=92ve checked it, you should too. spt for the chairs [1] https://github.com/tlswg/tls13-spec/blob/master/SUBMITTING.md= From nobody Thu Apr 17 14:30: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 D74691A0168; Thu, 17 Apr 2014 14:30:29 -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 VGX83kaiMrTY; Thu, 17 Apr 2014 14:30:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5041A0054; Thu, 17 Apr 2014 14:30:28 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417213028.20510.75767.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 14:30:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CZpWracW5GgpFMc_c-BxLhI4mJQ Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc5246-bis-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: Thu, 17 Apr 2014 21:30:30 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Authors : Tim Dierks Eric Rescorla Filename : draft-ietf-tls-rfc5246-bis-00.txt Pages : 102 Date : 2014-04-17 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc5246-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-rfc5246-bis-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 Thu Apr 17 14: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 044601A01A0; Thu, 17 Apr 2014 14:34: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1dR06FDJsvX; Thu, 17 Apr 2014 14:34:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C231A0133; Thu, 17 Apr 2014 14:34:53 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417213453.22251.81675.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 14:34:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W5N905KkGvVWtQrbYz7ybtoIw_g Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-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: Thu, 17 Apr 2014 21:34:54 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Authors : Tim Dierks Eric Rescorla Filename : draft-ietf-tls-tls13-00.txt Pages : 102 Date : 2014-04-17 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-tls13-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 Thu Apr 17 14:40: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 344CA1A01A5 for ; Thu, 17 Apr 2014 14:40:00 -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 OOnYxGL1QVid for ; Thu, 17 Apr 2014 14:39:56 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 22BB91A0054 for ; Thu, 17 Apr 2014 14:39:55 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so974448wes.30 for ; Thu, 17 Apr 2014 14:39: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K3IgeRZfBElUYhRSTT+pRtfYWHXqvOaCF119t20Df5o=; b=D/YhrqBR92JqESxr/KINyHuYQdQ1HIB48Tx8ABu3fa5Nl2LLVScGy2tPdPT86EvqOP EeeUTcywpkxb0a099+vLlf42h3KD71ZH9Jg6uRxE59oO/PN+icz4TX8F/GdRGDnTBuBI zVLHFeVEF3ffC2zPfyyxdprQFXY+ITrY0A8VwwmqwDbYQ3BZ/l54HzAXCbOEG32w6Aft kw9yExraH1MjDQLWVf7WOprEUasKP6rSjV3RXYQF3WM/3VSXYP+VxxLqWbCAK5Y1wHGP N+DArzsGO2awfKMYuZ0sxEKiVHu4zxfBLNCtOK0MWlgcB3A0plLMkTsYX5tuD+hrzZz5 WzVg== X-Gm-Message-State: ALoCoQkdqCJC3MJKbGHWgpX8CoAUYdDEBqZ/jB6REwYkdOqZE5rrGlXYoNs6/Jy2EdPWphag6ptK X-Received: by 10.180.90.140 with SMTP id bw12mr13906118wib.18.1397770791956; Thu, 17 Apr 2014 14:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 14:39:11 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: References: From: Eric Rescorla Date: Thu, 17 Apr 2014 14:39:11 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=f46d043c811a883f1704f743dfc1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VFlDbGRDsgJ9-nHAlCdwi9no87I Cc: "" Subject: Re: [TLS] github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 21:40:00 -0000 --f46d043c811a883f1704f743dfc1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 2:28 PM, Sean Turner wrote: > WG Members, > > Going forward we will be following the successful example of the > HTTPbis WG and using github to organize our work. > > This means: > > - The editor will maintain the editor's draft on github in the > following repository: https://github.com/tlswg/tls13-spec > > - Technical changes can be submitted as pull requests and are subject > to the usual WG consensus process before being merged. No > substantive technical discussion should occur in github. If you > cannot submit a pull request, you can send text directly to the list > but pull requests are preferred for tracking purposes. The editor > may also be tasked by the WG to make technical changes directly, > based on WG consensus. > > - Editorial changes should be submitted as pull requests and the > editor may just merge them directly and/or commit editorial changes > directly as needed. > > - If you believe a change has been committed inappropriately, either > note this on the list/chairs/editor or if the change is minor, > submit your own pull request to back it out. > > - Revisions will be submitted as internet drafts regularly, and be > tagged (see process in [1]). We still maintain a manual change log > for major issues, but the commit history is used as a more detailed > record. > > - The git issue tracker will be used to manage outstanding issues, > but as above, any substantive discussion should happen on-list. > > We also will use github for meeting arrangements, agendas and > minutes. These will also be posted to the IETF datatracker as > usual. > > The editor has posted a first RFC 5246 bis draft at the following > location: > https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.txt > This draft should not contain any intentional substantive changes > and is just a baseline for future change tracking. I've checked it, > you should too. > This has now been submitted as an I-D. At: http://tools.ietf.org/html/draft-ietf-tls-tls13-00 Please ignore the notification for rfc5246-bis. I fumble-fingered the draft name. The correct draft name is: draft-ietf-tls-tls13-00 As Sean said, there should be no substantive changes between this draft and RFC 5246. If you find any, please let me know and/or submit a git pull request and I will correct. -Ekr spt for the chairs > > [1] https://github.com/tlswg/tls13-spec/blob/master/SUBMITTING.md > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043c811a883f1704f743dfc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 17, 2014 at 2:28 PM, Sean Turner <TurnerS@ieca.com><= /span> wrote:
WG Members,

Going forward we will be following the successful example of the
HTTPbis WG and using github to organize our work.

This means:

- The editor will maintain the editor's draft on github in the
  following repository: https://github.com/tlswg/tls13-spec

- Technical changes can be submitted as pull requests and are subject
  to the usual WG consensus process before being merged. No
  substantive technical discussion should occur in github. If you
  cannot submit a pull request, you can send text directly to the list=
  but pull requests are preferred for tracking purposes. The editor   may also be tasked by the WG to make technical changes directly,
  based on WG consensus.

- Editorial changes should be submitted as pull requests and the
  editor may just merge them directly and/or commit editorial changes<= br>   directly as needed.

- If you believe a change has been committed inappropriately, either
  note this on the list/chairs/editor or if the change is minor,
  submit your own pull request to back it out.

- Revisions will be submitted as internet drafts regularly, and be
  tagged (see process in [1]).  We still maintain a manual change= log
  for major issues, but the commit history is used as a more detailed<= br>   record.

- The git issue tracker will be used to manage outstanding issues,
  but as above, any substantive discussion should happen on-list.

We also will use github for meeting arrangements, agendas and
minutes.  These will also be posted to the IETF datatracker as
usual.

The editor has posted a first RFC 5246 bis draft at the following
location:
https://github.com/tlswg/tls13-spec/blob/master= /draft-ietf-tls-tls13.txt
This draft should not contain any intentional substantive changes
and is just a baseline for future change tracking.  I’ve checked= it,
you should too.

This has now been submi= tted as an I-D. At:
http://tools.ietf.org/html/draft-ietf-tls-tls13-00

Please ignore the notification for rfc5246-bis. I fumbl= e-fingered the draft
name. The correct draft name is:  draft= -ietf-tls-tls13-00

As Sean said, there should be n= o substantive changes between this
draft and RFC 5246. If you find any, please let me know and/or submit<= /div>
a git pull request and I will correct.

-= Ekr

spt for the chairs

[1] https://github.com/tlswg/tls13-spec/blob/master/SUBMIT= TING.md
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d043c811a883f1704f743dfc1-- From nobody Thu Apr 17 14:59: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 EA0001A0208 for ; Thu, 17 Apr 2014 14:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OLNI3G2bTjU for ; Thu, 17 Apr 2014 14:58:57 -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 E84D51A01A5 for ; Thu, 17 Apr 2014 14:58:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A2B524750E for ; Thu, 17 Apr 2014 21:58:51 +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 64235474E4 for ; Thu, 17 Apr 2014 21:58:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 552C8FE054 for ; Thu, 17 Apr 2014 21:58:50 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 17 Apr 2014 17:58:44 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 17 Apr 2014 17:58:43 -0400 Thread-Topic: Incorporate by reference Thread-Index: Ac9ah15vDfb3/f/EQSq311EU2rjt4Q== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCE@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCEUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-atTW9zBGfinXQ_FpjRRkXsiUgA Subject: [TLS] Incorporate by reference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 21:59:02 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCEUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are several TLS-related RFC's that we probably want to roll up into T= LS 1.3. One thing we should consider is to incorporate them by reference. = For example, have a section that says The TLS padding specification, RFC nnnn, is to be considered part of = this document and is incorporated by reference, with the following changes: 1. .... Whatever... if there are any. Be more explicit than just an entry in the 'normative reference' list. And= it gives us a chance to explicitly list errata, exceptions, etc. There cases where this makes sense, and cases (encrypt then mac) where it d= oesn't. But I think it's a worthwhile tool to have in the editor's tool= box. -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCEUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are severa= l TLS-related RFC’s that we probably want to roll up into TLS 1.3.&nb= sp; One thing we should consider is to incorporate them by reference. = For example, have a section that says

<= o:p> 

      The= TLS padding specification, RFC nnnn, is to be considered part of this docu= ment and is incorporated by reference, with the following changes:

1.   &n= bsp;   …. Whatever… if there = are any.

 

Be more explicit than just an entry in the ‘normative re= ference’ list.  And it gives us a chance to explicitly list erra= ta, exceptions, etc.

 

There cases where this makes sense, and cases (encry= pt then mac) where it doesn’t.     But I think it= ’s a worthwhile tool to have in the editor’s toolbox.

 

-- = ;

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

<= p class=3DMsoNormal> 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCEUSMBX1msgcorp_-- From nobody Thu Apr 17 15: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 167441A0110 for ; Thu, 17 Apr 2014 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Urre4oemy5ZR for ; Thu, 17 Apr 2014 15:16:21 -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 88F2B1A0100 for ; Thu, 17 Apr 2014 15:16:21 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so98131wiv.6 for ; Thu, 17 Apr 2014 15:16: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:from:date :message-id:subject:to:cc:content-type; bh=IvpzpcoRJfKQKfMx/isI8zYyiGRdItdjLyN6fTKPhdY=; b=ea9kC4VkM5LHt65sfaQHHRORLgVr50YFW5VSE+Ia0S6NNofLM2daTgzIQXAYuvmEZ1 xUzoEzw/+HdfOkpeXLqaenPu338inW4JQkLZwqH74NwT5OgCqOyBhNrOc/oFncaTFAYv aMtlebWm8vLLOztLV1SWvTIsfIT3hSJ9ZvfrQh52bjPAi1F3rQQIckyPECv+NvpiuXNO wUYEFWFRBdJr5T0aK6khLdjp1CHCwFVNfxF+lSJ3lfABJm04c1PIRSWxigdiAvVd6Z4b TkgohlMABkZ6LCs+UruYaLnUarvKwsm6sWFJnfSxgqjYvC635yW9DOGJfmpjwrWGvN1Z +5/g== X-Gm-Message-State: ALoCoQmnmdOorYr0ELaGxz/yP5lZh1dnwJY8UO5lS2eUQsQs1qKe9q3N5Mst9aQSFEq42vjLwDxj X-Received: by 10.180.212.76 with SMTP id ni12mr13890067wic.49.1397772977350; Thu, 17 Apr 2014 15:16:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 15:15:37 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCE@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCE@USMBX1.msg.corp.akamai.com> From: Eric Rescorla Date: Thu, 17 Apr 2014 15:15:37 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c351a4cac51004f7446172 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GwmkStUA0cEhcWYyI0vYySt41ts Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Incorporate by reference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 22:16:26 -0000 --001a11c351a4cac51004f7446172 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 2:58 PM, Salz, Rich wrote: > There are several TLS-related RFC's that we probably want to roll up into > TLS 1.3. One thing we should consider is to incorporate them by > reference. For example, have a section that says > > > > The TLS padding specification, RFC nnnn, is to be considered part of > this document and is incorporated by reference, with the following changes: > > 1. .... Whatever... if there are any. > > > > Be more explicit than just an entry in the 'normative reference' list. > And it gives us a chance to explicitly list errata, exceptions, etc. > > > > There cases where this makes sense, and cases (encrypt then mac) where it > doesn't. But I think it's a worthwhile tool to have in the editor's > toolbox. > This does seem like a useful tool. We'll need to use some taste to determine where this is appropriate and where copying the text in is best. -Ekr --001a11c351a4cac51004f7446172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Apr 17, 2014 at 2:58 PM, Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com&g= t; wrote:

There are several TLS-related RFC’= s that we probably want to roll up into TLS 1.3.  One thing we should = consider is to incorporate them by reference.  For example, have a sec= tion that says

 

 = ;     The TLS padding specification, RFC nnnn, is to be= considered part of this document and is incorporated by reference, with th= e following changes:

1.       …. Whatever… if there are any.

 

Be more explicit than just an entry in the ‘normative reference&rsquo= ; list.  And it gives us a chance to explicitly list errata, exception= s, etc.

 

There cases where this makes sense, and cases (encrypt = then mac) where it doesn’t.     But I think it&rs= quo;s a worthwhile tool to have in the editor’s toolbox.


This does seem like a useful t= ool. We'll need to use some taste to determine
where this is = appropriate and where copying the text in is best.

-Ekr 
--001a11c351a4cac51004f7446172-- From nobody Thu Apr 17 15:48: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 10C7E1A01CF for ; Thu, 17 Apr 2014 15:48:16 -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 cLInL0A85oua for ; Thu, 17 Apr 2014 15:48:12 -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 E23CB1A01BB for ; Thu, 17 Apr 2014 15:48:11 -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 s3HMm4Lu001431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 15:48:05 -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: Thu, 17 Apr 2014 15:48:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D6E890D-CF68-4903-A371-C7CD8A0A9113@vpnc.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCE@USMBX1.msg.corp.akamai.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7d3jvODjRmDK3Kqpqm4hyH7fb0E Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Incorporate by reference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 22:48:16 -0000 On Apr 17, 2014, at 3:15 PM, Eric Rescorla wrote: > This does seem like a useful tool. We'll need to use some taste to = determine > where this is appropriate and where copying the text in is best. And for the ones where you thought about it, but didn't pull stuff in, = it is still useful to list those RFCs in 1.3. "In addition to the RFCs = that have been incorporated into this document, TLS implementers should = certainly also consider implementing RFCs abcd and efgh." --Paul Hoffman= From nobody Thu Apr 17 15:51: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 44E121A01BB for ; Thu, 17 Apr 2014 15:51:31 -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 KmnRmBFg-CIS for ; Thu, 17 Apr 2014 15:51:27 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id EA2981A0188 for ; Thu, 17 Apr 2014 15:51:26 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so117841wiv.13 for ; Thu, 17 Apr 2014 15:51:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FAsmgD0zLa+3+W4uo0U3Rg/qow+EB0MMTBnNi8dDmPQ=; b=IoSX+z5rTf1IDUcASmLjG2WzeTfcf48rFK6AajsdBCscN+I0Lq5cBTWEdjGnJuvdCv YIr0aIJhOxrBbQ+YdqRlhPlq/3K/9pQYvZZ7Zf3gJMmnygTeAmscwFgu91DQTEwFOl+U eC3X7ixqG+468Xjluvl49nyChQNXU/vDqjuy2vnXsLnqdTubMFMrxNNX07DlgydZgIUd jXVZYWhoRfpeHjzjCM8LuJGC0m1lGXsD+KvCSyG3NRZXFWQa5npr1axHMGqYu2mATIvz uomsztpdMJtidYYcctsUgDtslJ+50G5gwyPnSCCA1etAX2dcdNpBeVq8Mxbdn/clzwPz EKnw== X-Gm-Message-State: ALoCoQlJMQDuswtmeDVSf6eBKuIqzrBtmzu2IlJ7K/bKbOdzGla3axhGurI4zyjrPun1XgUjAjHT X-Received: by 10.194.203.170 with SMTP id kr10mr13934847wjc.19.1397775081861; Thu, 17 Apr 2014 15:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 15:50:41 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: <5D6E890D-CF68-4903-A371-C7CD8A0A9113@vpnc.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120BCF2CCE@USMBX1.msg.corp.akamai.com> <5D6E890D-CF68-4903-A371-C7CD8A0A9113@vpnc.org> From: Eric Rescorla Date: Thu, 17 Apr 2014 15:50:41 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b6d87de3b09da04f744dfcd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LfBD9zUYCkSoCLU4uUnrpY8Lsog Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Incorporate by reference X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 22:51:31 -0000 --047d7b6d87de3b09da04f744dfcd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 3:48 PM, Paul Hoffman wrote: > On Apr 17, 2014, at 3:15 PM, Eric Rescorla wrote: > > > This does seem like a useful tool. We'll need to use some taste to > determine > > where this is appropriate and where copying the text in is best. > > And for the ones where you thought about it, but didn't pull stuff in, it > is still useful to list those RFCs in 1.3. "In addition to the RFCs that > have been incorporated into this document, TLS implementers should > certainly also consider implementing RFCs abcd and efgh." > +1. -Ekr --047d7b6d87de3b09da04f744dfcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 17, 2014 at 3:48 PM, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:
On Apr 17, 2014, at 3:15 PM,= Eric Rescorla <ekr@rtfm.com> wro= te:

> This does seem like a useful tool. We'll need to use some taste to= determine
> where this is appropriate and where copying the text in is best.

And for the ones where you thought about it, but didn't pull stuf= f in, it is still useful to list those RFCs in 1.3. "In addition to th= e RFCs that have been incorporated into this document, TLS implementers sho= uld certainly also consider implementing RFCs abcd and efgh."

+1.

-Ekr

--047d7b6d87de3b09da04f744dfcd-- From nobody Thu Apr 17 16:05:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C121A0235 for ; Thu, 17 Apr 2014 16:05:43 -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 fY3M2PPMG_x8 for ; Thu, 17 Apr 2014 16:05:39 -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 0FFB81A01DB for ; Thu, 17 Apr 2014 16:05:38 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so967785yho.1 for ; Thu, 17 Apr 2014 16:05:35 -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=rFFDNfeksEUYwzG59UDY0KAPWJRtiAqBAYE6b3JKZHQ=; b=A6k8Z0lXkotzhDvSznL6los7FpfzfloYKlTLVeUkTAAdsocdUTghPRCesriI3T0iJ3 CGcaywhXfe2HFDR/z/PJtHVz4jwwUgK31iAJu9PgJYdOLTnKU5bCIfpsFAo/3wiYPRHZ maC1Fyq/StXwPXVd8F23mLemDTF0nvfQ3sg9SXRo1RSW0qkshkHOOs5jnnLTXyvUmsZn WDzgFdqu/QPQ6QcRrfmVJtcnNWuN/liLTp8hoHLEXyOkRos86ZaK6SDQeG9h+/4tuNrQ a7oTnD0R8PY2cJw9xQaRpdBPlO0uGiwN1Xszd3GSpteht8PmH7qmBeToSGkZjb2OMQf8 O2aA== MIME-Version: 1.0 X-Received: by 10.236.30.230 with SMTP id k66mr26128942yha.57.1397775935250; Thu, 17 Apr 2014 16:05:35 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.170.126.207 with HTTP; Thu, 17 Apr 2014 16:05:34 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> Date: Thu, 17 Apr 2014 19:05:34 -0400 X-Google-Sender-Auth: hURTU1_mdzT0vhcTZF75aQ84a9I Message-ID: From: Erik Nygren To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0163407418c28b04f745120d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ktcSGSUCbsLOWGa5NB6yng1hWuY Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:05:43 -0000 --089e0163407418c28b04f745120d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 1:00 PM, Martin Thomson wrote: > On 17 April 2014 08:05, Erik Nygren wrote: > > 4) Send a long byte-string key label which allows the server to pack in > > enough information to allow it to be time-variant (eg, a timestamp plus > an > > encrypted version of the timestamp and more detailed routing information) > > Isn't that what draft-ekr-tls-new-flows effectively proposes? > Exactly, hence my proposal to include that in a DNS Service Binding record. The concern raised was that this could be used by a passive attacker to further identify the hostname the client was connecting to. By preference would be to take this approach but provide some guidance on a way to help raise the bar. For example, constructing this label with something like: { timestamp, label_key_vers , AES(label_key, timestamp || SNI_routing_identifier || handshake_keyversion ) } would reduce some of these attacks over just having a static value in the label (which might degenerate down to something with a static 1:1 identifier with the SNI which would some of the point of encrypting the SNI in the first place). Erik --089e0163407418c28b04f745120d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 1:00 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 17 Apr= il 2014 08:05, Erik Nygren <er= ik+ietf@nygren.org> wrote:
> 4) Send a long byte-string key label which allows the server to pack i= n
> enough information to allow it to be time-variant (eg, a timestamp plu= s an
> encrypted version of the timestamp and more detailed routing informati= on)

Isn't that what draft-ekr-tls-new-flows effectively proposes?

Exactly, hence my p= roposal to include that in a DNS Service Binding record.=C2=A0
The conc= ern raised was that this could be used by a passive attacker
to further identify the hostname the client was connecting to.
By preference would be to take this approach but pr= ovide some guidance
on a way to help raise the bar.=C2=A0 For example, c= onstructing this label with
something like:

=C2=A0=C2=A0=C2=A0 { timestamp, label_key_vers , AES= (label_key, timestamp || SNI_routing_identifier || handshake_keyversion ) }=

would reduce some of these attacks= over just having a static value in the label (which might
degenerate down to something with a static 1:1 identifier with the SNI whic= h would some of the
point of encrypting the SNI in the first place).
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Erik


--089e0163407418c28b04f745120d-- From nobody Thu Apr 17 16:18: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 CF7821A0100; Thu, 17 Apr 2014 16:18:30 -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 HWd8H99FtWo8; Thu, 17 Apr 2014 16:18:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B13461A0054; Thu, 17 Apr 2014 16:18:25 -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.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417231825.13974.54669.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 16:18:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/psPZeHUPjIfDX52Rs8WSt6LP9o8 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:18:31 -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 : The Transport Layer Security (TLS) Protocol Version 1.3 Authors : Tim Dierks Eric Rescorla Filename : draft-ietf-tls-tls13-01.txt Pages : 103 Date : 2014-04-17 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-tls13-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 17 16:23: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 884391A01C7 for ; Thu, 17 Apr 2014 16:23:14 -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 7FV7AepKoWIP for ; Thu, 17 Apr 2014 16:23:10 -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 C30D41A0196 for ; Thu, 17 Apr 2014 16:23:09 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so145653wiv.0 for ; Thu, 17 Apr 2014 16:23: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=5s6LwIZP9AnOhXCCEOb2yyA9qTQm/nc8xtnkSzMEXWs=; b=P0yyXaU7BoXGnN0ZFA9bOvVDCUqFSwY3Wfwor+DbbDa0jaF1XVTbySRbYnrZLP3Jr0 /8nAg4z5iV7hZ2YMhuUo3USHdt1P1LOiBDb+dQ2aTWK6NEnqtOO0bhA7ChKBKjKftYev O0zCAMqKCqdYyZtr0xvqM9eLEwmmmuT25exKV9Ee1gA1SmbFARUNeflagtanwtg5wMaa 8o0cZIHEJqpiTlj5/FGpfM+YXM+Bul/CZzppBN0Fujbvk9Gx7caRwQtmGPHLGkgxgPO5 MHviFH7Lco6caL2EldaJxjWxggA056OX3I3nEFZh9YINmMPHg087gnoAIUIQ0B0UdR6S oVEw== X-Gm-Message-State: ALoCoQmGfGCB7Nys/UTwB6vSjlAhiLJ6W9A/PMJHvfgNCsDxBAgJbCgy/71uN9FrzltS8BY4px8L X-Received: by 10.194.187.107 with SMTP id fr11mr968882wjc.70.1397776985670; Thu, 17 Apr 2014 16:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 16:22:25 -0700 (PDT) X-Originating-IP: [63.245.221.34] In-Reply-To: References: From: Eric Rescorla Date: Thu, 17 Apr 2014 16:22:25 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=047d7bb03f60b4ddc004f7455066 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FgSGOinOeXHc3LI60Dlr6ZUNay0 Cc: "" Subject: Re: [TLS] github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:23:14 -0000 --047d7bb03f60b4ddc004f7455066 Content-Type: text/plain; charset=ISO-8859-1 And now we have an -01. The only change here is a correction to the copyright notice to reflect the fact that there is material which predates the IETF revised rights policy in RFC 5378. New URL: http://tools.ietf.org/html/draft-ietf-tls-tls13-01 -Ekr On Thu, Apr 17, 2014 at 2:39 PM, Eric Rescorla wrote: > > > On Thu, Apr 17, 2014 at 2:28 PM, Sean Turner wrote: > >> WG Members, >> >> Going forward we will be following the successful example of the >> HTTPbis WG and using github to organize our work. >> >> This means: >> >> - The editor will maintain the editor's draft on github in the >> following repository: https://github.com/tlswg/tls13-spec >> >> - Technical changes can be submitted as pull requests and are subject >> to the usual WG consensus process before being merged. No >> substantive technical discussion should occur in github. If you >> cannot submit a pull request, you can send text directly to the list >> but pull requests are preferred for tracking purposes. The editor >> may also be tasked by the WG to make technical changes directly, >> based on WG consensus. >> >> - Editorial changes should be submitted as pull requests and the >> editor may just merge them directly and/or commit editorial changes >> directly as needed. >> >> - If you believe a change has been committed inappropriately, either >> note this on the list/chairs/editor or if the change is minor, >> submit your own pull request to back it out. >> >> - Revisions will be submitted as internet drafts regularly, and be >> tagged (see process in [1]). We still maintain a manual change log >> for major issues, but the commit history is used as a more detailed >> record. >> >> - The git issue tracker will be used to manage outstanding issues, >> but as above, any substantive discussion should happen on-list. >> >> We also will use github for meeting arrangements, agendas and >> minutes. These will also be posted to the IETF datatracker as >> usual. >> >> The editor has posted a first RFC 5246 bis draft at the following >> location: >> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.txt >> This draft should not contain any intentional substantive changes >> and is just a baseline for future change tracking. I've checked it, >> you should too. >> > > This has now been submitted as an I-D. At: > http://tools.ietf.org/html/draft-ietf-tls-tls13-00 > > Please ignore the notification for rfc5246-bis. I fumble-fingered the draft > name. The correct draft name is: draft-ietf-tls-tls13-00 > > As Sean said, there should be no substantive changes between this > draft and RFC 5246. If you find any, please let me know and/or submit > a git pull request and I will correct. > > -Ekr > > spt for the chairs >> >> [1] https://github.com/tlswg/tls13-spec/blob/master/SUBMITTING.md >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --047d7bb03f60b4ddc004f7455066 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And now we have an -01. The only change here is a correcti= on to 
the copyright notice to reflect the fact that there is mate= rial which
predates the IETF revised rights policy in RFC 5378.

New URL:

-Ekr



On Thu, Apr 17, 2014 at 2:39 PM, Eric Re= scorla <ekr@rtfm.com> wrote:


On Thu, Apr 17, 2014 at 2:28 PM, Sean Turner <TurnerS@ieca.co= m> wrote:
WG Members,

Going forward we will be following the successful example of the
HTTPbis WG and using github to organize our work.

This means:

- The editor will maintain the editor's draft on github in the
  following repository: https://github.com/tlswg/tls13-spec

- Technical changes can be submitted as pull requests and are subject
  to the usual WG consensus process before being merged. No
  substantive technical discussion should occur in github. If you
  cannot submit a pull request, you can send text directly to the list=
  but pull requests are preferred for tracking purposes. The editor   may also be tasked by the WG to make technical changes directly,
  based on WG consensus.

- Editorial changes should be submitted as pull requests and the
  editor may just merge them directly and/or commit editorial changes<= br>   directly as needed.

- If you believe a change has been committed inappropriately, either
  note this on the list/chairs/editor or if the change is minor,
  submit your own pull request to back it out.

- Revisions will be submitted as internet drafts regularly, and be
  tagged (see process in [1]).  We still maintain a manual change= log
  for major issues, but the commit history is used as a more detailed<= br>   record.

- The git issue tracker will be used to manage outstanding issues,
  but as above, any substantive discussion should happen on-list.

We also will use github for meeting arrangements, agendas and
minutes.  These will also be posted to the IETF datatracker as
usual.

The editor has posted a first RFC 5246 bis draft at the following
location:
https://github.com/tlswg/tls13-spec/blob/master= /draft-ietf-tls-tls13.txt
This draft should not contain any intentional substantive changes
and is just a baseline for future change tracking.  I’ve checked= it,
you should too.

This has no= w been submitted as an I-D. At:

Please ignore the notification for rfc5246-bis. I fumbl= e-fingered the draft
name. The correct draft name is:  draft= -ietf-tls-tls13-00

As Sean said, there should be n= o substantive changes between this
draft and RFC 5246. If you find any, please let me know and/or submit<= /div>
a git pull request and I will correct.

-= Ekr

spt for the chairs

[1] https://github.com/tlswg/tls13-spec/blob/master/SUBMIT= TING.md
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--047d7bb03f60b4ddc004f7455066-- From nobody Thu Apr 17 16:33:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A921A0203 for ; Thu, 17 Apr 2014 16:33:18 -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 V3koh9kAA7IX for ; Thu, 17 Apr 2014 16:33:17 -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 E45EF1A01CF for ; Thu, 17 Apr 2014 16:33:16 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n12so1028633wgh.0 for ; Thu, 17 Apr 2014 16:33:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8ubhzz5T+5zOXGST/2o4enreVF1hP0wqFjAXPkFEEoI=; b=A+ZvlR+FY30+TiVV8yMoISC8k1UqoiV/1SwmreJ7a8MuRjhOmGFBUtCgntDx9fPLQZ B/MwtnOgxUR19jqwmmPHvyBUuSGxHoZBdeCEG2qcWJR6vONZix/hsV1fL0SC1u0kSPUJ IySlcInYYojS1DZDArg0DBLiHq6cbcrbdT93C6XlxsTA+c1OUSZ2GE1431ykswoBqx00 +D5mFzV1NbxVvRr6vOjD1goaiErt5Yu8wRzm0zcE2nChSRXJNTh4PYTX7Wl1YxDDh+76 a/DtSmlN6YmouJeIrqm0k6CbgrQzXxQLMgRfrdGM9AqsHcLuSUNl+rWH3B1RjU7tLOwb C1iw== X-Gm-Message-State: ALoCoQm3FXXcbfdmfUl1DmLcXucfqZnFALZosiij0ww+iXjPJ7zwcmL/FxZ6lzssJ3Va0StlwFMs MIME-Version: 1.0 X-Received: by 10.194.133.1 with SMTP id oy1mr38950wjb.87.1397777592593; Thu, 17 Apr 2014 16:33:12 -0700 (PDT) Received: by 10.216.45.146 with HTTP; Thu, 17 Apr 2014 16:33:12 -0700 (PDT) X-Originating-IP: [50.204.254.254] In-Reply-To: References: Date: Thu, 17 Apr 2014 16:33:12 -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/Lwph9SJIPeq_pLRUEPhb1yjh0pM Cc: "" Subject: Re: [TLS] Concluding the TLS process thread X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Apr 2014 23:33:19 -0000 On Thu, Apr 17, 2014 at 2:26 PM, Sean Turner wrote: > > Further discussion of changes to or reinterpretation of the charter are > now out out of scope for this working group and should be taken off this > mailing list. I'll leave it at this: It's disappointing the chairs have chosen a "chairs do whatever they want" process rather than a process based on WG consensus. Trevor From nobody Thu Apr 17 16:36: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 3E2F61A0201 for ; Thu, 17 Apr 2014 16:36:14 -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 UrrVH0w-QXr2 for ; Thu, 17 Apr 2014 16:36:13 -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 B865C1A01C3 for ; Thu, 17 Apr 2014 16:36:12 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so144012wib.17 for ; Thu, 17 Apr 2014 16:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ahNer6uQzfSvqFpwyM5QL3qiNFEMAOBr0Uf2syxbH3Y=; b=S61KE2qWkvCMhJiq7SGySXnkb+xSPxPU0cHyL1xLhpohw6wE7UbfiqsL+E1Ky+vfdu H+fDXMRbMGm2SH826uj6Mb3zm7VFZ4G6IbgUKls6u54g6H5wAAd3JMJMJyM8s/ynzuvv qX9g3/29vVMBGL6d32064l8UsDnIEFprmz0h2NmvuqQKOl4SLX7vL+UXybdkFQJcpPrw VxJQg7InBZbXqEqCmkkRKQeY6fkyi0x4IfCyy6Q6kVzr6IEZGxlVpj9yTV+31POJonQM 1GcC+GJROe/xXczq7VJnieZTArFPDDAXeVeJ+htYzUKfDYou459cxhfRr3O7V1qpT0ql I9jg== MIME-Version: 1.0 X-Received: by 10.194.204.199 with SMTP id la7mr14070276wjc.4.1397777768595; Thu, 17 Apr 2014 16:36:08 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Thu, 17 Apr 2014 16:36:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 16:36:08 -0700 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/33QzJAs34_VvFF649HPQ5S3JVt0 Cc: "" Subject: Re: [TLS] github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:36:14 -0000 On 17 April 2014 14:28, Sean Turner wrote: > Going forward we will be following the successful example of the > HTTPbis WG and using github to organize our work. To demonstrate some more concrete examples of this, I've created issues to track some of what we've been discussing, as well as some trivial pull requests for a few of the RFC 5246 errata. I've found this to be the most efficient way to work in HTTP/2, especially the bit where everyone helps fix stupid typos. From nobody Thu Apr 17 18:03:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6391A0176 for ; Thu, 17 Apr 2014 18:03:36 -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 ZdxocpuWGeu5 for ; Thu, 17 Apr 2014 18:03:35 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) by ietfa.amsl.com (Postfix) with ESMTP id 827311A0134 for ; Thu, 17 Apr 2014 18:03:35 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 131so962814ykp.26 for ; Thu, 17 Apr 2014 18:03: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=vXHsD1iCf9MiZpOTscbeOUDHoUaGUoLDTutNbes5RAQ=; b=dfNvfoN6EnBOXzgpqu/zU935h6jxuxjTXlr2uv440eXJEw9/ifCeyW9qPqwVhLjjDM BrAklShzCXSkqmfiuXs/GWnCzkj1500fp9dFYDKMYt3ndmlkjXJza8NiZDuIIl6DtO3K 8e791N+tHGSjr0yoBKiHfUiqakB0Zibch01L30NMeGnlqzXPHztEETSA3oDJctYjJfGr C6d6bRT7nvJ4OfmyOkoFrT3MwWsOwAtUYdGF0H4KW9XiW80qHWNAn1pIWBuAC9lqeMUT //l7YhZKkStvn7b68ZJ3gyucrjYXZhgN7Kx//FPbxAfJ5EK67p+pk6jSW88K6q4xypyl q+bA== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr26843093yhj.63.1397783011614; Thu, 17 Apr 2014 18:03:31 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 17 Apr 2014 18:03:31 -0700 (PDT) Date: Thu, 17 Apr 2014 18:03: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/IbuCTRdr0RiMicENXhy7tKAls7c Subject: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 01:03:37 -0000 Dear all, Recently Michael St. Thomas pointed out the PRF is painful in hardware. It's painful in software if you do monadic tricks to ensure keys are only encrypted with and never sent over the wire or process isolation to ensure that they are never read. So I'll make a radical proposal, and it will get pared down to something acceptable over time. So I propose the following changes: Client IV starts at 0 and proceeds through the even numbers, Server IV from 1 and proceeds through the odd numbers. Finished dies. Instead we hash the entire handshake, certs and all into the master secret. This has the side effect of making life for cryptographers a lot nicer. I've not figured out resumption quite yet: maybe this is a problem there. I've also probably missed some other outputs that need munging or replacements. This way the PRF is only used to generate keys, so it can be marked at such. There aren't any security implications: we've replaced finished with the master secret hashing, so the only way to get two identical master secrets is from identical exchanges. Sincerely, Watson Ladd From nobody Thu Apr 17 18:10: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 0FF191A017C for ; Thu, 17 Apr 2014 18:10:34 -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 ClDj1F_1Kiow for ; Thu, 17 Apr 2014 18:10:30 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 018DE1A01E8 for ; Thu, 17 Apr 2014 18:10:29 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 644CE2AC064 for ; Thu, 17 Apr 2014 18:10:26 -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=pWuTsqGM+QeJUXSX3ZWW wFAsarw=; b=PNS4wS5tsOkJhgyFh7BLnQdO9S8xfjLUZgOt7K3dcfR7SmzOhCKo 5OkZktVQ/9XJ7p2ZqI6SjC0GKEnDViUG3fxh37VHzcmJgEnj/6gWuFFxz4WRgSEu F7TnpFRNtKts7OPHyE2DdvSoZg9YxJWbaWqeYTZnw63oMm6i6mv+wWs= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 14A7D2AC059 for ; Thu, 17 Apr 2014 18:10:25 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t60so1108697wes.33 for ; Thu, 17 Apr 2014 18:10:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr330052wib.42.1397783424778; Thu, 17 Apr 2014 18:10:24 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 18:10:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 20:10:24 -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/F6e6UT8kV8orwzLBnIfwD-7nFUg Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 01:10:34 -0000 This would require updating the tls-unique channel binding (which the resumption bug doesn't: just fix resumption). Also, are you proposing to have no message which demonstrates possession of the shared master secret immediately after being able to compute it? Nico -- From nobody Thu Apr 17 18:36: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 EEBD51A023D for ; Thu, 17 Apr 2014 18:36:00 -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 leqqCzGodWqU for ; Thu, 17 Apr 2014 18:35:56 -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 E1EEF1A021F for ; Thu, 17 Apr 2014 18:35:55 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so1053518yho.18 for ; Thu, 17 Apr 2014 18:35: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; bh=LFRQU2NQiETo/GV+Y2AeyR76bMztsQ5zV9ldXYgdN08=; b=XMcCxEe4AUl4pwWEvqyrJSo5+jYByoRahUNb/g2zzziKrJd7uiKHSquYk996JcN89S JOTR1xCQbnA6bk2qCTVMxyBLomCz3KLsl7KcbkmSsNFpEav7sx8oDVVVAg1kWGikqkEf dYDuZuKsHQ3u4+dbQnDOFjWvsH62wrTG+acCaacrgVsViV5NpnRg/sCv9ATCKRC+DC4m Iti5Y0WLJ6Vy5wWverb5G8k9EHdxgxylfsTGvZNxDmXe7Y28/mWJFDJE4cXJnTa14lw1 1dXkbxFrJ45cbqrXLe9jcKRwY0/FtjvCgBE1gzttFt1pVxQ12oQOWRdTEMEmA7XMPZBt K1lQ== MIME-Version: 1.0 X-Received: by 10.236.76.105 with SMTP id a69mr27701195yhe.8.1397784951543; Thu, 17 Apr 2014 18:35:51 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 17 Apr 2014 18:35:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 18:35:51 -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/jK15i5Z146TxuFDGXSz_4_JwdKs Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 01:36:01 -0000 On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams wrote: > This would require updating the tls-unique channel binding (which the > resumption bug doesn't: just fix resumption). You have a master key: do another extraction from it. I don't see this as unsolvable. > > Also, are you proposing to have no message which demonstrates > possession of the shared master secret immediately after being able to > compute it? Yes. Key confirmations are useful in extremely limited circumstances. Furthermore, this fixes the issue with 1-RTT proposals where a modified handshake might not get detected until data was sent on a downgraded channel. 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 Thu Apr 17 19:13: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 E04831A0254 for ; Thu, 17 Apr 2014 19:13: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 dmRv5WAEhE18 for ; Thu, 17 Apr 2014 19:13:48 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 694001A01F3 for ; Thu, 17 Apr 2014 19:13:48 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so232456wiv.13 for ; Thu, 17 Apr 2014 19:13: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:from:date :message-id:subject:to:cc:content-type; bh=wnNLE30u/9RTHgEJskUx1Mq618BxZaSJxmeCTrxad5c=; b=M8IpIFvjN+gg7EsM7547BXt0H91cs5x0/sNJRouXb6CpHnq2SWAIktRjDWw0EPZtht xLKx2LDx7MDkESgauBX6RjZFTD9uEwwZrMoInTskSGty815t3DSADBEjtWVfrc3nQY4S ARi99fWZV9CMervMrQf2hvLKTu+U6QCj00EXHiXeyKhilSJ+lxCi3J98VWQwH2hcroYE 2gcticDIgT9ftZ7IMgFTVAgUuUQmTANl0KaR9wbLyHM+nyzzaJrb/AScyf+rbex7liPu y8yZd55D8gdSWuZzQDsiHShzr0upYGdP0G9BCY/1RHdtJ6W6bpoSvcnEB1npFvHT++gX bq4A== X-Gm-Message-State: ALoCoQkcbFj8etiqbi3ZBQnK1DbGW5Wnw9lqx/s2E+s5/sD6iuRZcPmbLVH6yaCdCPZqXC1bYWlq X-Received: by 10.180.94.226 with SMTP id df2mr459081wib.1.1397787224254; Thu, 17 Apr 2014 19:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Thu, 17 Apr 2014 19:13:04 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Thu, 17 Apr 2014 19:13:04 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d04447e61f94abb04f747b24b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/acHMyWaSLr1C7fI5wycL-za2abc Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 02:13:52 -0000 --f46d04447e61f94abb04f747b24b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 6:03 PM, Watson Ladd wrote: > Dear all, > > Recently Michael St. Thomas pointed out the PRF is painful in > hardware. It's painful in software if you do monadic tricks to ensure > keys are only encrypted with and never sent over the wire or process > isolation to ensure that they are never read. So I'll make a radical > proposal, and it will get pared down to something acceptable over > time. > Interesting suggestion. I have some questions/thoughts below. > So I propose the following changes: Client IV starts at 0 and proceeds > through the even numbers, Server IV from 1 and proceeds through the > odd numbers. > Can you elaborate more on what you have in mind here? In the current GCM mode, the per-packet nonce is formed from a fixed "IV" generated by the PRF (as described by Mike) and a per-packet value which is carried in the packet. What structure were you thinking of here? Also, what's the advantage of partitioning the IV space like this if you use separate keys in each direction? > Finished dies. Instead we hash the entire handshake, certs and all > into the master secret. This has the side effect of making life for > cryptographers a lot nicer. I've not figured out resumption quite yet: > maybe this is a problem there. I've also probably missed some other > outputs that need munging or replacements. > How would this interact with wanting to encrypt parts of the handshake, e.g., the client's certificate? I.e., we need to generate keys which we can use to encrypt the certificate, but these must be generated prior to the certificate being transmitted. Were you thinking we would have two sets of keys? We wouldn't hash them into the keys? Something else? -Ekr This way the PRF is only used to generate keys, so it can be marked at > such. There aren't any security implications: we've replaced finished > with the master secret hashing, so the only way to get two identical > master secrets is from identical exchanges. > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04447e61f94abb04f747b24b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 17, 2014 at 6:03 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
Dear all,

Recently Michael St. Thomas pointed out the PRF is painful in
hardware. It's painful in software if you do monadic tricks to ensure keys are only encrypted with and never sent over the wire or process
isolation to ensure that they are never read. So I'll make a radical proposal, and it will get pared down to something acceptable over
time.

Interesting suggestion. I have so= me questions/thoughts below.

=A0
So I propose the following changes: Client IV starts at 0 and proceeds
through the even numbers, Server IV from 1 and proceeds through the
odd numbers.

Can you elaborate more on = what you have in mind here? In the current
GCM mode, the per-pack= et nonce is formed from a fixed "IV" generated
by the P= RF (as described by Mike) and a per-packet value which is
carried in the packet. What structure were you thinking of here?
=

Also, what's the advantage of partitioning the IV s= pace like this if you
use separate keys in each direction?

=A0
Finished dies. Instead we hash the entire handshake, certs and all
into the master secret. This has the side effect of making life for
cryptographers a lot nicer. I've not figured out resumption quite yet:<= br> maybe this is a problem there. I've also probably missed some other
outputs that need munging or replacements.

<= div>How would this interact with wanting to encrypt parts of the handshake,=
e.g., the client's certificate? I.e., we need to generate ke= ys which we
can use to encrypt the certificate, but these must be generated prior = to
the certificate being transmitted. Were you thinking we would = have two
sets of keys? We wouldn't hash them into the keys? S= omething else?

-Ekr



=
This way the PRF is only used to generate keys, so it can be marked at
such. There aren't any security implications: we've replaced finish= ed
with the master secret hashing, so the only way to get two identical
master secrets is from identical exchanges.

Sincerely,
Watson Ladd

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

--f46d04447e61f94abb04f747b24b-- From nobody Thu Apr 17 19:22: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 D87491A0176 for ; Thu, 17 Apr 2014 19:22:39 -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 uszFHlu3P3dO for ; Thu, 17 Apr 2014 19:22:35 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 10E9E1A00BE for ; Thu, 17 Apr 2014 19:22:35 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.32.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1C597509B5; Thu, 17 Apr 2014 22:22:28 -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: <534DD8A5.8050202@pobox.com> Date: Fri, 18 Apr 2014 12:24:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53456D1B.1010804@alum.mit.edu> <53459638.50309@alum.mit.edu> <53459E6B.4030900@alum.mit.edu> <5c4a4616b1d34efbb85643d1f26e5410@BL2PR03MB419.namprd03.prod.outlook.com> <719f0ee665324b929a0da56e127588fe@BL2PR03MB419.namprd03.prod.outlook.com> <534C75D2.3010308@pobox.com> <3276489C-6843-4C01-9E0F-0FD98EB5C1A9@mnot.net> <534C850B.1030505@pobox.com> <534D8157.5070200@pobox.com> <534DB00F.5050105@pobox.com> <534DD8A5.8050202@pobox.com> To: Michael D'Errico X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HjUFQL-6JAKLMp_rTn_mpJauQbQ Cc: TLS Mailing List Subject: Re: [TLS] Questions about ALPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 02:22:40 -0000 On 16 Apr 2014, at 11:11 am, Michael D'Errico = wrote: > Martin Thomson wrote: >> On 15 April 2014 15:17, Michael D'Errico wrote: >>> If you foresee only ever defining "h2" (meaning secure HTTP2 over = TLS) >>> and "h2c" (meaning unsecured HTTP2), then why even mention TCP at = all? >> I have no prescient abilities. We do know that TCP is what HTTP/2 = uses though. >=20 > What I'm trying to understand is the need to mention TCP at all since > there is nothing about HTTP (that I'm aware of) which requires TCP > specifically, other than its guarantees of reliability and in-order > delivery, a.k.a. a stream. >=20 > Can't we just have "HTTP/2 with TLS" and "HTTP/2 without TLS" and know > that the underlying transport is a stream in both cases (possibly TCP, > possibly something else)? This is true in the abstract, but concretely, when I want to connect to = , I need to know a number of things, including: * What version of HTTP to use * What underlying transport it's bound to (TCP, SCTP, QUIC, whatever) * Whether to use TLS or not (if using TLS for http:// URIs, a.k.a. = "opportunistic encryption" takes off) Previously, these were all obvious, because there weren't any = backwards-incompatible versions of HTTP, the only transport used was = TCP, and TLS was indicated by HTTPS URIs.=20 We're pretty quickly moving into a world where none of these assumptions = hold true, so we need a mechanism to denote the specifics to the client. = HTTPbis has chosen to use the ALPN identifier to do this, because we = need a way of talking about the protocol *stack* in use not only in TLS, = but also in "vanilla" HTTP (see the Alternative Services draft), and = possibly even in DNS in the future. Cheers, -- Mark Nottingham http://www.mnot.net/ From nobody Thu Apr 17 19:23: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 697BE1A00BE for ; Thu, 17 Apr 2014 19:23:44 -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 H_d49OYHmcGm for ; Thu, 17 Apr 2014 19:23:40 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8684D1A00B4 for ; Thu, 17 Apr 2014 19:23:40 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id E66B42F4059 for ; Thu, 17 Apr 2014 19:23:36 -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=Kek4c8D9FYUyp7/o5oND ch7c1ag=; b=daHiSqchOtNEfeLuCBi4KAmRsdOWuEis33H6syovr0hQqSBBAQcV yQS4e4+bk3pZsw9bCOndr+gSgfGuNGikBE/meZXe3S7EMUFoSW5T2d1jPiJrH6lH AEDaVIB7FtW0uLWiHfOX6Xqz/cpUqH3PRs2RCkIvE5eNgxKtUBzLHLI= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 9A5632F4057 for ; Thu, 17 Apr 2014 19:23:36 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id z2so244186wiv.0 for ; Thu, 17 Apr 2014 19:23:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr480849wic.5.1397787815345; Thu, 17 Apr 2014 19:23:35 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 19:23:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 21:23:35 -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/pEF-leRsKw01SNs0LLdDiFWdOKw Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 02:23:44 -0000 On Thu, Apr 17, 2014 at 8:35 PM, Watson Ladd wrote: > On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams wrote: >> This would require updating the tls-unique channel binding (which the >> resumption bug doesn't: just fix resumption). > > You have a master key: do another extraction from it. I don't see this > as unsolvable. I was pointing out a fact. Clearly it's solvable. >> Also, are you proposing to have no message which demonstrates >> possession of the shared master secret immediately after being able to >> compute it? > > Yes. Key confirmations are useful in extremely limited circumstances. Are key confirmations cargo cult? It depends: If one is doing channel binding then a channel binding confirmation -which might look much the same as key confirmation- is needed. The reason is that the point of CB is to leave encryption to the lower-layer channel, but only if there was no MITM there. If one is not doing channel binding then I believe no key confirmation is needed. The Kerberos AP exchange is a clear case of this. When no CB is used what does one gain from key confirmation in Kerberos? Nothing, IMO. If you trust your KDC and the cryptosystem then really, who cares if you're feeding ciphertext to a party that lacks the key to decrypt it with? But in the Kerberos GSS mechanism the AP-REP message serves as the channel binding confirmation message, so if one is doing CB then clearly one also wants that AP-REP. > Furthermore, this fixes the issue with 1-RTT proposals where a > modified handshake might not get detected until data was sent on a > downgraded channel. Only by removing the thing that the modification of which would have been detected. The "issue" remains in some sense, or it was never really an issue. Let's focus on whether and when we need key confirmation. Nico -- From nobody Thu Apr 17 20:12: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 846A31A0259 for ; Thu, 17 Apr 2014 20:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ryJrl2BggqN for ; Thu, 17 Apr 2014 20:12:47 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 706EE1A01E8 for ; Thu, 17 Apr 2014 20:12:45 -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=1397790764; x=1429326764; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=LH3REhB3436TVaO2S+E4EkpBLw/4D5WXnW2MP4QO3jE=; b=ee4tYrMjIqeNpz8UlTjSp7arBzqM/nuawegA+TDEmx7b40oMLrZIhMob JhAW586CYZMNbggk4ftOB6DENGrjcImiqZRrg0J7xqiXGm2W3lngRdhf7 8DoUvLjuouJ1quu2JrgUtD97gQujdpy3hOS2WUOAhJjbcXDCRtIsLHRa6 g=; X-IronPort-AV: E=Sophos;i="4.97,882,1389697200"; d="scan'208";a="247904021" 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; 18 Apr 2014 15:12:20 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Fri, 18 Apr 2014 15:12:19 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Deprecating more (DSA?) Thread-Index: Ac9atAHIHHdH7XpiSuW7pc5jUkhiMQ== Date: Fri, 18 Apr 2014 03:12:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC03B67@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/A4X6gQEviEkqQq9gzQw-LCE0cjo Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 03:12:53 -0000 Watson Ladd writes:=0A= =0A= >I would like to note in particular that 3DES has a 64-bit block, which lim= its=0A= >the transferable data to 2^32 blocks, and so as a backup to AES it is=0A= >painful. =0A= =0A= You missed the "theoretically" in there. I realise you can come up with al= l=0A= manner of obscure corner cases where it's an issue, but in practice which= =0A= typical users of TLS (browsers, IM, etc) are going to be affected? In fact= =0A= even for some pathological case where users actually will be moving more th= an=0A= 4GB over TLS, what real, practical impact is there?=0A= =0A= (Note: I know what the theoretical issue is, I'm asking what the real-world= =0A= impact will actually be).=0A= =0A= Peter.=0A= From nobody Thu Apr 17 20:28: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 DDFF81A0269 for ; Thu, 17 Apr 2014 20:28: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 ExC6JvGcYEHd for ; Thu, 17 Apr 2014 20:28:33 -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 514CA1A026A for ; Thu, 17 Apr 2014 20:28:33 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so1056932yks.33 for ; Thu, 17 Apr 2014 20:28: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=e6puccgodS5KaStJHd7WH75fjsZJ2cqDFBnGRvCPfv8=; b=nH/Wsgia92FVRWh/LPklKn4a3w5+ljzLfKsk4s44uPS53BeERp3Oaf4Uyk24QAMndG Jm255d1vPnL6jlbcXpZ5dJD1uPheDeS6vMV9cqLL6RbVDtWc322PE0SZLYAxJXlAGrED nazA/xdPKkk4sFN6DNKRPJYQqkU7zLJwb0S+cFYYP+7b/WWTlAoLzFWoyOq97pPYnCHt rCu71wHO6jWZdpJjN9GYchvvVCLim134XS43QHCMZwFbn4x4EqVXDjzwK/EhHMB2n+JX mLl2rCFSGt+IjpNtUl5PqgNhH6xbvttwrJQ4CEKKQspaOlrvnZetY1IFXfOW8vpUC7LO 3k7A== MIME-Version: 1.0 X-Received: by 10.236.94.197 with SMTP id n45mr27610674yhf.46.1397791709428; Thu, 17 Apr 2014 20:28:29 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 17 Apr 2014 20:28:29 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC03B67@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC03B67@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Thu, 17 Apr 2014 20:28:29 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NS7idnp8sYo4bA4YAQT8wyMcpgc Cc: "" Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 03:28:38 -0000 On Thu, Apr 17, 2014 at 8:12 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>I would like to note in particular that 3DES has a 64-bit block, which limits >>the transferable data to 2^32 blocks, and so as a backup to AES it is >>painful. > > You missed the "theoretically" in there. I realise you can come up with all > manner of obscure corner cases where it's an issue, but in practice which > typical users of TLS (browsers, IM, etc) are going to be affected? In fact > even for some pathological case where users actually will be moving more than > 4GB over TLS, what real, practical impact is there? We can always rekey frequently to solve this, so it is mitigatable. The lack of AEAD with it is also fixable. The issue is that we leak the xor of two plaintext blocks in event of collision of outputs in CBC mode. In CTR mode I would need to do a lot more analysis to come up with the exact impact: you may have quite a few more blocks to play with. I don't feel comfortable ever endorsing a mechanism in TLS that is not theoretically sound. Sincerely, Watson Ladd > > (Note: I know what the theoretical issue is, I'm asking what the real-world > impact will actually be). > > Peter. > > _______________________________________________ > 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 Apr 17 20:38: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 3CFE31A01EE for ; Thu, 17 Apr 2014 20:38: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 AZ4eZ9ZlQQvt for ; Thu, 17 Apr 2014 20:38:17 -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 CEB691A00A5 for ; Thu, 17 Apr 2014 20:38:16 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so1119463yho.25 for ; Thu, 17 Apr 2014 20:38: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=efr/vtQlI1aZ7WtAdu9aIgsvLHIE7ArdiXkW6CiC7D0=; b=eyHUZK2r88hHV8beCOPWMr+4UI+CsqBr5sMNCa/U0YjNr0xB4lNeF72JpV0CxIJdaj LalHxptf1oB4qvI3xziPlxmznnda5dGRHwN3A1WDx9yCTSNOH/0utd6WjLcUr8AFVcDE 4OlQCj5U4zLP2ra/s5gVjhk7kWn9w4vQjhlb0ttR36y7EN+QpCCMXkuGzS+RlcLSgwa0 cSso+1FZyndN3Q28JP6xvXvOCNfb114g4x52hwbMa8xDO6QUnt8YguU/Ki5zbl35IpI9 dimRd0xDMBHTQPOckxZyNFGbID0a5xsgySE6j+XpMv7u8SAhoYQYkBuOUTO5Z+NdM/IB xDfw== MIME-Version: 1.0 X-Received: by 10.236.45.69 with SMTP id o45mr27886225yhb.64.1397792292951; Thu, 17 Apr 2014 20:38:12 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Thu, 17 Apr 2014 20:38:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 20:38:12 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VUd7htsVI39sCB20HEIWRHslC0s Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 03:38:21 -0000 On Thu, Apr 17, 2014 at 7:13 PM, Eric Rescorla wrote: > > > On Thu, Apr 17, 2014 at 6:03 PM, Watson Ladd wrote: >> >> Dear all, >> >> Recently Michael St. Thomas pointed out the PRF is painful in >> hardware. It's painful in software if you do monadic tricks to ensure >> keys are only encrypted with and never sent over the wire or process >> isolation to ensure that they are never read. So I'll make a radical >> proposal, and it will get pared down to something acceptable over >> time. > > > Interesting suggestion. I have some questions/thoughts below. > > >> >> So I propose the following changes: Client IV starts at 0 and proceeds >> through the even numbers, Server IV from 1 and proceeds through the >> odd numbers. > > > Can you elaborate more on what you have in mind here? In the current > GCM mode, the per-packet nonce is formed from a fixed "IV" generated > by the PRF (as described by Mike) and a per-packet value which is > carried in the packet. What structure were you thinking of here? Nonces as incrementing integers. Each side tracks the other's nonce, or you can put them on the wire if you want. > > Also, what's the advantage of partitioning the IV space like this if you > use separate keys in each direction? None. I forgot we did this. > > >> >> Finished dies. Instead we hash the entire handshake, certs and all >> into the master secret. This has the side effect of making life for >> cryptographers a lot nicer. I've not figured out resumption quite yet: >> maybe this is a problem there. I've also probably missed some other >> outputs that need munging or replacements. > > > How would this interact with wanting to encrypt parts of the handshake, > e.g., the client's certificate? I.e., we need to generate keys which we > can use to encrypt the certificate, but these must be generated prior to > the certificate being transmitted. Were you thinking we would have two > sets of keys? We wouldn't hash them into the keys? Something else? So I wasn't thinking in terms of anything more than a 1-RTT handshake. If you want to encrypt portions of the handshake, I would hash the ciphertext in. I wasn't going to reuse anything from the key generation of those keys. Sincerely, Watson Ladd > > -Ekr > > > >> This way the PRF is only used to generate keys, so it can be marked at >> such. There aren't any security implications: we've replaced finished >> with the master secret hashing, so the only way to get two identical >> master secrets is from identical exchanges. >> >> 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 Apr 17 22:59: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 48C751A0150 for ; Thu, 17 Apr 2014 22:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V78NJ4jbzMb for ; Thu, 17 Apr 2014 22:59:43 -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 F40171A00D4 for ; Thu, 17 Apr 2014 22:59:41 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6F9A31045B; Fri, 18 Apr 2014 01:59:37 -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=s69G2TPwETAk M9TOz/J+s2smigU=; b=GU3VDvypklQdcU4LrOPTe3dSi7WGUbRSmOCn59gYiumO f7phuDtR4oPI7uz9lOz5cgQF0okBGeb1bvijsvy+3M9R+be0vhKeCyGHzPF/7gFc WfesNE+gYbXjPQd99gXH0UGhltfNKfNJZT0UtynS+gpMwatHuXZdMokwGxKKf9w= 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=VimKIg TxnKQ3WDJvW1+Wmn9k/tJXDzbQhfkdd+xOzHiJTLcTiAwr/1pbgtiXB0OUjnU8yx aayA8SfdOa8H3ebi3ZTwEZ/0fW1CXB8OiihF6FfLpmsQPkLZ5cd+3ydJOcVebw0R Ej4YhI9m7Ott0QjV8O7onjL9I2150zhKs8kjU= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5FEAD1045A; Fri, 18 Apr 2014 01:59:37 -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 F281910459; Fri, 18 Apr 2014 01:59:35 -0400 (EDT) Message-ID: <5350BF46.7000608@pobox.com> Date: Thu, 17 Apr 2014 22:59:34 -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: 9ECDD418-C6BE-11E3-968C-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FmmcU3lOOsKUE9iLgKAQ6oPwERc Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 05:59:47 -0000 Watson Ladd wrote: > > So I propose the following changes:... > > Finished dies. Instead we hash the entire handshake, certs and all > into the master secret. This has the side effect of making life for > cryptographers a lot nicer. I've not figured out resumption quite yet: > maybe this is a problem there. I've also probably missed some other > outputs that need munging or replacements. > > This way the PRF is only used to generate keys, so it can be marked at > such. There aren't any security implications: we've replaced finished > with the master secret hashing, so the only way to get two identical > master secrets is from identical exchanges. The Finished messages are equivalent to "Can you hear me now?" spoken over the encrypted link, with an affirmative reply in both directions. Without them, you just start talking and hope that the other side can hear you. The only way for a sender to know there's a problem is to receive an alert (which can't be decrypted) and/or a dropped connection. If the other side is also sending application_data, then a failed decryption will indicate a problem. This is a much weaker failure indication than checking the Finished messages, so I'd prefer to keep them. Can you think of an alternate construction for the Finished message that doesn't use the PRF? Mike From nobody Fri Apr 18 04:55: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 6899A1A01CF for ; Fri, 18 Apr 2014 04:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0aQaHl-c4Gr for ; Fri, 18 Apr 2014 04:55:40 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id C7F431A01BB for ; Fri, 18 Apr 2014 04:55:39 -0700 (PDT) Received: from [10.179.112.19] (85-76-87-112-nat.elisa-mobile.fi [85.76.87.112]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id B720A4001B; Fri, 18 Apr 2014 14:55:30 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Fri, 18 Apr 2014 14:55:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <55C3B6DB-D891-4562-86EE-B2DDB9E25FC5@iki.fi> References: To: Sean Turner Archived-At: http://mailarchive.ietf.org/arch/msg/tls/58fC4fxirtQNPa4EEBFC-lbUlnk Cc: "" Subject: Re: [TLS] github X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 11:55:44 -0000 > On 18.4.2014, at 0.28, Sean Turner wrote: >=20 > WG Members, >=20 > Going forward we will be following the successful example of the > HTTPbis WG and using github to organize our work. Big +1 for using git and github here, this brings transparency to a differen= t level. Juho From nobody Fri Apr 18 05:20: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 352861A01BB for ; Fri, 18 Apr 2014 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=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 LgW4Itbcw5yL for ; Fri, 18 Apr 2014 05:19:57 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id 776CA1A01A8 for ; Fri, 18 Apr 2014 05:19:57 -0700 (PDT) Received: from [10.179.112.19] (85-76-87-112-nat.elisa-mobile.fi [85.76.87.112]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 5057F40048; Fri, 18 Apr 2014 15:19:48 +0300 (EEST) Content-Type: multipart/alternative; boundary=Apple-Mail-BBAB4D75-3552-4476-90B7-3D4EBDF0E889 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D167) In-Reply-To: Date: Fri, 18 Apr 2014 15:19:46 +0300 Content-Transfer-Encoding: 7bit Message-Id: <293A3316-9F3A-4C83-9BFC-E3BEC871F1FE@iki.fi> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> <58DDAD35-E8F4-4446-A228-A15F9CDB0D29@iki.fi> To: Alfredo Pironti Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EbUF3gVeprD5Uhj52n0EpBc1qJM Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 12:20:02 -0000 --Apple-Mail-BBAB4D75-3552-4476-90B7-3D4EBDF0E889 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 16.4.2014, at 13.42, Alfredo Pironti wrote: >=20 >> On Wed, Apr 16, 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: >>=20 >> If someone is trying to get funding for TLS 2.0 and cannot get it because= of the consensus in this WG, they should definitely bring it to discussion o= n this mailing list. Otherwise I think the topic is slightly speculative. >=20 > This is not speculative. I work in the academia, and right now I'm refrain= ing to invest my time (let alone funds) into a TLS proposal because, in the a= bsence of a call for proposals, I deem my time is better invested in other a= ctivities. Thanks for coming forward, so I stand corrected that the issue is not specul= ative. > That said, I'll admit that, as long as we have to stick with the current C= lient/ServerHello negotiation and client speaks first, I see much of the pro= gress one can make being incremental, rather than radically new. Let's just hope the discussion keeps going after the TLSv1.3 issue is resolv= ed. The WG had a lot of inactivity between TLSv1.2 and now that could have b= een used better, but it seems that only after several big exploits people ar= e suddenly interested in TLS again. Juho --Apple-Mail-BBAB4D75-3552-4476-90B7-3D4EBDF0E889 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 16.4.2014, at 13.42,= Alfredo Pironti <alfredo.pir= onti@inria.fr> wrote:

On Wed, A= pr 16, 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua <<= a href=3D"mailto:juhovh@iki.fi" target=3D"_blank">juhovh@iki.fi> wrote:

If someone is trying to get funding for TLS 2.0 and cannot get it because of= the consensus in this WG, they should definitely bring it to discussion on t= his mailing list. Otherwise I think the topic is slightly speculative.

This is not speculative. I work in the acad= emia, and right now I'm refraining to invest my time (let alone funds) into a= TLS proposal because, in the absence of a call for proposals, I deem my tim= e is better invested in other activities.
<= /blockquote>

Thanks for coming forward, so I stand correc= ted that the issue is not speculative.

That said, I'll admit that, as long as we have to stick with the current C= lient/ServerHello negotiation and client speaks first, I see much of the pro= gress one can make being incremental, rather than radically new.

Let's just hope the d= iscussion keeps going after the TLSv1.3 issue is resolved. The WG had a lot o= f inactivity between TLSv1.2 and now that could have been used better, but i= t seems that only after several big exploits people are suddenly interested i= n TLS again.


Juho

= --Apple-Mail-BBAB4D75-3552-4476-90B7-3D4EBDF0E889-- From nobody Fri Apr 18 06:01:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D71A011B for ; Fri, 18 Apr 2014 06:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 gaqmTH9gWTjY for ; Fri, 18 Apr 2014 06:01:47 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EDF201A01BB for ; Fri, 18 Apr 2014 06:01:45 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i4so1749758oah.15 for ; Fri, 18 Apr 2014 06:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cgGVvEH9dzrxvULSGy+d8jwbBk8l1vSoN2ePkej1W3w=; b=Hm0l4rpOGP7PaDSsKQgL+hEGrm9QQkhAM9VX6EGXywIU4n4+judiup46Jta5IdLRcw IrWFGGRAv+hyt/9Wg29LFYcIsIhKdTPxbQO8CTaRtgxYHXEsTrF29Kcfu/bRo6WhJX7N GGHNJEw/1dGqbvnUo60nrBJyLxPPO0VWPulDI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cgGVvEH9dzrxvULSGy+d8jwbBk8l1vSoN2ePkej1W3w=; b=K1rm7srMcyJQRorcXrVEr+T2FqCrEurCbDK4EtPO7QiiQtELZykaAQHrDH1OTvD8F9 FqoT1aU2aeTHCmsUFnfnwhxtr6AwcuvGGeTkIuM8ZLUgl/MGB+NR7wrMyh6CnlnMZq+T yerBXsp/y5vMPtqt2XwzNb8QjSjWNMcDh5bwlhBrDsJqSEa10g5n83xsw7oCm7xnoJWR chwjwiRdxcPtGFXtVL6Z7KuJp7A6evQRr7eYPYxoCrqFOrfTkAYS76uV0tEE1HUn11Fo eMlL91jIeeoUvGG+HY738p+R66lOYNiqdzzvDnRIgd9dJvVkgK2ZoyC9PKzIoYgkvBmm UnHQ== X-Gm-Message-State: ALoCoQnDi3hD6waf5grzQaBZOGNnxiXroSVMtRNp4MU+q8Xgg6cBt16aUwA2VipKVG0NrB0N86Sp MIME-Version: 1.0 X-Received: by 10.60.98.139 with SMTP id ei11mr12282117oeb.43.1397826101524; Fri, 18 Apr 2014 06:01:41 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.76.24.168 with HTTP; Fri, 18 Apr 2014 06:01:41 -0700 (PDT) X-Originating-IP: [2.233.215.178] In-Reply-To: <293A3316-9F3A-4C83-9BFC-E3BEC871F1FE@iki.fi> References: <52DE0FAE-1B11-4FB0-B376-EFABA44F3ECD@gmail.com> <1397634943.12647.11.camel@dhcp-2-127.brq.redhat.com> <58DDAD35-E8F4-4446-A228-A15F9CDB0D29@iki.fi> <293A3316-9F3A-4C83-9BFC-E3BEC871F1FE@iki.fi> Date: Fri, 18 Apr 2014 15:01:41 +0200 X-Google-Sender-Auth: I1XeR49bwMgOL8Vz8ICqa8KTOsw Message-ID: From: Alfredo Pironti To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: multipart/alternative; boundary=089e0122991c3d4e4504f750c0b2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qKqlILVavNBDePVHyPjryBS-JBo Cc: "tls@ietf.org" Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 13:01:52 -0000 --089e0122991c3d4e4504f750c0b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 18, 2014 at 2:19 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > > On 16.4.2014, at 13.42, Alfredo Pironti wrote: > > > On Wed, Apr 16, 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > >> >> If someone is trying to get funding for TLS 2.0 and cannot get it becaus= e >> of the consensus in this WG, they should definitely bring it to discussi= on >> on this mailing list. Otherwise I think the topic is slightly speculativ= e. >> > > This is not speculative. I work in the academia, and right now I'm > refraining to invest my time (let alone funds) into a TLS proposal becaus= e, > in the absence of a call for proposals, I deem my time is better invested > in other activities. > > > Thanks for coming forward, so I stand corrected that the issue is not > speculative. > Well, it's just me ;-) > > That said, I'll admit that, as long as we have to stick with the current > Client/ServerHello negotiation and client speaks first, I see much of the > progress one can make being incremental, rather than radically new. > > > Let's just hope the discussion keeps going after the TLSv1.3 issue is > resolved. The WG had a lot of inactivity between TLSv1.2 and now that cou= ld > have been used better, but it seems that only after several big exploits > people are suddenly interested in TLS again. > After all, I do agree with the chairs that progress on TLS is more urgent than meta-discussion (so, sorry chairs for keeping this thread alive! I'll stop now!). And although seeing handshake messages encapsulated in ClientHello extensions does make me feel a bit sick, I acknowledge that, without changing the well-known port for "protocol x over TLS", none of the radical changes I'd like to see can happen. Alfredo > > > Juho > > --089e0122991c3d4e4504f750c0b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 18, 2014 at 2:19 PM, Juho V=C3=A4h=C3=A4-Herttua <juhovh@i= ki.fi> wrote:

<= /div>
On 16.4.2014, at 13.42, Alfredo Pironti <alfredo.pironti@inria.fr> w= rote:

On Wed, Apr 16, = 2014 at 12:09 PM, Juho V=C3=A4h=C3=A4-Herttua <juhovh@iki.fi> wr= ote:

If someone is trying to get funding for TLS 2.0 and cannot get it because o= f the consensus in this WG, they should definitely bring it to discussion o= n this mailing list. Otherwise I think the topic is slightly speculative.

This is not speculative. I work in the aca= demia, and right now I'm refraining to invest my time (let alone funds)= into a TLS proposal because, in the absence of a call for proposals, I dee= m my time is better invested in other activities.

Thanks= for coming forward, so I stand corrected that the issue is not speculative= .

Well, it's just me ;-)
=C2=A0

That said, I'll admit that, as long as = we have to stick with the current Client/ServerHello negotiation and client= speaks first, I see much of the progress one can make being incremental, r= ather than radically new.

Let= 9;s just hope the discussion keeps going after the TLSv1.3 issue is resolve= d. The WG had a lot of inactivity between TLSv1.2 and now that could have b= een used better, but it seems that only after several big exploits people a= re suddenly interested in TLS again.

After all, I do agree with the chair= s that progress on TLS is more urgent than meta-discussion (so, sorry chair= s for keeping this thread alive! I'll stop now!). And although seeing h= andshake messages encapsulated in ClientHello extensions does make me feel = a bit sick, I acknowledge that, without changing the well-known port for &q= uot;protocol x over TLS", none of the radical changes I'd like to = see can happen.

Alfredo
=C2=A0
=

Juho


--089e0122991c3d4e4504f750c0b2-- From nobody Fri Apr 18 07:45: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 98A5B1A01BB for ; Fri, 18 Apr 2014 07:45:04 -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 X2cX02zR_sSH for ; Fri, 18 Apr 2014 07:45:02 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 92BD41A030E for ; Fri, 18 Apr 2014 07:44:59 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so1754137qcz.16 for ; Fri, 18 Apr 2014 07:44:55 -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=BKEFYswUfYMLMwYjhaSd/bysqMIp241d4kFyWR1ieRg=; b=ivrSNJtvUdC2ELWisaAJA2QgffKKqrjJo0Ki+wLytsWcDGgL1ZwVQbJT5PveRO5Fbd zV91PaBBacN/0TGnwHdXJonXy0R7TrCXoLEEdQbr/AZ+RWq7kcSbWHHgtxtcoZom/u20 5qo9DrnW06KSYQEat0GUWUvWHYxyJ40ApEwc8GD59C9Q+hnJkRse//ND1cWFR8k1v8DA cJOuKTIbKtkJJ5sFf5ZmRAK089UWr+PnlnaxPvNJyVkHAxDKnO47N1aDF4wZ8DYEwaCK XY1EhmC6A8pQ5hC83PDPSAn1GZzBYPaZSQQ3zDnDICfFbR9MhLMm+Kj3s5sxyH9R1M+j GSqg== X-Gm-Message-State: ALoCoQnhOCGErB6+ulBlnpjgFRJGJ5TTH0Nf1PqC5G1RBR5HhSYl085Pi76Xbw82iwrUyXNL485v X-Received: by 10.224.13.7 with SMTP id z7mr21297090qaz.4.1397832295466; Fri, 18 Apr 2014 07:44:55 -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 s13sm56011227qag.19.2014.04.18.07.44.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 07:44:55 -0700 (PDT) Message-ID: <53513A6B.8080606@nthpermutation.com> Date: Fri, 18 Apr 2014 10:44:59 -0400 From: Michael StJohns 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: <5350BF46.7000608@pobox.com> In-Reply-To: <5350BF46.7000608@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-jQEF7CkW_bRCV0xuVfxxK76wf8 Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 14:45:04 -0000 Edited and comments in line. On 4/18/2014 1:59 AM, Michael D'Errico wrote: > Watson Ladd wrote: >> >> So I propose the following changes:... >> >> Finished dies. ......... > > This is a much weaker failure indication than checking the Finished > messages, so I'd prefer to keep them. Can you think of an alternate > construction for the Finished message that doesn't use the PRF? The simplest thing here is to use the negotiated PRF algorithm (SecurityParameters.prf_algorithm, not the TLS PRF wrapper around that algorithm) directly, but key it with a different key than the master secret that would also be derived from the pre-master secret. _____________________________________________________ draft-stjohns-tls-tls13-crypto-infra has the complete details on what I'm proposing along with the above. It recommends doing a straight MAC over the handshake data, but I realized last night that that might not (will not?) be possible as you may not (will not?) have the derived key you're going to need for this until later in the processing. You'd have to keep a copy of the negotiation messages around until you acquired the other side's random data (e.g. on the client side until you heard ServerHello). So having some sort of summary function is going to be necessary. We know how to do this for hash-based (e.g. HMAC) MACs (use the underlying hash directly), but would have to define something for a block-cipher (e.g. CMAC) MAC to do the summary function - probably using the CMAC with a zero key. So something like: if MAC is a CMAC then verify_data = MAC (handshake_key, MAC (0, handshake_messages))[0..verify_data_length-1]; else verify_data = MAC (handshake_key, HASH (handshake_messages))[0..verify_data_length-1]; Mike > > Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 18 07:58: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 4E6721A01AF for ; Fri, 18 Apr 2014 07:58: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 gMw2zW_jMLXK for ; Fri, 18 Apr 2014 07:58:21 -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 B63F31A02FB for ; Fri, 18 Apr 2014 07:58:21 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so1523224yho.39 for ; Fri, 18 Apr 2014 07:58: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 :content-type; bh=/Xcsuc6PcLI8qxgDmGTN7+9eV7Rk3e2dM0oi1SFe3uY=; b=AgHRLYoZUWa9yNC3R6Vcz4aJGMvn1+OSe/g2zyX8zsv+m19zTdGQaVFReeR3pL/R05 YlD8Gyw76PvzMKR40SphuBRQqJmEkRtZyu8SzbGVS5tUoXroJjMo1NUYDQHHQ5z+4jLC W1/QbuqkP8HOfxnRvJOU8tSzrLoz86HcTUf+XVsGGe3OgH1xW71iVpG3V/eNzloZ4pLv WS9VvGkuje4pJ36zvib5Ipn4LLVqQGVqyIuJMiCMqxTGYVTyr14LvJ4mX7l+vrkF8LET lcOMCktXZ69/LG7ibkvixhoQxjzbHFltFsbIzo2dM+Nq+1u5c5EZKxazj7JKzWvhBEzo TMBg== MIME-Version: 1.0 X-Received: by 10.236.115.198 with SMTP id e46mr30695252yhh.24.1397833097643; Fri, 18 Apr 2014 07:58:17 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 18 Apr 2014 07:58:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Apr 2014 07:58:17 -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/abuNmEpb2OforJr7OmWnmig4PNk Subject: [TLS] Fwd: Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 14:58:26 -0000 Dear all: I screwed up my reply and Nicos argued it needed to be sent to the list. On Thu, Apr 17, 2014 at 7:23 PM, Nico Williams wrote: > On Thu, Apr 17, 2014 at 8:35 PM, Watson Ladd wrote: >> On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams wrote: >>> This would require updating the tls-unique channel binding (which the >>> resumption bug doesn't: just fix resumption). >> >> You have a master key: do another extraction from it. I don't see this >> as unsolvable. > > I was pointing out a fact. Clearly it's solvable. > >>> Also, are you proposing to have no message which demonstrates >>> possession of the shared master secret immediately after being able to >>> compute it? >> >> Yes. Key confirmations are useful in extremely limited circumstances. > > Are key confirmations cargo cult? It depends: > > If one is doing channel binding then a channel binding confirmation > -which might look much the same as key confirmation- is needed. The > reason is that the point of CB is to leave encryption to the > lower-layer channel, but only if there was no MITM there. Is channel binding really necessary in TLS? I agree key extractors are, but I think the cases where TLS is layered on encrypted channels are pretty rare. Of course if TCPcrypt becomes more common this will change. But I don't see how to do a key confirmation and 1-RTT in the same handshake: we may end up with options, and then have to be very, very careful in hashing the handshake. Chalk this up to me neglecting a usecase. > > If one is not doing channel binding then I believe no key confirmation > is needed. That's correct: You can't get PFS but only weak PFS. However, weak PFS is good enough. No two message protocol can achieve PFS. > > The Kerberos AP exchange is a clear case of this. When no CB is used > what does one gain from key confirmation in Kerberos? Nothing, IMO. > If you trust your KDC and the cryptosystem then really, who cares if > you're feeding ciphertext to a party that lacks the key to decrypt it > with? > > But in the Kerberos GSS mechanism the AP-REP message serves as the > channel binding confirmation message, so if one is doing CB then > clearly one also wants that AP-REP. > >> Furthermore, this fixes the issue with 1-RTT proposals where a >> modified handshake might not get detected until data was sent on a >> downgraded channel. > > Only by removing the thing that the modification of which would have > been detected. The "issue" remains in some sense, or it was never > really an issue. Let's focus on whether and when we need key > confirmation. I was completely confused. You can have C->S: here's my key S->C: here's my exchange and half of the confirmation C->S: confirmation and my data. S->C: response a 1-RTT handshake in which the Finished message actually protects the handshake. Sincerely, Watson Ladd > > Nico > -- -- "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 Apr 18 08: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 8260E1A0236 for ; Fri, 18 Apr 2014 08:05:31 -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 bNg8WsW0-YUM for ; Fri, 18 Apr 2014 08:05:27 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 4645D1A0158 for ; Fri, 18 Apr 2014 08:05:27 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so1796613qcy.14 for ; Fri, 18 Apr 2014 08:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=dlkyEZCy+lMygvdtgf/rVfV97iOw1ubkZmoYnm2Q4Ss=; b=hZh8SUu5fNfH8VUh69i0gxg0W6mhQiSVKJ32IGB1u6BEQpA/kkHNe3EV1l+PrcFYk9 L7gvID50En+JG40slNjR3EAgj7YoWcNcV5J/D/ZfY/GVxGZi2S33HiYxUBk7Wj0LpNYD wOJJeakxpaIcNKS7WV8tvB5A30/69zchI7A+di9G2WbD+7lIOZBFl3Lt7TBE6wGog4vL FChq+Wrm+n3tqCRH2Snpvc1+QT/lHcy5CIEHWqejlRno/p9z4vPBEkSkW6zp8XzAgnDI nT8cigSDBxObjiNFG6mCsaaceyZibKiuX8wuLoOob0XPn2exswJa2rkaM5i7ySH9So32 /WFg== X-Gm-Message-State: ALoCoQmmMXeQbMQKLsK+kEcLioJnl5hefBFp2kRQylX4MONNBD7XmF2LSjJ9CcQUAMGRD1GBrlc8 X-Received: by 10.224.166.210 with SMTP id n18mr21456996qay.6.1397833523032; Fri, 18 Apr 2014 08:05: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 s13sm56101943qag.19.2014.04.18.08.05.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 08:05:22 -0700 (PDT) Message-ID: <53513F36.7050106@nthpermutation.com> Date: Fri, 18 Apr 2014 11:05:26 -0400 From: Michael StJohns 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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nCtcvnxPOJxHPpSdHGEqWi5GU3A Subject: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 15:05:32 -0000 As I was working through the "finished" message email I just sent, I realized something about PRF negotiation. The client, when it sends a ClientHello, doesn't necessarily know which PRF it will be using (assuming there are multiple PRFs defined in the offered cipher suites) until it gets the ServerHello back. I think that means that the client either needs to keep a copy of the ClientHello around (or the data to rebuild it), or needs to keep multiple HASH states - one for each PRF algorithm. It may be useful to add a paragraph on PRF negotiation implications that provides this guidance. Mike From nobody Fri Apr 18 08:15: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 2DD3C1A021C for ; Fri, 18 Apr 2014 08:15: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 Ni07HHCSeyHG for ; Fri, 18 Apr 2014 08:15:52 -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 044D71A022A for ; Fri, 18 Apr 2014 08:15:51 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 10so1473037ykt.18 for ; Fri, 18 Apr 2014 08:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3dLHhZvTZden/DLqqsZP7sZaE60Q7h1gFIV6k6rgqp0=; b=n7ktd/lw0VsKX3z6XjtBlEDvQM8DsFRF1MbmwMS0JuacaSEzgakGmH9B4DnPUsYg7Q tTcMMBn9nwe2FnQdwYDhV/hlggsXm9HVqM17ecImyiQrZjS3G5nGkpAJbKN6XNHEFdjf lXn7hM30ZeOvwvcfyuHGO0RYk2AngVLK7NpoFwk63jU+IF7HTthm44QlvRNATDSZhF6r Bt6WW/f8pnJeWE4DO78367Ki6xWcFTLjasbmN9fmlYBz9QBGwYpBqA4JEg/FYLf+LUfq Z/z6HZ7NejmblRiEdZgclgB9Nq+jmlXyh14AG4sFPLxfrcWn9YbwtdL/vyDAT5mCWGLg gGNA== MIME-Version: 1.0 X-Received: by 10.236.139.70 with SMTP id b46mr2976924yhj.63.1397834147999; Fri, 18 Apr 2014 08:15:47 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 18 Apr 2014 08:15:47 -0700 (PDT) In-Reply-To: <53513A6B.8080606@nthpermutation.com> References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> Date: Fri, 18 Apr 2014 08:15:47 -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/4r61m_WmzogOUt5SwdxRXi8FNcQ Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 15:15:57 -0000 On Fri, Apr 18, 2014 at 7:44 AM, Michael StJohns wrote: > Edited and comments in line. > > > On 4/18/2014 1:59 AM, Michael D'Errico wrote: >> >> Watson Ladd wrote: >>> >>> >>> So I propose the following changes:... >>> >>> Finished dies. ......... >> >> >> This is a much weaker failure indication than checking the Finished >> messages, so I'd prefer to keep them. Can you think of an alternate >> construction for the Finished message that doesn't use the PRF? > > > The simplest thing here is to use the negotiated PRF algorithm > (SecurityParameters.prf_algorithm, not the TLS PRF wrapper around that > algorithm) directly, but key it with a different key than the master secret > that would also be derived from the pre-master secret. This still has the key-dependent encryption issue. If we fix the key generation, the finished messages can be constants. If we need to use finished messages related to keys, then for technical reasons verification gets hard. I'm not an expert on this matter: I only had it explained to me at DIAC '13 by someone. I don't know how the miTLS paper deals with it, or if new methods can avoid it. There are key-confirmation messages that do not have this issue. It does fix your hardware issue though. > > _____________________________________________________ > > draft-stjohns-tls-tls13-crypto-infra has the complete details on what I'm > proposing along with the above. It recommends doing a straight MAC over the > handshake data, but I realized last night that that might not (will not?) be > possible as you may not (will not?) have the derived key you're going to > need for this until later in the processing. You'd have to keep a copy of > the negotiation messages around until you acquired the other side's random > data (e.g. on the client side until you heard ServerHello). So having some > sort of summary function is going to be necessary. We know how to do this > for hash-based (e.g. HMAC) MACs (use the underlying hash directly), but > would have to define something for a block-cipher (e.g. CMAC) MAC to do the > summary function - probably using the CMAC with a zero key. There is a problem here: CMAC is a MAC, not a hash. In particular, I can make collisions in CMAC(0, message) trivially, by letting m_1' be the decryption of m_2+m_2'. 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 Fri Apr 18 08:17:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202671A01EF for ; Fri, 18 Apr 2014 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 slUS5yx67p7S for ; Fri, 18 Apr 2014 08:17:29 -0700 (PDT) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id C71851A01AF for ; Fri, 18 Apr 2014 08:17:28 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP for ; Fri, 18 Apr 2014 17:14:22 +0200 (CEST) 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 2031B1DEB7 for ; Fri, 18 Apr 2014 17:17:23 +0200 (CEST) Message-ID: <535141E7.2000001@streamsec.se> Date: Fri, 18 Apr 2014 17:16:55 +0200 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: <5350BF46.7000608@pobox.com> In-Reply-To: <5350BF46.7000608@pobox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gV4q6rIQCxkA24MbWYjfIj2ggQU Subject: Re: [TLS] Kill Finished (and other tricks for hardware) 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, 18 Apr 2014 15:17:31 -0000 On 2014-04-18 07:59, Michael D'Errico wrote: > This is a much weaker failure indication than checking the Finished > messages, so I'd prefer to keep them. Can you think of an alternate > construction for the Finished message that doesn't use the PRF? Indeed. The client (being the last peer of the connection to send a random handshake message, and being in a position to pick the pre_master_secret) will have a quadratically improved chance of picking a specific master_secret. From nobody Fri Apr 18 08:36: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 178511A03F7 for ; Fri, 18 Apr 2014 08:36:42 -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 LExHpnRBEgTn for ; Fri, 18 Apr 2014 08:36:40 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4F1A041D for ; Fri, 18 Apr 2014 08:36:38 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id DA8171A2623; Fri, 18 Apr 2014 18:36:32 +0300 (EEST) Date: Fri, 18 Apr 2014 18:36:31 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140418153631.GA29018@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/J7dbnhCE_Ddzk4hVj6Oynyml4B4 Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 15:36:42 -0000 On Fri, Apr 18, 2014 at 07:58:17AM -0700, Watson Ladd wrote: > > Is channel binding really necessary in TLS? I agree key extractors > are, but I think the cases where TLS is layered on encrypted channels > are pretty rare. Of course if TCPcrypt becomes more common this will > change. But I don't see how to do a key confirmation and 1-RTT in the > same handshake: we may end up with options, and then have to be very, > very careful in hashing the handshake. Chalk this up to me neglecting > a usecase. AFAIK, This isn't about binding TLS to something underneath, but about binding something over TLS into the TLS. Naively, one would expect signing a value from TLS-extractor to provode channel binding. Currently this does not hold because: - Non-FS key exchanges. - FS key exchanges not binding DH public keys into master secret (allows MITM to play games resulting same MS on both sides). And yes, if there is TCPCrypt running, that's whole another ballgame. -Ilari From nobody Fri Apr 18 09:10: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 887F91A02A4 for ; Fri, 18 Apr 2014 09:10:52 -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 MBcgAwDvWO6D for ; Fri, 18 Apr 2014 09:10:50 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id AA8051A0256 for ; Fri, 18 Apr 2014 09:10:50 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so1809500qcq.23 for ; Fri, 18 Apr 2014 09:10:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HTcWalu2iPMkaoICaDzXpVou4LJudN6HDVCGzOABXcU=; b=b2YtylSXrWm6lJx0K1fCqrsu2Cdex3qItP83qE3GbubieXSKMOFrtcjAEGJpOtk8Uj /sxn6LqkHxg1HLt5Lf2yFshezs5rZOAaqpXSziYFwGJR/JYmzHmSqJ4N4z5+kUfdTRNG rLmz0YY4gUfwx/sxWD65T4G16bm+RWDWZkaPV3sLPEFvYiA0nqY6r/vE/DHMhETkN2+3 IDM73SZovY31aSmFKXBeknZ2yG1xz6rYZg5FDpcM+HzTgITW2XJleh8/8EEUI7WrBo1A 339wDcbcL5ytCiPxwNuWdMSVxdysn7TkTYsGTIXgmA2GBBSikEkbFuxxQ0w3PF2aLLeI 4OSg== X-Gm-Message-State: ALoCoQkfzdbdYd2dX2TYK6KUBnCeD/4Ta7FXfh4XnV39QTbpPdg7s2LRPq9UdfiqJDv76wkBgaci X-Received: by 10.224.22.65 with SMTP id m1mr3626983qab.103.1397837446533; Fri, 18 Apr 2014 09:10:46 -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 b3sm56403878qae.2.2014.04.18.09.10.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 09:10:45 -0700 (PDT) Message-ID: <53514E89.5000208@nthpermutation.com> Date: Fri, 18 Apr 2014 12:10:49 -0400 From: Michael StJohns 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3HDLvHk9AxSSeDtzTgZSv1Efgbc Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 16:10:52 -0000 On 4/17/2014 9:03 PM, Watson Ladd wrote: > > Finished dies. Instead we hash the entire handshake, certs and all > into the master secret. This has the side effect of making life for > cryptographers a lot nicer. I've not figured out resumption quite yet: > maybe this is a problem there. I've also probably missed some other > outputs that need munging or replacements. > > This way the PRF is only used to generate keys, so it can be marked at > such. There aren't any security implications: we've replaced finished > with the master secret hashing, so the only way to get two identical > master secrets is from identical exchanges. > > Not quite. You missed that IVs are generated using the PRF and that's another problem. My PRF proposal is to change the PRF to a counter based PRF prf_step (i, secret, label, context, total_length) = MAC (secret, i + label + 0x00 + context + total_length); // i and total_length are uint32 big endian prf_data (secret, label, context, total_length) = CONCAT (i = 1 to CEIL(total_length/blocksize), prf_step (i, secret, label, context, total_length))[0..total_length-1]; For deriving keys, you use the above construct and a master secret. For using this for the production of random public data (e.g. IVs), you use a '0' key of the appropriate length. The externalized functions are the KDF function (which passes in a key) and the DRBG (deterministic random bit generator) (which doesn't pass in a key), but the underlying implementation is common. The PRF function is never externalized. The above construct is the same as defined in NIST SP800-108 (no, not dual EC...) and is similar to KDF and DRBG constructs used with X9.63, ECDH etc Mike From nobody Fri Apr 18 09:46: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 B94C81A044A for ; Fri, 18 Apr 2014 09:46:29 -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 pFrUdjtsyS7n for ; Fri, 18 Apr 2014 09:46:25 -0700 (PDT) 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 AB40D1A0444 for ; Fri, 18 Apr 2014 09:46:24 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1754946wes.34 for ; Fri, 18 Apr 2014 09:46:20 -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=WBj7naeEvanUvT60hJ6Ie6TK7ZAl1Uxb8dShYRAWxRo=; b=w3nzFVy4o+dtfxaZGGteXTKb8N2GWDXh6uxthDQfbykqDZDNnW48d1Ywha+wt3oCQc N0lkXn3PYL0sTX56pY7qWxlF6an3gycaAY+1pbk9zUVF/Do29azvtHc5wpb1qaLD0wjZ sWb7pyybDFePduLY9VJHppMQcY2Xi30UQDIXJw10XajikPSNxn+vB7iOD+p3IknniG+0 rYytB+bxbMGPECXQ0rwvggwYLiUITE0Jy4Yp8bB+BnwMjeMsBBXDGGNap69t9X/jmht6 9o1llwKj/Ps54gYTNfKGD26Wr4CqfBC98wPmjJp/Yd5hA0r2q+S0Pg8ic8SuSEHaY7Uc 2/rQ== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr3071557wiy.50.1397839580292; Fri, 18 Apr 2014 09:46:20 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 18 Apr 2014 09:46:20 -0700 (PDT) In-Reply-To: <53513F36.7050106@nthpermutation.com> References: <53513F36.7050106@nthpermutation.com> Date: Fri, 18 Apr 2014 09:46:20 -0700 Message-ID: From: Martin Thomson To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kv5MKwOZFMF2-PV2yF-X4WMQIXY Cc: "tls@ietf.org" Subject: Re: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 16:46:29 -0000 On 18 April 2014 08:05, Michael StJohns wrote: > As I was working through the "finished" message email I just sent, I > realized something about PRF negotiation. The client, when it sends a > ClientHello, doesn't necessarily know which PRF it will be using (assuming > there are multiple PRFs defined in the offered cipher suites) until it gets > the ServerHello back. I think that means that the client either needs to > keep a copy of the ClientHello around (or the data to rebuild it), or needs > to keep multiple HASH states - one for each PRF algorithm. > > It may be useful to add a paragraph on PRF negotiation implications that > provides this guidance. Indeed. There is another way to avoid this problem: don't negotiate the hash function used for the PRF. SHA-256 might be good enough until we next revise the protocol. https://github.com/tlswg/tls13-spec/issues/26 From nobody Fri Apr 18 10:08: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 DD5E11A044A for ; Fri, 18 Apr 2014 10:07:49 -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 GYXGsNx-BmQy for ; Fri, 18 Apr 2014 10:07:44 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id 98F161A01DE for ; Fri, 18 Apr 2014 10:07:44 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so1851773qgf.7 for ; Fri, 18 Apr 2014 10:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1TA0WDVsdwqi2+Olb7H2lr0RkmJlRTFE0ZIZnM0PShs=; b=BSosaYIxso55ZKH8eRMcZQ2rumdDLTbbSYTWSYbzNAgm+oz34YhUzWoeMsd+gCCvap vcL8C/aOimwy+sscmKZ2t/QevIZZQBBISSGUqKEUEBRlBkzbzFFTiBElBginw8joJPh1 IRAWAlkdM48JunnD1f6mzBxsQtk1MwSTu+jhP8exJC4iSa93GpBcfbFfqHsCyodL5x2j KQxM8UHznh9Q6wW61VYH+wFJjCiWQN5pTR1sVQkiw8T/Jgd6EOkq4sH98BRWkF014LMl YWB23RQdWDfLIR4NZZYDOrBwwT12DdolELc2j6gRgB7PUCMjisrk+Y4sWtmwXbx2p/A8 WlwQ== X-Gm-Message-State: ALoCoQnVtPjzvvnz4YqQRMjZuQgTWrI78SCiLEMgpRsqPZ7SjB3nmGH9mzKz4Fh5MUggrOo+1viV X-Received: by 10.140.102.166 with SMTP id w35mr9876126qge.97.1397840860342; Fri, 18 Apr 2014 10:07:40 -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 q62sm10341852qgd.0.2014.04.18.10.07.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 10:07:39 -0700 (PDT) Message-ID: <53515BDF.7010909@nthpermutation.com> Date: Fri, 18 Apr 2014 13:07:43 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson References: <53513F36.7050106@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/6ollmSLneEv4W4uNRu7zp7t4UEs Cc: "tls@ietf.org" Subject: Re: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 17:07:50 -0000 On 4/18/2014 12:46 PM, Martin Thomson wrote: > On 18 April 2014 08:05, Michael StJohns wrote: >> As I was working through the "finished" message email I just sent, I >> realized something about PRF negotiation. The client, when it sends a >> ClientHello, doesn't necessarily know which PRF it will be using (assuming >> there are multiple PRFs defined in the offered cipher suites) until it gets >> the ServerHello back. I think that means that the client either needs to >> keep a copy of the ClientHello around (or the data to rebuild it), or needs >> to keep multiple HASH states - one for each PRF algorithm. >> >> It may be useful to add a paragraph on PRF negotiation implications that >> provides this guidance. > Indeed. > > There is another way to avoid this problem: don't negotiate the hash > function used for the PRF. SHA-256 might be good enough until we next > revise the protocol. > > https://github.com/tlswg/tls13-spec/issues/26 > > But I *really* want to be able to build a cipher suite that only needs AES encrypt.... From nobody Fri Apr 18 11:56: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 64A2E1A043F for ; Fri, 18 Apr 2014 11:56:38 -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 SbNgRpjv-DdV for ; Fri, 18 Apr 2014 11:56:34 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 070BB1A0401 for ; Fri, 18 Apr 2014 11:56:33 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so1708357pbb.22 for ; Fri, 18 Apr 2014 11:56:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UlVrZID5H2nsigpguF3F4p9FMhz0iPeopUr2oNuPAmo=; b=Sy8bAO2n0ma3Wz7GDGK9BskXNglHFTemL7M9qzQ5/QVPGgy6SDX3cUySgJPByH+ee8 7V5EP5R9OwzpD19av43HmFvWkfoNKjcXt9E9xO9SDQ2pcXWHdwGH2q14esDbsnfZdklQ 7PrseMbA3Rr883yUoA+UB5B6kr9pRUrHsVaUYpPvjPzmHMPsHzAv0nnG1AUhHs7BGxok 13wu0IBocWDcjZBA/RzmgjzLkVUaxG4cwnwaEw2cnHt6UPCHjGmU9KY8qfTwWt0J9LK+ Y6aEJz69NGSbKUyeQ3Dfk4mZW7KDTi9O+MOHRfGjIQMnwBegclIYMOlsduM4zIqhvM+G IgpA== X-Gm-Message-State: ALoCoQnpimbRLLlWRRzrjkXO1eTC4bBYPGTcSRC53e3sb+YrEQuAgytPyHABfjZwMAbadNbeQ/t4 X-Received: by 10.68.212.10 with SMTP id ng10mr23593529pbc.95.1397847389300; Fri, 18 Apr 2014 11:56:29 -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 ha11sm61436724pbd.17.2014.04.18.11.56.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Apr 2014 11:56:28 -0700 (PDT) Message-ID: <53517559.1060101@mit.edu> Date: Fri, 18 Apr 2014 11:56:25 -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: Nico Williams , Watson Ladd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6ZKOWCkYgMH-hKYy2h1O0QbfkgQ Cc: "tls@ietf.org" Subject: Re: [TLS] Kill Finished (and other tricks for hardware) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 18:56:38 -0000 On 04/17/2014 07:23 PM, Nico Williams wrote: > On Thu, Apr 17, 2014 at 8:35 PM, Watson Ladd wrote: >> On Thu, Apr 17, 2014 at 6:10 PM, Nico Williams wrote: >>> This would require updating the tls-unique channel binding (which the >>> resumption bug doesn't: just fix resumption). >> >> You have a master key: do another extraction from it. I don't see this >> as unsolvable. > > I was pointing out a fact. Clearly it's solvable. > >>> Also, are you proposing to have no message which demonstrates >>> possession of the shared master secret immediately after being able to >>> compute it? >> >> Yes. Key confirmations are useful in extremely limited circumstances. > > Are key confirmations cargo cult? It depends: > > If one is doing channel binding then a channel binding confirmation > -which might look much the same as key confirmation- is needed. The > reason is that the point of CB is to leave encryption to the > lower-layer channel, but only if there was no MITM there. > > If one is not doing channel binding then I believe no key confirmation > is needed. Playing the devil's advocate: Suppose I'm using client certificates and I have a server that takes some action as soon as an authenticated client connects. Without some kind of key confirmation, this stops being secure. Fixing it may be as simple as having the client send an empty record after the handshake. I don't see this being a problem in the other direction. Without key confirmation, a MITM could trick a client into thinking it connected to the server, and the client wouldn't notice until it sent some data and never gets any response. But even with key confirmation, a MITM can do more or less the same thing, just by severing the connection after the handshake. --Andy From nobody Fri Apr 18 12:10: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 59DB91A0468 for ; Fri, 18 Apr 2014 12:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyHKCSrx3mPo for ; Fri, 18 Apr 2014 12:10:00 -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 0676F1A043F for ; Fri, 18 Apr 2014 12:09:59 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 57AF3110E2; Fri, 18 Apr 2014 15:09:55 -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=VaW70uom/Rlo CADqVlDtics+q/g=; b=tKo7b3ozsJMuaoVtdtoG1aAvymopTHpLAfqoW2rOCRrc +de1EfNoXMzEDLycA0tc2bd1tClKXqOJUb2Q0J2XlFxwJ1JFfsykovE3g7wmD/+0 eYxtJgPPr0xNcAtxYmRXndkbWZRT4tDiM0i4eInne5+1izvuKQWbJVX2bY9LQzY= 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=LWZSnT v0sZQAVpmNbvCe8TyHlEwi3XM5/n0U60hoEJzivFpEMpMZ9r9Ar6oFHeATAmWBJ4 ffc/gMml6QP1CAq8cyzXsmWqsg2HdV+ls3nNsl4LHhFeZ/HcnsMS8sZMqt9ydYR9 NqPgnBZ3wgM9bcJtz1/tpPKpjZMP74DB7phu8= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4CBEE110E1; Fri, 18 Apr 2014 15:09:55 -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 94FD9110E0; Fri, 18 Apr 2014 15:09:53 -0400 (EDT) Message-ID: <53517880.7080801@pobox.com> Date: Fri, 18 Apr 2014 12:09:52 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Watson Ladd References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 05E83D28-C72D-11E3-A80B-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P6QMVIQJBXlvcdX0HSt-81ntsRo Cc: "tls@ietf.org" Subject: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 19:10:04 -0000 Watson Ladd wrote: > If we fix the key generation, the finished messages can be constants. IANAC but using a long-enough "magic number" for Finished seems fine if the handshake hash is moved to the key generator. But how long should that magic number be? Currently we use 12 bytes, but should it be 16 or maybe even 32 bytes (when negotiating 256-bits of security)? Can it be a simple string of zeros? Mike From nobody Fri Apr 18 13:21: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 998451A01D9 for ; Fri, 18 Apr 2014 13:21: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 CFIov8fqelYa for ; Fri, 18 Apr 2014 13:21:12 -0700 (PDT) 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 9E6A41A01F0 for ; Fri, 18 Apr 2014 13:21:10 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so851607wgh.29 for ; Fri, 18 Apr 2014 13:21: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=eaj1U+1QQyBZcIY/m+BYSYIY6fUn3ncqUWd9ZrtZNWM=; b=VKYrN3cJSNwxwvX2U/MqBQsLKe4CeaA1IDQtwOMtvXwhDqI3/eCCtM19uG/8dcXSYm baLJsjBmXj20EUSnhNgHRvIM6K6JMG9xuwOrEezIClQUhHQs4rrNZVNVpsI3hDdwiZJK GbjIs1/xEmPr+hehU3LLmLLRqbikY9fhU3HCcAX5lBylbvr4sdb0rJNYMZShksUgCPCX LZXvkXJACG6P6iM5JNiH99lStxhd4lwEQBpC4L1Gs0ka9/Tds5H+J0uxZzJv/ugOKAnB O1RSjo68K0TWB/H7klJ2mA9TRFONhiTNRqefMRmuZBFcHoyz7mat9m/UR/Sf4Jo7Iegn IF2A== MIME-Version: 1.0 X-Received: by 10.180.188.134 with SMTP id ga6mr3656526wic.58.1397852466083; Fri, 18 Apr 2014 13:21:06 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 18 Apr 2014 13:21:05 -0700 (PDT) In-Reply-To: <53517880.7080801@pobox.com> References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> Date: Fri, 18 Apr 2014 13:21:05 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vmOZUDaB0-AyeCPZQ2Ptjfd5rIQ Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 20:21:18 -0000 On 18 April 2014 12:09, Michael D'Errico wrote: > IANAC but using a long-enough "magic number" for Finished seems fine > if the handshake hash is moved to the key generator. > > But how long should that magic number be? Currently we use 12 bytes, > but should it be 16 or maybe even 32 bytes (when negotiating 256-bits > of security)? Can it be a simple string of zeros? Why would it need to be anything at all? As long as you can identify the message as a Finished unambiguously, that should suffice. HandshakeType is one byte. From nobody Fri Apr 18 13:26: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 079841A01C4 for ; Fri, 18 Apr 2014 13:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Grcd9jq_n_z for ; Fri, 18 Apr 2014 13:26:10 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 605061A002E for ; Fri, 18 Apr 2014 13:26:09 -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 s3IKQ4n2002858; Fri, 18 Apr 2014 13:26:04 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1kavc3awde-6 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Apr 2014 13:26:04 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Fri, 18 Apr 2014 13:26:03 -0700 From: Paul Lambert To: Michael StJohns , Martin Thomson Date: Fri, 18 Apr 2014 13:26:03 -0700 Thread-Topic: [TLS] PRF Negotiation - Finished "gotcha" Thread-Index: Ac9bKMGVXb1KVwwqTpCZPKMltYKMhgAG2GHw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D0197DEF8FAC@SC-VEXCH2.marvell.com> References: <53513F36.7050106@nthpermutation.com> <53515BDF.7010909@nthpermutation.com> In-Reply-To: <53515BDF.7010909@nthpermutation.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-18_01:2014-04-18,2014-04-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404180344 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mmE7_6ON26mOWFQnND79h8AzQI4 Cc: "tls@ietf.org" Subject: Re: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 20:26:12 -0000 ]But I *really* want to be able to build a cipher suite that only needs ]AES encrypt.... +1 Specifically for the data path. SHA-256 is appropriate key management, gene= ration etc.=20 ] ] ]_______________________________________________ ]TLS mailing list ]TLS@ietf.org ]https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 18 13:27: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 AACFD1A01CE for ; Fri, 18 Apr 2014 13:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trp2hCIu5rYD for ; Fri, 18 Apr 2014 13:27:00 -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 135BE1A002E for ; Fri, 18 Apr 2014 13:26:59 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A8E561140E; Fri, 18 Apr 2014 16:26:55 -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=N47EnDQmg0Kw R/lE3KYfGUM7TEc=; b=MnkMV+qV7rcmfGiVHsTUpT64XLuYOPaBgWtWMpfaythk whwG0rG2WjWQGVPZ1hTtOkjiYg0/ejMkKgc40YQjwvpD2tEIKjYr7E8uo235DRO9 Zxub/zBjN7KwjVvlwzmm43BQ+tkdRkT1Y2QeMNvragy/xFHbI+cjExUZSPCZog4= 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=ZKHXWC CgcJp9R9Mru4+iaNQhmndFx6d1qHB/Zp3WIoOgPIEEIBHr1b0iTuJGXjS17U25y1 VbmDXPVABarKB08WHMWHEq5cI93ltgsN0vRHFMIDotBuf3pnVElqdZK+pcBKf+ZI oUq3On3uiHYRNl997RJCO9yhTt2UwTWQVlDdQ= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A1D001140D; Fri, 18 Apr 2014 16:26:55 -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 0958B1140C; Fri, 18 Apr 2014 16:26:53 -0400 (EDT) Message-ID: <53518A8D.4080107@pobox.com> Date: Fri, 18 Apr 2014 13:26:53 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Martin Thomson References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C7F231F8-C737-11E3-BBE1-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_upCW0TYIijd8bwKIFTg2_Orz0c Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 20:27:01 -0000 Martin Thomson wrote: > On 18 April 2014 12:09, Michael D'Errico wrote: >> IANAC but using a long-enough "magic number" for Finished seems fine >> if the handshake hash is moved to the key generator. >> >> But how long should that magic number be? .... > > Why would it need to be anything at all? As long as you can identify > the message as a Finished unambiguously, that should suffice. > HandshakeType is one byte. Oh, I see, as long as you can decrypt the record layer, you know it's working. Mike From nobody Fri Apr 18 13:28: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 3135E1A01F6 for ; Fri, 18 Apr 2014 13:28: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 IPg8ehAeZMwv for ; Fri, 18 Apr 2014 13:28:32 -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 CBD3D1A002E for ; Fri, 18 Apr 2014 13:28:31 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so1880869wes.37 for ; Fri, 18 Apr 2014 13:28: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=4HSDaQotqz5L7P4lUz0s56NmQiRzQmesXqW/VHjvUE4=; b=XPfugQl4hYzpFvwPrkUdslL62Ej9pOExHY8lfpd5EVH1dgRaRbpNd+gnNzWwSShy8H LBDg8DFhyTvTLQt16Sccw3E3GNDq40SeE3ULfq0Aa7WAKSN4D4EtAt9vwwwyC9+Ec3fX yOb05C7rWuy8a++0/+/lih4l7RTO6wMMjctUwSnjQBuLXYcOvV5MN4moK9BPjfc9xvi/ OqLU4/TPgH8c5ckiSAWJKBgeVErErVUoK+kti1uypBf0AkcURWdQtL1/7ib9BE+XZGzY SNySSh+0q7bDOFOscSOS4uwiR3zwIVmcBJV2qSgzBTeEth9lw2/cdttXEp/OWIYbfF1r Tl9Q== MIME-Version: 1.0 X-Received: by 10.180.106.198 with SMTP id gw6mr3741816wib.50.1397852907338; Fri, 18 Apr 2014 13:28:27 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 18 Apr 2014 13:28:27 -0700 (PDT) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D0197DEF8FAC@SC-VEXCH2.marvell.com> References: <53513F36.7050106@nthpermutation.com> <53515BDF.7010909@nthpermutation.com> <7BAC95F5A7E67643AAFB2C31BEE662D0197DEF8FAC@SC-VEXCH2.marvell.com> Date: Fri, 18 Apr 2014 13:28:27 -0700 Message-ID: From: Martin Thomson To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HMqcio7NmAk7lWHRkui9PYu5lFg Cc: "tls@ietf.org" Subject: Re: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 20:28:33 -0000 On 18 April 2014 13:26, Paul Lambert wrote: > Specifically for the data path. SHA-256 is appropriate key management, generation etc. The PRF is only needed for key management, generation, extractors, etc... I think that (perhaps) Mike wants to go one further and be able to ship a stack that doesn't even HAVE SHA-256. From nobody Fri Apr 18 13:29: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 A98FB1A022D for ; Fri, 18 Apr 2014 13:29: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 6eyf3W9aAqVR for ; Fri, 18 Apr 2014 13:29:27 -0700 (PDT) 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 108EA1A02D8 for ; Fri, 18 Apr 2014 13:29:26 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1919440wes.34 for ; Fri, 18 Apr 2014 13:29: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=aClEOX/e+4l5AcXqwACkJU/Z3wqpKf4Bv8ONO08c9Z0=; b=ArSTp1uNX40AIHhOo3Nzr/XsVDMJZbxH1yCeqsAvRF4rWOEiv4+ZJfk+Bn/te26SVs xpfuXFwgC00f2sq9Zy3b8SF84wb9wRH4B7PuFR61s/yyidMu3hk9VFilSLFoMA5Y85vl piLjtk0y5bFxwJytb1CT9eJRqOSH6GYVUonjZ+jHTdFTg6BVCc4V0f/HFLKSBOGd3Mdh LFIPMYvawdFgScyW06Guq8WTx/FOKCQLWJ8qG0TKrTB9a/J/KtG+5eCb90WHKoeFl717 ZWnFIZeEjZjcanURIZCGNlCeK2rfyHQo60h7PcR0YqtpK/2NKm4j/ED9HF+GOQ8o9b+p Z7ig== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr3740060wiy.50.1397852962582; Fri, 18 Apr 2014 13:29:22 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 18 Apr 2014 13:29:22 -0700 (PDT) In-Reply-To: <53518A8D.4080107@pobox.com> References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> <53518A8D.4080107@pobox.com> Date: Fri, 18 Apr 2014 13:29:22 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OgJWw1x10TazsWzmW--Hi5T_cxE Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Apr 2014 20:29:28 -0000 On 18 April 2014 13:26, Michael D'Errico wrote: > Oh, I see, as long as you can decrypt the record layer, you know it's > working. Yep, either that or the record layer is busted :) From nobody Fri Apr 18 21:14: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 BC8641A01F0 for ; Fri, 18 Apr 2014 21:14:09 -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 s86tvDkpdv4F for ; Fri, 18 Apr 2014 21:14:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7472B1A00C2 for ; Fri, 18 Apr 2014 21:14:05 -0700 (PDT) Received: from sjc-vpn6-468.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 15F9322E1F4 for ; Sat, 19 Apr 2014 00:13:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: Date: Fri, 18 Apr 2014 21:15:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SAjlg2as5p6Zj0m2aV_Jk3FfflQ Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 04:14:09 -0000 On Apr 16, 2014, at 5:08 PM, Mark Nottingham wrote: > The IETF isn't set up to do this sort of thing; the best way to get = traction here is to get implementation experience / buy-in. >=20 > Working on TLS 2 at the same time as TLS 1.3 is in active development = is asking for both to fail, IMO. +1 From nobody Fri Apr 18 21:36: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 9A3971A021C for ; Fri, 18 Apr 2014 21:36:22 -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 7P-ZBMJhNXt9 for ; Fri, 18 Apr 2014 21:36:21 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 021C21A00C0 for ; Fri, 18 Apr 2014 21:36:20 -0700 (PDT) Received: from sjc-vpn6-468.cisco.com (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3B11622E1F4 for ; Sat, 19 Apr 2014 00:36:15 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Cullen Jennings In-Reply-To: Date: Fri, 18 Apr 2014 21:37:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30153B8A-3EFE-4747-AD02-C5702E9ADAC5@iii.ca> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <534F09D6.1060308@akr.io> To: "tls@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7TT6GbEBTxy_WPHcFUXHjddURlQ Subject: Re: [TLS] Bakeoffs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 04:36:22 -0000 My apologies for sending this. Since I use a threaded email reader, I = did not see the "Concluding the TLS process thread=94 until after I sent = this.=20 On Apr 18, 2014, at 9:15 PM, Cullen Jennings wrote: >=20 > On Apr 16, 2014, at 5:08 PM, Mark Nottingham wrote: >=20 >> The IETF isn't set up to do this sort of thing; the best way to get = traction here is to get implementation experience / buy-in. >>=20 >> Working on TLS 2 at the same time as TLS 1.3 is in active development = is asking for both to fail, IMO. >=20 > +1 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Fri Apr 18 23:03: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 393151A01E0 for ; Fri, 18 Apr 2014 23:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RzKf4oBSWUN for ; Fri, 18 Apr 2014 23:03:48 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6199A1A01BF for ; Fri, 18 Apr 2014 23:03:48 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id b6so2046273yha.5 for ; Fri, 18 Apr 2014 23:03:44 -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=pbvq41rPf5sNP/F/5jxtOlSXAtHRx9Bsg4YUxqO9O3E=; b=WMeulqkOAQh0gv4UZBsMYABvmgP0LHKEBrcozQkk+k74vpl3QIFI+ClUD2O35ajt68 aHYMZfR1UauD9u+EGmtwMIs/vl5gYYx1i8m/MecJ4Cg5MHjtvxwFUoZL84j7+odcdK1d /hRlRv2BT/iEMU+GswCvyXLkDmLqKyLSF632k3vtwK1lH2KCF38tQAS94uBdByKj1593 l6gkR1ayna5Hdc0etu8BhQ7Ra7a18QupQB5rZyiO8yrb6djuqM+io5p32jKxVsOubrWr tRWcBtfn+HLIUtYCml1N2sYkt9EmTRuHiZo7SLIRT9izCCUKJRP2rcpqirJRDY+phkC0 4Wpg== MIME-Version: 1.0 X-Received: by 10.236.127.68 with SMTP id c44mr35629375yhi.1.1397887424104; Fri, 18 Apr 2014 23:03:44 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 18 Apr 2014 23:03:44 -0700 (PDT) Date: Fri, 18 Apr 2014 23:03:44 -0700 Message-ID: From: Watson Ladd To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IlQLyHGuHxZmnCAbzfzlf2Fyc3g Cc: "tls@ietf.org" Subject: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 06:03:53 -0000 On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen wrote: > Alyssa Rowan writes: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> It looks like RC4 is rapidly heading for the chopping block, with >> basically unanimous consensus. Good. > > Agreed, mod Martin's proposal that I understand to ask for a reasonable > path by which we strongly deprecate RC4 on clients, then after a client > generation ban RC4 on clients and deprecate for servers. I don't think this is the correct path. I think what we should do is have clients and servers both prefer other options (in all TLS versions), then once that change is made, ban it entirely. Deprecation on one side won't affect the other side if there isn't an alternative mandated. (Right now RC4 only servers are keeping RC4 alive). This first step has already happened in the web context on modern browsers. What we need is to make the server side step happen, and then think about removal in the second step. Sadly, our ability to force upgrades is very limited. How long a client generation were you thinking? Because I could see cryptanalysis speeding up: RC4 has been neglected for about 12 years after WEP, but the new techniques of massive brute force coupled with some good idea might bear fruit sooner than expected. 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 Sat Apr 19 06:10: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 71BD21A0201 for ; Sat, 19 Apr 2014 06:10:31 -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 T5zPqyBn_e42 for ; Sat, 19 Apr 2014 06:10:26 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDAE1A01FB for ; Sat, 19 Apr 2014 06:10:25 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id F17F51C2121; Sat, 19 Apr 2014 15:10:19 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id BCC8D1FE0214; Sat, 19 Apr 2014 15:10:19 +0200 (CEST) Date: Sat, 19 Apr 2014 15:10:19 +0200 From: Kurt Roeckx To: Watson Ladd Message-ID: <20140419131019.GA29561@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ot10GOJlxA0SLUcTTh2VOO_1iso Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 13:10:32 -0000 On Fri, Apr 18, 2014 at 11:03:44PM -0700, Watson Ladd wrote: > On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen wrote: > > Alyssa Rowan writes: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> It looks like RC4 is rapidly heading for the chopping block, with > >> basically unanimous consensus. Good. > > > > Agreed, mod Martin's proposal that I understand to ask for a reasonable > > path by which we strongly deprecate RC4 on clients, then after a client > > generation ban RC4 on clients and deprecate for servers. > > I don't think this is the correct path. I think what we should do is > have clients and servers both prefer other options (in all TLS > versions), then once that change is made, ban it entirely. Deprecation > on one side won't affect the other side if there isn't an alternative > mandated. (Right now RC4 only servers are keeping RC4 alive). > > This first step has already happened in the web context on modern > browsers. What we need is to make the server side step happen, and > then think about removal in the second step. > > Sadly, our ability to force upgrades is very limited. And I think publishing an RFC isn't actually really going to help much. Yes, people could use it tell others that it's deprecated, but I think there are already more than enough places that say so that having this RFC isn't really going to make a difference. I do agree that we need to try to get both sides to stop using it, and I wish we could just tell people to stop using it and that they would do so. But I don't see either the server or the client side wanting to break things. It would clearly help if they could say at which point they wouldn't mind breaking things. So I think that for now the best we can do is: - Servers should either stop accepting RC4 or make sure that if the clients supports something better (TLS >= 1.1?) it should not pick RC4. It's my understanding that the client preferences of ciphers should be used but that servers can override that, and that there might be good reasons to do so. For instance to get PFS when talking to Internet Explorer. If they override it, they should make sure not to put RC4 first. Basically, a mondern client should never get RC4. - Clients should not announce support for RC4 in their initial connection attempt, and only fall back to support it when the server says that there are no common ciphers. (I'm not sure if a MITM can fake that response or not.) At some point in time when the clients or servers think that they don't need to support RC4 anymore they should disable it. Kurt From nobody Sat Apr 19 07:27: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 03FB01A0252 for ; Sat, 19 Apr 2014 07:27:55 -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 h9Gfk9K_s-VJ for ; Sat, 19 Apr 2014 07:27:53 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCCA1A0218 for ; Sat, 19 Apr 2014 07:27:51 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id B8336817EE; Sat, 19 Apr 2014 17:27:45 +0300 (EEST) Date: Sat, 19 Apr 2014 17:27:45 +0300 From: Ilari Liusvaara To: Kurt Roeckx Message-ID: <20140419142745.GA412@LK-Perkele-VII> References: <20140419131019.GA29561@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140419131019.GA29561@roeckx.be> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nt5SKfre2XB0Er8gc5vDmXPDjt4 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 14:27:55 -0000 On Sat, Apr 19, 2014 at 03:10:19PM +0200, Kurt Roeckx wrote: > - Clients should not announce support for RC4 in their initial > connection attempt, and only fall back to support it when the > server says that there are no common ciphers. (I'm not sure > if a MITM can fake that response or not.) MITM (or eavesdropper with packet injection capabilities) can fake the response, there is no cryptographic verification. -Ilari From nobody Sat Apr 19 08:55: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 49DA41A001F for ; Sat, 19 Apr 2014 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GGU572x4-dV for ; Sat, 19 Apr 2014 08:55:30 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 592AE1A001E for ; Sat, 19 Apr 2014 08:55:30 -0700 (PDT) Received: from [174.226.64.241] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WbXbu-0000x6-U3; Sat, 19 Apr 2014 11:55:23 -0400 Date: Sat, 19 Apr 2014 08:55:22 -0700 From: Bill Frantz To: Yoav Nir X-Priority: 3 In-Reply-To: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79dfe4a6a1a534755339048d3142935f1c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.226.64.241 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-ZkZRsM78G0gl8IDg354dZYNCio Cc: tls@ietf.org Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 15:55:33 -0000 On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: > Those who won=E2=80=99t use TCP are doomed to re-create it. To get a UDP-= based protocol to replace TCP for=20 > the web you=E2=80=99d need all of reliable delivery through (selective?) = retransmissions, bandwidth=20 > detection, replay protection, a whole lot of things that took the transpo= rt community years to get=20 > right. Yes, there have been many attempts, but there=E2=80=99s a reason T= CP is still the protocol everyone=20 > uses for pretty much any type of bulk transfer. And this is before we eve= n begin to talk about=20 > middleboxes dropping unrecognized UDP services. Absolutely correct. However, one could set up a DTLS session and then initialize the TCP protoc= ol within that session. I don't think anyone has considered this inversion before. It may not be us= eful, but... Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Privacy is dead, get over | Periwinkle (408)356-8506 | it. | 16345 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos, CA 95032 From nobody Sat Apr 19 08: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 D97351A001E for ; Sat, 19 Apr 2014 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB8T5fgDbuOU for ; Sat, 19 Apr 2014 08:55:29 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2437E1A0012 for ; Sat, 19 Apr 2014 08:55:29 -0700 (PDT) Received: from [174.226.64.241] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WbXbv-0000x6-SW; Sat, 19 Apr 2014 11:55:24 -0400 Date: Sat, 19 Apr 2014 08:55:23 -0700 From: Bill Frantz To: Alyssa Rowan X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79dfe4a6a1a5347553d84803bb3e8d5a33350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.226.64.241 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dsKnuubt-hZgTmqmv-FDXTT39o4 Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 15:55:34 -0000 There are two use cases to keep in mind here: There are environments which need authentication and replay=20 protection but can not use secrecy. Amateur radio communications=20 comes to mind where the FCC regulations forbid encoding a=20 message with the intent of obscuring its meaning. Now the risks of having secrecy compromised in the many palaces=20 we want to have it out weigh the advantages of supporting this=20 small part of of the use space, but at least we should think for=20 a moment about the choice. The other use case to always keep in mind is limited performance=20 devices. With the Internet of Things, we will continue to see=20 new 8 bit, and possibly even 4 bit processors as manufactures=20 drive in the direction of the small, low power, and cheap. These=20 devices will be much safer if they have authentication and=20 replay protection. While secrecy is probably not as important,=20 it might also be vital in certain applications of these devices. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Sat Apr 19 09:34: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 09D3F1A0027 for ; Sat, 19 Apr 2014 09:34:07 -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 fkrQBIqyUZ2E for ; Sat, 19 Apr 2014 09:34:05 -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 5415F1A0020 for ; Sat, 19 Apr 2014 09:34:05 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so2490443eei.33 for ; Sat, 19 Apr 2014 09:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gwsvv5w/JdviZkjUjSHeACDlImknaXc1riLuLLzQurI=; b=k+IB71AbrvPlGI7zTT5gi5A+rFJQT3nnQA9t+Zg/OalmCkr7zts5fJUueEVK6LylPr dYX3Eq1pwyJLFTYL5rY8tKe6+tW6Cht1VheNWg0yr7lt/1f5G+jpm7LYQTTu4KHFLh6W 6/82Ny0ze2ZWAyEQTn+VP7x6M3nmH+7nOFPWzNhCcD0s0Rx9vCB3M1cswk1NKXjoerb/ gqJaztp7xPbVxEp06KGm/2wXPG/h/82JekD6NvzF8RFua48zfw+lwPSIYbUlkNInd15u Q3tAMsuhewG9h3rMiSOVSpRJMmdEFfoC2RH8WXe8oAdl+Gj+jTh6BOxhuwlYN/tBKIA5 7YmA== X-Received: by 10.14.110.199 with SMTP id u47mr3001648eeg.74.1397925240423; Sat, 19 Apr 2014 09:34:00 -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 48sm86938873eei.24.2014.04.19.09.33.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 09:33:59 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Sat, 19 Apr 2014 19:33:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <72CC862F-0CEA-4A4D-9AA3-7613F926472F@gmail.com> References: To: Bill Frantz X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ADzI6WH9FjwWLEiIt36EUrRUs80 Cc: tls@ietf.org Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 16:34:07 -0000 On Apr 19, 2014, at 6:55 PM, Bill Frantz wrote: > On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: >=20 >> Those who won=92t use TCP are doomed to re-create it. To get a = UDP-based protocol to replace TCP for=20 >> the web you=92d need all of reliable delivery through (selective?) = retransmissions, bandwidth=20 >> detection, replay protection, a whole lot of things that took the = transport community years to get=20 >> right. Yes, there have been many attempts, but there=92s a reason TCP = is still the protocol everyone=20 >> uses for pretty much any type of bulk transfer. And this is before we = even begin to talk about=20 >> middleboxes dropping unrecognized UDP services. >=20 > Absolutely correct. >=20 > However, one could set up a DTLS session and then initialize the TCP = protocol within that session. You mean a security layer between the IP layer and the transport layer?=20= > I don't think anyone has considered this inversion before. It may not = be useful, but=85 Except people who have implemented IPsec in transport mode. For = compatibility with NAT, it can use UDP with port 4500. Really, the only advantage of DTLS over IPsec is that the TLS handshake = is easier to deploy than IPsec=92s key exchange (IKE), because IKE = demands mutual authentication, and deploying client credentials is so = hard, some people would like us to remove it entirely from TLS 1.3. What would work nicely (and some vendors have products that do this = already) is initiating IPsec in a client/server model, where the client = receives the details of the IPsec SA from the server. That transaction = could run over UDP or even over HTTPS. Of course, I think this is the = wrong mailing list to discuss a suggestion like this. Yoav From nobody Sat Apr 19 10:14: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 11CA91A004C for ; Sat, 19 Apr 2014 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j0kwkwLyBHr5 for ; Sat, 19 Apr 2014 10:14:04 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 11A621A0041 for ; Sat, 19 Apr 2014 10:14:03 -0700 (PDT) Received: from [174.236.38.99] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WbYpy-00067m-EI; Sat, 19 Apr 2014 13:13:58 -0400 Date: Sat, 19 Apr 2014 10:13:58 -0700 From: Bill Frantz To: Yoav Nir X-Priority: 3 In-Reply-To: <72CC862F-0CEA-4A4D-9AA3-7613F926472F@gmail.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791ed746939a5351a472d87f8842134530350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.38.99 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TmZ-yAviKwYoJRjCJZCzthyZCp8 Cc: tls@ietf.org Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 17:14:07 -0000 On 4/19/14 at 9:33 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: >>However, one could set up a DTLS session and then initialize the TCP prot= ocol within that session. > >You mean a security layer between the IP layer and the=20 >transport layer? >>I don't think anyone has considered this inversion before. It may not be = useful, but=E2=80=A6 > >Except people who have implemented IPsec in transport mode. For=20 >compatibility with NAT, it can use UDP with port 4500. Indeed IPsec is proof that it can work. >Really, the only advantage of DTLS over IPsec is that the TLS=20 >handshake is easier to deploy than IPsec=E2=80=99s key exchange=20 >(IKE), because IKE demands mutual authentication, and deploying=20 >client credentials is so hard, some people would like us to=20 >remove it entirely from TLS 1.3. > >What would work nicely (and some vendors have products that do=20 >this already) is initiating IPsec in a client/server model,=20 >where the client receives the details of the IPsec SA from the=20 >server. That transaction could run over UDP or even over=20 >HTTPS. Of course, I think this is the wrong mailing list to=20 >discuss a suggestion like this. If we can get IPsec to be practical for the TLS use cases, we=20 can all go home. :-) One of the disadvantages of putting TCP on top of the encrypted=20 layer is that when a packet is resent it is re-encrypted. My=20 crypto-plumber reflexes say that re-encryption can be dangerous=20 with certain systems, but I can't remember the details.=20 Apparently IPsec has avoided this problem. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Sat Apr 19 10:32: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 DFCBD1A004C for ; Sat, 19 Apr 2014 10:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWr1gaUZk2s2 for ; Sat, 19 Apr 2014 10:32:33 -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 EFFCC1A0041 for ; Sat, 19 Apr 2014 10:32:31 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4826D10CFC for ; Sat, 19 Apr 2014 13:32:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=0FELS/+RCKc3 3m8bYlCM3UkcknI=; b=x7PgsirgUvERCROQ/M/ifPU5tz0j9S/ghPbcvLHQJHNJ 5Pt0uxwbyM0RkhuINU0qVn1FBGCiNm5hhwYk73qpP5668+Jm2UkMEPY3M/cMv1Wt 6tBytoZp0//pN1M6RqqA891KIYj0pbVxOGUbp7ieSf8nL9brDId22DdV385nijY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SeAg9x pBMtvIPqy6MZ9iS5iyo3yakCINZYWnKncJgLvEy+uP8EbIIVAHTMx5x/fkfNJW60 La0LUFEM0I8ytyW1xamzqc/nvnsyQTMbkYQnIJ2WEH6Cn5gcjjcPqTsdzaP9DU7s lao4nkuB1XZVnut4Dp9K49kvtosJBSRwI+jMA= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3F6CD10CFB for ; Sat, 19 Apr 2014 13:32:27 -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 D70E010CFA for ; Sat, 19 Apr 2014 13:32:25 -0400 (EDT) Message-ID: <5352B328.1080006@pobox.com> Date: Sat, 19 Apr 2014 10:32:24 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "tls@ietf.org" References: <20140419131019.GA29561@roeckx.be> In-Reply-To: <20140419131019.GA29561@roeckx.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 92C1BE52-C7E8-11E3-BEFD-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6b4w1GMy7PwtYJKPFEsnqQf8m4Q Subject: Re: [TLS] RC4 deprecation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 17:32:36 -0000 Kurt Roeckx wrote: > > - Clients should not announce support for RC4 in their initial > connection attempt, and only fall back to support it when the > server says that there are no common ciphers. (I'm not sure > if a MITM can fake that response or not.) Continue the handshake all the way through to the Finished messages to determine if a MITM has tampered with it. This will only not work if the server is of the type that chooses RC4 no matter where it is in the client's cipher suite list. Here's the message flow I'm thinking about: ClientHello (w/o RC4) -----> <----- Alert (handshake_failure) close and reconnect: ClientHello (with RC4) -----> <----- ServerHello (RC4 chosen) ..... continues Place the RC4 suites at the end of the list so that the server will not choose them if it respects the client's preference. Mike From nobody Sat Apr 19 10:44: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 839EE1A0064 for ; Sat, 19 Apr 2014 10:44: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 DfOOFVYLEqhW for ; Sat, 19 Apr 2014 10:44:33 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) by ietfa.amsl.com (Postfix) with ESMTP id EE36A1A0061 for ; Sat, 19 Apr 2014 10:44:32 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 19so2279468ykq.11 for ; Sat, 19 Apr 2014 10:44:28 -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=lP+CneJajfhTjuL3PnYwFhh/TKujz51Qw6kO/UXwvqo=; b=Ky8oq1LBQU3XnA10+SE+wrr0FMdpQgKee3T4xCOiYyJEbCGPuLeo0BnUT3tUJ3IBAx ENWyLva5cf10sgCyF/mLy1gDrgB4IATJM5Sua7iBTUnR+Vx5gzM5P0M00n5REY0odTlE JFvaqLratsFxOaD60pjzuwC5xjdTjm3pvQvRVkRxIwAglUgwAvvUfnxiksGcuNx2C87c r1Zl3iTPDn+8gR0OXYpK4kiKFgM1agTbbgCLwzH+J9YyN+P/kM8ybypni4uMz7xey5i6 hDdMW2yzSSsDPWdaWQ8tw2KQq3buRJvKs9pn+BRMQn6KgMo5zwA/Kalvw8rlS8+kAg19 SZvA== MIME-Version: 1.0 X-Received: by 10.236.128.180 with SMTP id f40mr4332382yhi.71.1397929468335; Sat, 19 Apr 2014 10:44:28 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sat, 19 Apr 2014 10:44:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Apr 2014 10:44:28 -0700 Message-ID: From: Watson Ladd To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sHoT33FrzcKuvtanljc8UD2C_4c Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 17:44:37 -0000 On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz wrote: > There are two use cases to keep in mind here: > > There are environments which need authentication and replay protection but > can not use secrecy. Amateur radio communications comes to mind where the > FCC regulations forbid encoding a message with the intent of obscuring its > meaning. > > Now the risks of having secrecy compromised in the many palaces we want to > have it out weigh the advantages of supporting this small part of of the use > space, but at least we should think for a moment about the choice. Authenticated only channels are occasionally nice, we can do them, but most users don't need them, and most implementations don't keep them separate enough to avoid mistakes. > > > The other use case to always keep in mind is limited performance devices. > With the Internet of Things, we will continue to see new 8 bit, and possibly > even 4 bit processors as manufactures drive in the direction of the small, > low power, and cheap. These devices will be much safer if they have > authentication and replay protection. While secrecy is probably not as > important, it might also be vital in certain applications of these devices. So AES-CCM fixes one issue (the wire PDU), but we really, really, need a hash for the handshake. These devices also might not even have random number generators that aren't deterministic or a counter to avoid replays. There's a lot to be done: benchmarking, thinking hard about protocol problems that might cause issues, determining what we can and cannot provide. >From some cursory research, hash functions are the real issue here. AES is byte-oriented, but Keccak is slow as molasses at big capacities sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR benchmark data? JW Bos has some ideas about reusing AES in a hash construction of double the size. With ECC life can get interesting. Drop the idea of RSA and DHE over F_p: too slow. 8 bit saturated arithmetic is probably the best. Timings are pretty slow: lots of verifications are a terrible idea. With PSK you don't need any of this, but I think that some embedded CPUs have the horsepower to do ECC, even at 8 bits. Make sure that this happens rarely, i.e. mostly static keys so results can be cached, and I think we are good. Due to memory pressure ladders are great. I've never seen a 4 bit micro. Anyone got details on what they are like and can do? Sincerely, Watson Ladd > > Cheers - Bill > > ----------------------------------------------------------------------- > Bill Frantz | Truth and love must prevail | Periwinkle > (408)356-8506 | over lies and hate. | 16345 Englewood Ave > www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 > > > _______________________________________________ > 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 Sat Apr 19 10:54: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 62F6E1A0057 for ; Sat, 19 Apr 2014 10:53: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 su_TlS_Kp8eZ for ; Sat, 19 Apr 2014 10:53: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 62C0A1A0055 for ; Sat, 19 Apr 2014 10:53:57 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 9684D1C23B3; Sat, 19 Apr 2014 19:53:52 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6950C1FE0214; Sat, 19 Apr 2014 19:53:52 +0200 (CEST) Date: Sat, 19 Apr 2014 19:53:52 +0200 From: Kurt Roeckx To: Michael D'Errico Message-ID: <20140419175352.GA9090@roeckx.be> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5352B328.1080006@pobox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XfDE81oUXK0W84WGRar28-P6dmg Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 deprecation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 17:53:59 -0000 On Sat, Apr 19, 2014 at 10:32:24AM -0700, Michael D'Errico wrote: > Kurt Roeckx wrote: > > > >- Clients should not announce support for RC4 in their initial > > connection attempt, and only fall back to support it when the > > server says that there are no common ciphers. (I'm not sure > > if a MITM can fake that response or not.) > > Continue the handshake all the way through to the Finished messages > to determine if a MITM has tampered with it. This will only not > work if the server is of the type that chooses RC4 no matter where > it is in the client's cipher suite list. > > Here's the message flow I'm thinking about: > > ClientHello (w/o RC4) -----> > <----- Alert (handshake_failure) > > close and reconnect: > > ClientHello (with RC4) -----> > <----- ServerHello (RC4 chosen) > ..... continues > > Place the RC4 suites at the end of the list so that the server will > not choose them if it respects the client's preference. Right, so an MITM could downgrade to RC4 in case the server prefers RC4 over the rest in that case. Kurt From nobody Sat Apr 19 12:21: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 3BBF11A007F for ; Sat, 19 Apr 2014 12:21: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 JrZenK6xFB9L for ; Sat, 19 Apr 2014 12:21:33 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86CCB1A006E for ; Sat, 19 Apr 2014 12:21:33 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so1492841wgh.15 for ; Sat, 19 Apr 2014 12:21: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2o28f4TZ/09wPthyzSF5K7F1up8ZDUEaKN1PtmUo4+g=; b=Itns65ZXu9QdzzEHu/oh0hf4KWZtw8mazPJT/WclEZSGjdpHqLcV0Wpt8/UxAVouMq cu7JLertlaxmIY+qaoKmb2ncj3q+SukTDSKQ2owGa/fyHFmCFWmzdo2EgrFzR2KB1R5c Mi8S39mgNdFHfFuyfbYFjGg62FvghwDAoQ9Pg3UnzaV41DS+4yRUl8S0Z34+imvvxJDZ 2YfrwJ8uWIviQGWI3/55yzQYRWFZWDG8PGFXUJL2Zym7SVjwmvXgW1oKY+ydYNyIdm56 JpTJkQGBI6DwaXms1vzFb20KUrrbdfEqUMHobEWTNCtlB2kMGdaT3yzcIhfvKfszRZGg gbhQ== X-Gm-Message-State: ALoCoQmniTOW3z5ir59wiSnxWBMiQKWqL5pUJSX4bAFVTbKE4LCTxi/R47I30VYXM+CzHsdfw67X X-Received: by 10.181.8.204 with SMTP id dm12mr792642wid.1.1397935288759; Sat, 19 Apr 2014 12:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 19 Apr 2014 12:20:48 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> From: Eric Rescorla Date: Sat, 19 Apr 2014 12:20:48 -0700 Message-ID: To: Bill Frantz Content-Type: multipart/alternative; boundary=001a113484ca4e4df704f76a2c4f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e8wGqphUD6TTsWIC6bCk8Qj_bU8 Cc: "tls@ietf.org" Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:21:36 -0000 --001a113484ca4e4df704f76a2c4f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz wrote: > On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: > > > Those who won't use TCP are doomed to re-create it. To get a UDP-based > protocol to replace TCP for > > the web you'd need all of reliable delivery through (selective?) > retransmissions, bandwidth > > detection, replay protection, a whole lot of things that took the > transport community years to get > > right. Yes, there have been many attempts, but there's a reason TCP is > still the protocol everyone > > uses for pretty much any type of bulk transfer. And this is before we > even begin to talk about > > middleboxes dropping unrecognized UDP services. > > Absolutely correct. > > However, one could set up a DTLS session and then initialize the TCP > protocol within that session. > > I don't think anyone has considered this inversion before. It may not be > useful, but.. > This is how WebRTC DataChannels work, except that it's SCTP rather than TCP. http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03 The WG did consider TCP but selected SCTP for a variety of reasons that probably don't bear going into here. You certainly could build the same thing with TCP. -Ekr --001a113484ca4e4df704f76a2c4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <= frantz@pwpconsul= t.com> wrote:
On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote:

> Those who won’t use TCP are doomed to re-create it. To get a UDP= -based protocol to replace TCP for
> the web you’d need all of reliable delivery through (selective?)= retransmissions, bandwidth
> detection, replay protection, a whole lot of things that took the tran= sport community years to get
> right. Yes, there have been many attempts, but there’s a reason = TCP is still the protocol everyone
> uses for pretty much any type of bulk transfer. And this is before we = even begin to talk about
> middleboxes dropping unrecognized UDP services.

Absolutely correct.

However, one could set up a DTLS session and then initialize the TCP protoc= ol within that session.

I don't think anyone has considered this inversion before. It may not b= e useful, but..

This is how WebRTC Data= Channels work, except that it's SCTP rather than TCP.


The WG did consider TCP but selected SCTP= for a variety of reasons that probably
don't bear going into here. You certainly could build the same thi= ng with TCP.

-Ekr



--001a113484ca4e4df704f76a2c4f-- From nobody Sat Apr 19 12:28: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 8DBBE1A008D for ; Sat, 19 Apr 2014 12:28:41 -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 9ShyAgRGe3IQ for ; Sat, 19 Apr 2014 12:28:38 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 497381A0078 for ; Sat, 19 Apr 2014 12:28:38 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id e49so2557718eek.17 for ; Sat, 19 Apr 2014 12:28:33 -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=ytCaXUulmUnV/DvLpRmPVLQlkDuJOYCdtesnx04QU60=; b=QlH53zQVQW9UhzoE6zq4pVil3dYo2mLL6vF6zi9lpaSGhVquT6C18CQHmQvibfwz+s 4xk9Wk/CfPUBB3cECWBm1F76QBUpwstWI4AqfqXkZKdOrv3Wyt1XqXOp7BC6chvtosF7 X33/2+VXO+5Upv7MKe/b9EoivYbKj26WcX+nKFsMjso/W9BXvnKv7gvKXDKafu8pcaTP hOSDcS2zJKWFAPHi2LTzjwMN1m7BpbD93hMMBjKv5GyYaHWnLwjbPlEs5c3yzPv3QwQy REZqvGjY+AYl6ETejLL3d25RRtRlUxOpSxiUJViSJrU8R0KzQgG0PyPAXJTJsothZywU 6DOg== X-Received: by 10.15.36.136 with SMTP id i8mr238435eev.113.1397935713460; Sat, 19 Apr 2014 12:28:33 -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 h47sm88091514eey.13.2014.04.19.12.28.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 12:28:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E26ABC-713F-4C14-940D-AACA297FE379" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <20140419175352.GA9090@roeckx.be> Date: Sat, 19 Apr 2014 22:28:19 +0300 Message-Id: <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> To: Kurt Roeckx X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5UAEpumTdmn6mHa9LgFiVnD848U Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 deprecation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:28:41 -0000 --Apple-Mail=_E6E26ABC-713F-4C14-940D-AACA297FE379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 19, 2014, at 8:53 PM, Kurt Roeckx wrote: > On Sat, Apr 19, 2014 at 10:32:24AM -0700, Michael D'Errico wrote: >> Kurt Roeckx wrote: >>>=20 >>> - Clients should not announce support for RC4 in their initial >>> connection attempt, and only fall back to support it when the >>> server says that there are no common ciphers. (I'm not sure >>> if a MITM can fake that response or not.) >>=20 >> Continue the handshake all the way through to the Finished messages >> to determine if a MITM has tampered with it. This will only not >> work if the server is of the type that chooses RC4 no matter where >> it is in the client's cipher suite list. >>=20 >> Here's the message flow I'm thinking about: >>=20 >> ClientHello (w/o RC4) -----> >> <----- Alert (handshake_failure) >>=20 >> close and reconnect: >>=20 >> ClientHello (with RC4) -----> >> <----- ServerHello (RC4 chosen) >> ..... continues >>=20 >> Place the RC4 suites at the end of the list so that the server will >> not choose them if it respects the client's preference. >=20 > Right, so an MITM could downgrade to RC4 in case the server > prefers RC4 over the rest in that case. Yes. As long as the client is required to support such servers, I guess = we have to live with it. It=92s possible to make some kind of extension to help discover this = activity by a MitM, but I don=92t expect servers that continue to = support RC4 to be the kind of servers that upgrade to the latest version = of the software, the one that supports the new extension. Yoav --Apple-Mail=_E6E26ABC-713F-4C14-940D-AACA297FE379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 19, 2014, at 8:53 PM, Kurt = Roeckx <kurt@roeckx.be> = wrote:

On Sat, Apr 19, 2014 at 10:32:24AM = -0700, Michael D'Errico wrote:
Kurt Roeckx = wrote:

- Clients should not announce = support for RC4 in their initial
connection attempt, and only fall = back to support it when the
server says that there are no common = ciphers.  (I'm not sure
if a MITM can fake that response or = not.)

Continue the handshake all the way through to = the Finished messages
to determine if a MITM has tampered with it. =  This will only not
work if the server is of the type that = chooses RC4 no matter where
it is in the client's cipher suite = list.

Here's the message flow I'm thinking = about:

   ClientHello (w/o RC4) =      ----->
     &= nbsp;           &nb= sp;            = ;<-----    Alert (handshake_failure)

close and = reconnect:

   ClientHello (with RC4) =     ----->
      &= nbsp;           &nb= sp;           <-= ----    ServerHello (RC4 = chosen)
          &nb= sp;            = ;            &= nbsp;    ..... continues

Place the RC4 suites = at the end of the list so that the server will
not choose them if it = respects the client's preference.

Right, so an MITM = could downgrade to RC4 in case the server
prefers RC4 over the rest = in that case.

Yes. As long as the = client is required to support such servers, I guess we have to live with = it.

It=92s possible to make some kind of = extension to help discover this activity by a MitM, but I don=92t expect = servers that continue to support RC4 to be the kind of servers that = upgrade to the latest version of the software, the one that supports the = new = extension.

Yoav

= --Apple-Mail=_E6E26ABC-713F-4C14-940D-AACA297FE379-- From nobody Sat Apr 19 12:33: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 0EAB51A0096 for ; Sat, 19 Apr 2014 12:33: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 FHZ4Sr-EioF2 for ; Sat, 19 Apr 2014 12:33:05 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DD55E1A0078 for ; Sat, 19 Apr 2014 12:33:05 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so2451220pbb.36 for ; Sat, 19 Apr 2014 12:33: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=BOpBy1fgg54oARypBH1hA1CAy4jPgzUUuZjszIwkiWo=; b=g4ZfDTZBGmfosce8Q7XMByu1/ZOXuB6p3KvozeiGk8sRzpoSDlzg+4KFlt2uB7WOgq tDz0o3OM3SwHBB0TRliReq/qZP3/ht+msJXC85gFEkcrjgk2olTZtQIe5sKw675BQAif Zu53N9Dw8MGZFXLDbCwwqN1zMraCQ7R2xwX96kU6Fvjt0jibkOPHbWnyos6pan0cGOkD HcS+O1L7zI5jtTf7/3HzYJwOhwAG9U3HsCuexCiqOdpL27J8Ls9vpd+8lyHcjk8l4+cp 1dAEkNu+H6ARhe0LOAFjhprIUFxX0Lm1WBena10IB+kY9edqnM8fmo/NDH52/K/fprpM OBdA== X-Received: by 10.66.227.104 with SMTP id rz8mr29011581pac.74.1397935981512; Sat, 19 Apr 2014 12:33:01 -0700 (PDT) Received: from [10.0.1.2] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id iv2sm67763210pbc.19.2014.04.19.12.32.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 12:32:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D167) In-Reply-To: <20140419131019.GA29561@roeckx.be> Date: Sat, 19 Apr 2014 12:32:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140419131019.GA29561@roeckx.be> To: Kurt Roeckx Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P1BPGf5JUB4k7uceyeHKEpdWKqU Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:33:10 -0000 > On Apr 19, 2014, at 6:10, Kurt Roeckx wrote: >=20 >> On Fri, Apr 18, 2014 at 11:03:44PM -0700, Watson Ladd wrote: >>> On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen wro= te: >>> Alyssa Rowan writes: >>>=20 >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>>=20 >>>> It looks like RC4 is rapidly heading for the chopping block, with >>>> basically unanimous consensus. Good. >>>=20 >>> Agreed, mod Martin's proposal that I understand to ask for a reasonable >>> path by which we strongly deprecate RC4 on clients, then after a client >>> generation ban RC4 on clients and deprecate for servers. >>=20 >> I don't think this is the correct path. I think what we should do is >> have clients and servers both prefer other options (in all TLS >> versions), then once that change is made, ban it entirely. Deprecation >> on one side won't affect the other side if there isn't an alternative >> mandated. (Right now RC4 only servers are keeping RC4 alive). >>=20 >> This first step has already happened in the web context on modern >> browsers. What we need is to make the server side step happen, and >> then think about removal in the second step. >>=20 >> Sadly, our ability to force upgrades is very limited. >=20 > And I think publishing an RFC isn't actually really going to help > much. =20 Not much, but a little bit. I think there are still a lot of people (includi= ng myself) that are not convinced that the severity of the attacks against R= C4 justify removing it yet. I'm not an expert enough to be able to tell if t= he various published papers about RC4 are mostly theoretical issues, or prac= tical ones.=20 If the IETF comes out with an RFC officially deprecating it, that's one more= thing telling me this is serious enough that it should really be looked at.= > Yes, people could use it tell others that it's deprecated, > but I think there are already more than enough places that say so > that having this RFC isn't really going to make a difference > I do agree that we need to try to get both sides to stop using it, > and I wish we could just tell people to stop using it and that > they would do so. But I don't see either the server or the client > side wanting to break things. It would clearly help if they could > say at which point they wouldn't mind breaking things > So I think that for now the best we can do is: > - Servers should either stop accepting RC4 or make sure that=20 > if the clients supports something better (TLS >=3D 1.1?) it should > not pick RC4. I would think there would be very few if any clients out there that only sup= port RC4. But I would expect some servers out there do no support RC4 alread= y. Although I have no actual data to support my gut feeling here, and would be g= lad to be proven wrong.=20 > It's my understanding that the client preferences of ciphers > should be used but that servers can override that, and that > there might be good reasons to do so. For instance to get PFS > when talking to Internet Explorer. If they override it, they > should make sure not to put RC4 first. Basically, a mondern > client should never get RC4. > - Clients should not announce support for RC4 in their initial > connection attempt, and only fall back to support it when the > server says that there are no common ciphers. (I'm not sure > if a MITM can fake that response or not.) >=20 > At some point in time when the clients or servers think that they > don't need to support RC4 anymore they should disable it. >=20 >=20 > Kurt >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Apr 19 12:40:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC561A0078 for ; Sat, 19 Apr 2014 12:40:57 -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 EimRU6datic5 for ; Sat, 19 Apr 2014 12:40:53 -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 78EFB1A0087 for ; Sat, 19 Apr 2014 12:40:53 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so2388936yho.4 for ; Sat, 19 Apr 2014 12:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XPiHkqPGXsReuEM8cmvN4CWUe8waOaqsYni59eHOuBo=; b=BWxnBPOPP1sPGSP5N+6OYeK9s8PZAsfkI75ztjHX/xoTOQ6yGd1uWqz7Xdgb5aqa80 rds88IS5EMionWNPUzHGakFzTfyHZsC8IJrdlP3Zzxp92NeuEjAQBYNk0u7pJgnxAxN9 HsrBXN3XAovgJk8bO+jd7XPi2ZnmOI08ji9/4qKY1jD6s3Mgl2XOBltLq3xekshAPhg/ MIiMhZhQY91dAo7R8OGT3SmkukR4ZaLaRcV7bMPCDKeAFyUVxx3+4tDTlkgiBzjpF4Ae hycZBoFzXy1heS4r1OENOeGPjcginS71X9bAdgalT3Mh4m5nMTRCn+1IreahHJpnWIdP Ahmw== MIME-Version: 1.0 X-Received: by 10.236.156.65 with SMTP id l41mr39669157yhk.9.1397936449028; Sat, 19 Apr 2014 12:40:49 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sat, 19 Apr 2014 12:40:48 -0700 (PDT) In-Reply-To: References: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> Date: Sat, 19 Apr 2014 12:40:48 -0700 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/aGXajOEW7ZrlloR5D7fFD-DRhnc Cc: "tls@ietf.org" Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:40:57 -0000 On Sat, Apr 19, 2014 at 12:20 PM, Eric Rescorla wrote: > > > > On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz wrot= e: >> >> On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: >> >> > Those who won=E2=80=99t use TCP are doomed to re-create it. To get a U= DP-based >> > protocol to replace TCP for >> > the web you=E2=80=99d need all of reliable delivery through (selective= ?) >> > retransmissions, bandwidth >> > detection, replay protection, a whole lot of things that took the >> > transport community years to get >> > right. Yes, there have been many attempts, but there=E2=80=99s a reaso= n TCP is >> > still the protocol everyone >> > uses for pretty much any type of bulk transfer. And this is before we >> > even begin to talk about >> > middleboxes dropping unrecognized UDP services. >> >> Absolutely correct. >> >> However, one could set up a DTLS session and then initialize the TCP >> protocol within that session. >> >> I don't think anyone has considered this inversion before. It may not be >> useful, but.. > > > This is how WebRTC DataChannels work, except that it's SCTP rather than T= CP. > > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03 > > The WG did consider TCP but selected SCTP for a variety of reasons that > probably > don't bear going into here. You certainly could build the same thing with > TCP. This is also how MinimaLT, CurveCP, and indeed TCP over IPSec (assuming we fix the issues that stop IPSec at the application layer from working) work. The flow control issues are easy: copy the algorithm from TCP. The firewall issues are not. There is also an issue with the size of Server Hellos: they cannot be larger than the Client Hello in the first round to avoid amplification. So you won't get a full X509 chain in in one round. However, you can spend 2RTT and still beat the 1RTT over TCP solution. If you want to change things up even more, send the certs after the channel is established. Sincerely, Watson Ladd > > -Ekr > > > > > _______________________________________________ > 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 Sat Apr 19 12:42: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 89DC51A0096 for ; Sat, 19 Apr 2014 12:42:00 -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 VHibZy_AYtoW for ; Sat, 19 Apr 2014 12:41:59 -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 E839A1A0078 for ; Sat, 19 Apr 2014 12:41:58 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so2545745eek.7 for ; Sat, 19 Apr 2014 12:41:54 -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=SQqNMgzlH4HM0f0Dt08fYTKw7FQNQY6fWSnaGg7uZr8=; b=hs7wsVepCAJ6AlxuNuvAKjBPLxHAz3ROcv4rSGOk/hOxcIEMH+rDZ4etjrALzF5Pcc CdRLPNm1aQNlUjfVU4UFMMhTT+JFQct/IWh9SMXUwDClzavnXQS1lZqg1drucY/W5fqI 2n/WfjjYgVEMiYmPv/q6mBX/osiddhDHj2jkZ7zTfgdLkUZl79+KM29apM2fQYDyU6hd Ebz6hOL3/E8FiLtDk4HbkNUc/zu4MCaQkdYrai/ZstW1q/lkv0iAuOki7cdHPs078TAB v2pP5NLDo51o9dLFYkZJWgJeqrP3PjvBOYdV5QOcrNILFfZfpSKA+WvhgBXCqsV8J9U6 bkgA== X-Received: by 10.15.102.74 with SMTP id bq50mr33009074eeb.21.1397936514070; Sat, 19 Apr 2014 12:41:54 -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 y7sm88177495eev.5.2014.04.19.12.41.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 12:41:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D9D3599D-0D05-4A6E-8A71-4A38C5431F8B" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Sat, 19 Apr 2014 22:41:50 +0300 Message-Id: <38332C9B-D2B3-48DB-B794-866B619E152F@gmail.com> References: <20140419131019.GA29561@roeckx.be> To: Fabrice X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kKxPJkGBAoQ37Rzwc-A0vuPlqh4 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:42:00 -0000 --Apple-Mail=_D9D3599D-0D05-4A6E-8A71-4A38C5431F8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 19, 2014, at 10:32 PM, Fabrice wrote: >> On Apr 19, 2014, at 6:10, Kurt Roeckx wrote: >>=20 >>> Sadly, our ability to force upgrades is very limited. >>=20 >> And I think publishing an RFC isn't actually really going to help >> much. =20 >=20 > Not much, but a little bit. I think there are still a lot of people = (including myself) that are not convinced that the severity of the = attacks against RC4 justify removing it yet. I'm not an expert enough to = be able to tell if the various published papers about RC4 are mostly = theoretical issues, or practical ones.=20 >=20 > If the IETF comes out with an RFC officially deprecating it, that's = one more thing telling me this is serious enough that it should really = be looked at. +1 An RFC can help me convince management to let me make RC4 off by = default. Totally removing it from the product? Probably not. On the IPsec side = of it we still have =93Export=94 ciphers like 40-bit DES, but making it = off by default goes a long way towards making it not deployed. Yoav --Apple-Mail=_D9D3599D-0D05-4A6E-8A71-4A38C5431F8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 19, 2014, at 10:32 PM, Fabrice = <fabrice.gautier@gmail.com>= ; wrote:

On Apr = 19, 2014, at 6:10, Kurt Roeckx <kurt@roeckx.be> = wrote:

Sadly, our ability to force = upgrades is very limited.

And I think publishing an = RFC isn't actually really going to help
much. =  

Not much, but a little bit. I think there are = still a lot of people (including myself) that are not convinced that the = severity of the attacks against RC4 justify removing it yet. I'm not an = expert enough to be able to tell if the various published papers about = RC4 are mostly theoretical issues, or practical ones. 

If the IETF comes = out with an RFC officially deprecating it, that's one more thing telling = me this is serious enough that it should really be looked = at.

+1

An = RFC can help me convince management to let me make RC4 off by = default.

Totally removing it from the product? =  Probably not. On the IPsec side of it we still have =93Export=94 = ciphers like 40-bit DES, but making it off by default goes a long way = towards making it not = deployed.

Yoav

= --Apple-Mail=_D9D3599D-0D05-4A6E-8A71-4A38C5431F8B-- From nobody Sat Apr 19 12:51: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 5A6451A00CB for ; Sat, 19 Apr 2014 12:51: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 AlQDXz6IBAv2 for ; Sat, 19 Apr 2014 12:51:02 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 32B531A00BD for ; Sat, 19 Apr 2014 12:51:02 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so2496426wes.26 for ; Sat, 19 Apr 2014 12:50:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V6b1vUylEJmWMWEOZg5DwICa/3vucH7nJR0HIu2Lq7A=; b=mwkUTWaHVx1yrz/l5USHX/LslEYkCc4/uDBv+6gjwrY1Ndm/EIr7IJF1V+0t0+ZJGu 7Wlbi09PMsAVUit+cMc7B3+TsXN4iVTcyYK6NDIEqpubhW7mD0MkNT67rYEOlN9DKPfh p2zYS6TzNE+IFrLTAzi3sKwCOlJ005DIiGM7l8qv6yDVxsb5m7XCY+7Qjy94CL14RTd5 YwZlDEoM3rWdElH2wtEZuMnhiA8S7MGDFOrFjJgGpnetgkD/Gh7FFwIb3PRlf13i3e16 8kxlM6mtYAr+Tvu6UHy50aeIq3LhJR6gANbwikv0ntHtzEvYY3bVu3Z2LwWSgkIdVZA5 K02Q== X-Gm-Message-State: ALoCoQklU0PKJHKdzOJsEps8tuG/XW/Z4zUPAODGoPeMNEj1tkD/GbuFHJMXGqh7YtPMHpra29Gc X-Received: by 10.194.203.170 with SMTP id kr10mr21987547wjc.19.1397937057408; Sat, 19 Apr 2014 12:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 19 Apr 2014 12:50:17 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com> From: Eric Rescorla Date: Sat, 19 Apr 2014 12:50:17 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b6d87deb9bd6504f76a9584 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ID_d8TBxpuWicfiLMrmxSkokGAw Cc: "tls@ietf.org" Subject: Re: [TLS] Forged RST (was: About encrypting SNI) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:51:05 -0000 --047d7b6d87deb9bd6504f76a9584 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 19, 2014 at 12:40 PM, Watson Ladd wrote: > On Sat, Apr 19, 2014 at 12:20 PM, Eric Rescorla wrote: > > > > > > > > On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz > wrote: > >> > >> On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote: > >> > >> > Those who won't use TCP are doomed to re-create it. To get a UDP-based > >> > protocol to replace TCP for > >> > the web you'd need all of reliable delivery through (selective?) > >> > retransmissions, bandwidth > >> > detection, replay protection, a whole lot of things that took the > >> > transport community years to get > >> > right. Yes, there have been many attempts, but there's a reason TCP is > >> > still the protocol everyone > >> > uses for pretty much any type of bulk transfer. And this is before we > >> > even begin to talk about > >> > middleboxes dropping unrecognized UDP services. > >> > >> Absolutely correct. > >> > >> However, one could set up a DTLS session and then initialize the TCP > >> protocol within that session. > >> > >> I don't think anyone has considered this inversion before. It may not be > >> useful, but.. > > > > > > This is how WebRTC DataChannels work, except that it's SCTP rather than > TCP. > > > > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03 > > > > The WG did consider TCP but selected SCTP for a variety of reasons that > > probably > > don't bear going into here. You certainly could build the same thing with > > TCP. > > This is also how MinimaLT, CurveCP, and indeed TCP over IPSec > (assuming we fix the issues that stop IPSec at the application layer > from working) work. The flow control issues are easy: copy the > algorithm from TCP. The firewall issues are not. > Yes, the firewall issues are fairly complicated. The good news is that they're quite a bit easier in client-server type applications because servers generally have public IP addresses (otherwise you pretty much cannot connect to them via TCP). Basically, either the client is behind a network element (firewall/NAT) which lets UDP in and out or it's not. If it is (estimates for this vary, but rumors are ~95%), then client-server TCP over UDP variants should work. The situation is of course much more complicated for P2P applications, and in such applications you need ICE and generally a media relay server. -Ekr --047d7b6d87deb9bd6504f76a9584 Content-Type: text/html; charset=ISO-8859-1



On Sat, Apr 19, 2014 at 12:40 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Sat, Apr 19, 2014 at 12:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>
>> On 4/17/14 at 1:27 AM, ynir.ietf@gmail.com (Yoav Nir) wrote:
>>
>> > Those who won’t use TCP are doomed to re-create it. To get a UDP-based
>> > protocol to replace TCP for
>> > the web you’d need all of reliable delivery through (selective?)
>> > retransmissions, bandwidth
>> > detection, replay protection, a whole lot of things that took the
>> > transport community years to get
>> > right. Yes, there have been many attempts, but there’s a reason TCP is
>> > still the protocol everyone
>> > uses for pretty much any type of bulk transfer. And this is before we
>> > even begin to talk about
>> > middleboxes dropping unrecognized UDP services.
>>
>> Absolutely correct.
>>
>> However, one could set up a DTLS session and then initialize the TCP
>> protocol within that session.
>>
>> I don't think anyone has considered this inversion before. It may not be
>> useful, but..
>
>
> This is how WebRTC DataChannels work, except that it's SCTP rather than TCP.
>
> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-03
>
> The WG did consider TCP but selected SCTP for a variety of reasons that
> probably
> don't bear going into here. You certainly could build the same thing with
> TCP.

This is also how MinimaLT, CurveCP, and indeed TCP over IPSec
(assuming we fix the issues that stop IPSec at the application layer
from working) work. The flow control issues are easy: copy the
algorithm from TCP. The firewall issues are not.

Yes, the firewall issues are fairly complicated. The good news is that
they're quite a bit easier in client-server type applications because
servers generally have public IP addresses (otherwise you pretty
much cannot connect to them via TCP). Basically, either the client
is behind a network element (firewall/NAT) which lets UDP in and
out or it's not. If it is (estimates for this vary, but rumors are ~95%),
then client-server TCP over UDP variants should work.

The situation is of course much more complicated for P2P
applications, and in such applications you need ICE and generally
a media relay server.

-Ekr





--047d7b6d87deb9bd6504f76a9584-- From nobody Sat Apr 19 12:53: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 BAA771A00BF for ; Sat, 19 Apr 2014 12:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272, 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 edfYxVaTxE-P for ; Sat, 19 Apr 2014 12:53:33 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) by ietfa.amsl.com (Postfix) with ESMTP id BE4611A00A5 for ; Sat, 19 Apr 2014 12:53:32 -0700 (PDT) Received: from [192.168.1.64] (bl16-75-26.dsl.telepac.pt [188.81.75.26]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id s3JJrOso029571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 19 Apr 2014 20:53:30 +0100 Message-ID: <5352D418.7010806@dei.uc.pt> Date: Sat, 19 Apr 2014 20:52:56 +0100 From: Samuel Neves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 CC: "tls@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: s3JJrOso029571 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-59.229, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00, MISSING_HEADERS 1.02) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pI5Dqe26gHMZ4w5EKPo-w_QPdkM Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:53:35 -0000 On 19-04-2014 18:44, Watson Ladd wrote: > >From some cursory research, hash functions are the real issue here. > AES is byte-oriented, but Keccak is slow as molasses at big capacities > sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR > benchmark data? The XBX team's report on SHA-3 finalists [1] might be of use here. It argues that memory, rather than CPU cycles, is the primary concern on 8-bit CPUs, and ends up recommending Keccak for the Atmel ATmega 1284P. [1] http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/March2012/documents/papers/WENZEL_BENNER_paper.pdf From nobody Sat Apr 19 12:54: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 2EBAE1A00BF for ; Sat, 19 Apr 2014 12:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aheDLEgm-JoU for ; Sat, 19 Apr 2014 12:54:40 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 353021A00A5 for ; Sat, 19 Apr 2014 12:54:40 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 128111C2121; Sat, 19 Apr 2014 21:54:35 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E27471FE0214; Sat, 19 Apr 2014 21:54:34 +0200 (CEST) Date: Sat, 19 Apr 2014 21:54:34 +0200 From: Kurt Roeckx To: Fabrice Message-ID: <20140419195434.GA21513@roeckx.be> References: <20140419131019.GA29561@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l-i_XONqXSbFYkTY2x7Eba4y6nA Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:54:44 -0000 On Sat, Apr 19, 2014 at 12:32:59PM -0700, Fabrice wrote: > > > So I think that for now the best we can do is: > > - Servers should either stop accepting RC4 or make sure that > > if the clients supports something better (TLS >= 1.1?) it should > > not pick RC4. > > I would think there would be very few if any clients out there that only support RC4. But I would expect some servers out there do no support RC4 already. > Although I have no actual data to support my gut feeling here, and would be glad to be proven wrong. IE on XP is known to only support 3DES, RC4, and some export ciphers. Not everybody agrees that 3DES would be best for those, because 3DES is much slower. 3DES would probably be vulnerable to BEAST, and IE6 doesn't like the record splitting. If you really need to support those clients RC4 might actually be your best option. I don't have any good stats about what clients our out there and what they support, but I've hard mozilla is collecting some. But then I'd actually rather see stats from someone else. For stats about servers, see: https://www.trustworthyinternet.org/ssl-pulse/ https://jve.linuxwall.info/blog/index.php?post/TLS_Survey Kurt From nobody Sat Apr 19 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 9BDE81A00D5 for ; Sat, 19 Apr 2014 12:57: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_66=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 soPwMqVXT3qv for ; Sat, 19 Apr 2014 12:57:15 -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 BC8FC1A00A5 for ; Sat, 19 Apr 2014 12:57:15 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id v1so589011yhn.29 for ; Sat, 19 Apr 2014 12:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wY7+tJ4ztHKyr3SWh1af8hb9HrVtcVIH3ZIDGz8IDQY=; b=xXacnXUL3hhJtapn+O6uy94kgNqP6tE1Knauy1Kvo+fENcDw/E2mQGxBVgUB6wlCj1 NiyohmoxU3VWBl3DDvSpLFvF+xdFhyWZ7VJyfhZ29xOhSX7R4I33E/k+7HuOAC+1hzjg usRjxeh8iuoz7JmkLcnKoEcSM7XrcaBG1pSFELmI1nE5oZyyUHI3TFjCI8wlLHSTS0q9 nU3ecMHk+fQpv4avzVguWQ6k4935Dxe4jQTVAPxpqNrqW4oI9XwsWt2vPTXpiyMK2u3d W+6cgbWu8C/iU/bdODCKT57Q1dLjmS8VE52X0AIWgFwxZzwh6X8yabF0olj/6a9AWdnt qldQ== MIME-Version: 1.0 X-Received: by 10.236.66.135 with SMTP id h7mr38920761yhd.60.1397937431178; Sat, 19 Apr 2014 12:57:11 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sat, 19 Apr 2014 12:57:11 -0700 (PDT) In-Reply-To: References: <20140419131019.GA29561@roeckx.be> Date: Sat, 19 Apr 2014 12:57:11 -0700 Message-ID: From: Watson Ladd To: Fabrice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/25Ns12-r7XTl9U8gHA_qRjz6j84 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 19:57:19 -0000 On Sat, Apr 19, 2014 at 12:32 PM, Fabrice wrote= : >> On Apr 19, 2014, at 6:10, Kurt Roeckx wrote: >> >>> On Fri, Apr 18, 2014 at 11:03:44PM -0700, Watson Ladd wrote: >>>> On Thu, Apr 17, 2014 at 9:15 AM, Brian Sniffen w= rote: >>>> Alyssa Rowan writes: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA512 >>>>> >>>>> It looks like RC4 is rapidly heading for the chopping block, with >>>>> basically unanimous consensus. Good. >>>> >>>> Agreed, mod Martin's proposal that I understand to ask for a reasonabl= e >>>> path by which we strongly deprecate RC4 on clients, then after a clien= t >>>> generation ban RC4 on clients and deprecate for servers. >>> >>> I don't think this is the correct path. I think what we should do is >>> have clients and servers both prefer other options (in all TLS >>> versions), then once that change is made, ban it entirely. Deprecation >>> on one side won't affect the other side if there isn't an alternative >>> mandated. (Right now RC4 only servers are keeping RC4 alive). >>> >>> This first step has already happened in the web context on modern >>> browsers. What we need is to make the server side step happen, and >>> then think about removal in the second step. >>> >>> Sadly, our ability to force upgrades is very limited. >> >> And I think publishing an RFC isn't actually really going to help >> much. > > Not much, but a little bit. I think there are still a lot of people (incl= uding myself) that are not convinced that the severity of the attacks again= st RC4 justify removing it yet. I'm not an expert enough to be able to tell= if the various published papers about RC4 are mostly theoretical issues, o= r practical ones. > > If the IETF comes out with an RFC officially deprecating it, that's one m= ore thing telling me this is serious enough that it should really be looked= at. Have you seen the graphs of recovery probability against number of connections? It's pretty bad. The big idea is to use Fluherer-McGrew biases+Hidden Markov model algorithms. That's assuming no more cryptanalysis results. I don't think that's a good assumption. > >> Yes, people could use it tell others that it's deprecated, >> but I think there are already more than enough places that say so >> that having this RFC isn't really going to make a difference > >> I do agree that we need to try to get both sides to stop using it, >> and I wish we could just tell people to stop using it and that >> they would do so. But I don't see either the server or the client >> side wanting to break things. It would clearly help if they could >> say at which point they wouldn't mind breaking things > >> So I think that for now the best we can do is: >> - Servers should either stop accepting RC4 or make sure that >> if the clients supports something better (TLS >=3D 1.1?) it should >> not pick RC4. > > I would think there would be very few if any clients out there that only = support RC4. But I would expect some servers out there do no support RC4 al= ready. > Although I have no actual data to support my gut feeling here, and would = be glad to be proven wrong. It's a server-side workaround for BEAST. Not all old IE versions have 1/n-1 record splitting. I'm part of the problem here: my dad refuses to get a new computer, so IE6 on XP it is. However, old IE isn't vulnerable without plugins. Vanguard.com is a website using RC4 on modern browsers. The reason for this is partly BEAST and partly a misconfiguration in which they support TLS 1.2, but still want RC4. It's this sort of issue which we can solve easily. Removing RC4 from browsers wouldn't break them. > >> It's my understanding that the client preferences of ciphers >> should be used but that servers can override that, and that >> there might be good reasons to do so. For instance to get PFS >> when talking to Internet Explorer. If they override it, they >> should make sure not to put RC4 first. Basically, a mondern >> client should never get RC4. >> - Clients should not announce support for RC4 in their initial >> connection attempt, and only fall back to support it when the >> server says that there are no common ciphers. (I'm not sure >> if a MITM can fake that response or not.) >> >> At some point in time when the clients or servers think that they >> don't need to support RC4 anymore they should disable it. >> >> >> Kurt >> >> _______________________________________________ >> 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 Sat Apr 19 13:10: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 26B181A00A5 for ; Sat, 19 Apr 2014 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9wKjovgsuQK for ; Sat, 19 Apr 2014 13:10:25 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id D83391A0055 for ; Sat, 19 Apr 2014 13:10:24 -0700 (PDT) Message-ID: <5352D82C.2030302@akr.io> Date: Sat, 19 Apr 2014 21:10:20 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> In-Reply-To: <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eGjta3YnDQgrjpqUmHGfPkdF_1M Subject: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 20:10:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19/04/2014 20:28, Yoav Nir wrote: > As long as the client is required to support such servers, I guess > we have to live with it. I think the only correct deprecation path to recommend is the one that's on the table right now: the off switch. Warn your users if you have to. But don't negotiate RC4 without a click-through warning. RC4 is either on the brink of being cracked, given the serious known weaknesses pointed out in Section 1 of the draft, or it is already over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were talking about that they got from NSA, and that seems plausible to me, and to several others, including Schneier). If it's on the brink, then when it's cracked, captured traffic can (and will) be retroactively decrypted. If it's over the brink, that's already happening. That window of opportunity was widened by advice given to use RC4-SHA to avoid BEAST, which is why some servers prefer RC4 to AES-128. (That was very bad advice, with 20:20 hindsight.) We need to close that window now. As you've seen in this discussion, there is only one safe way to close that window: disable RC4 completely. Any delay in disabling RC4 leaves that window open for longer, and leaves users subject to a false sense of security about their connections that should be protected by that little 'lock icon'. I don't think we can in good conscience recommend any delay. That's why the draft we have strong consensus on is crystal-clear: o TLS clients MUST NOT include RC4 cipher suites in the ClientHello message. o TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message. o If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case. In short: RC4 is Considered Harmful. Kill it with fire. On 19/04/2014 20:54, Kurt Roeckx wrote: > IE on XP is known to only support 3DES, RC4, and some export > ciphers. Firstly, of those options, they're all bad. 3DES is the less awful option in my opinion (because BEAST is an active attack, but RC4 is or will be vulnerable to a passive attack applicable in retrospect), but none of them are recommended. But, reminder: support for Windows XP ended 11 days ago. It's now off life-support... it's got bigger problems than even 3DES. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTUtgsAAoJEOyEjtkWi2t6vUMP/jPu/pPVELPORfPfhyN7sxCV +6WrH6T933A/2RgkvvIHGXovMWceu95Kf9yT8qQSsbG3kIJIoFYSr+cMSa0+2F7r +cELTer21kavBgHlxJuS2plAZbgU72J1AYhkC5CxyHG6cUW5vAXmBDTSqOJikdks j5/NiClm9hh0EiKgkTBvcAsmt9I/md6RIP9kEgwlgwCXTakjWG2xY3PCTJoLC3ta ryb6HGyBD4dUlOAexh8ttBc5pei1hjTvrM3fDxXHLtLB/WGEuE24Ljf5UzBeLGli WFgMTmy8nGXSDgQgLTzkhX4IQSDI8vRd9H7NP3aKVyxPyjILShEuR08OEYgW21Vf G74tkB3LwToKRvvrZlv99/W7R0sIFRkqA8Zwq/9/TwqSWMwrbkn3x75GG35jEa98 LpX9OXvr1Q6nVEwL9S3vR8kFMggRMG0WZ6ypbF13AcrCzxDckC/gp3kFPstRlf1T k+C4b88FTexBNk6L00s2crrvLs8mcjBCWbPlT9ylYTA1Y9bZjdW3jU4JQ20haplb Qto5NIKPI0StmYaQ5ApKfN7UDAFqLZwD6SUxDFgfANbssvPKsEi/6zhiNLXEhydp QB6o7PAtHsZvVkdBpvjPB0DOEPbTsb7sSagK41rGReZDcX8WoKL2l4/i4noFmmYJ QRik78o7c2X5zdKam8Rm =0nHD -----END PGP SIGNATURE----- From nobody Sat Apr 19 13:41: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 7C62C1A00D5 for ; Sat, 19 Apr 2014 13:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 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, URI_NO_WWW_INFO_CGI=2.071] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL-WjI2mJCrL for ; Sat, 19 Apr 2014 13:40:58 -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 1C89F1A00CF for ; Sat, 19 Apr 2014 13:40:57 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id d17so2599231eek.15 for ; Sat, 19 Apr 2014 13:40: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=VpwkRGNPCnl+oDKQQkzuQj2F7fQ/3txld8Xp+kUZTW8=; b=rCR+IlcmZwr0B16gND+oiMnRAhPmr8zNRoMMMXJwkPoZ1eJY1v7+8ztqD4EIqvYqv+ Z3En6b9opTBaBJvuLLZlslpqR2s6wqHLtWPWZqoIl8OMKtSjbiFW8eM6Fu4+oeHgyQwH DImum6HpM4nEoL+pkgKtlfI/yY9R4y5/x0KQpV/b6g0GX8HemTTPrbBnXbeedf/Iv5AB 5UtRpZFzpJkAAmMSWbzkIqC+5aVNCKmZGNbb+kSAN2yTkeVVuCMmyWtZ8Pg8m7edoxF1 qmOIqqgNYP8VSwN5NUHXvBMSFVNIAgBvgiNMHb42IRc+x5aXtr8cwPbCPnZ9Fde31Cjm 0IQA== X-Received: by 10.15.22.201 with SMTP id f49mr33201878eeu.18.1397940053161; Sat, 19 Apr 2014 13:40:53 -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 o7sm88549057eew.25.2014.04.19.13.40.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 13:40:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <20140419195434.GA21513@roeckx.be> Date: Sat, 19 Apr 2014 23:40:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <812BA37F-C06F-4316-8747-B7C11F8847D5@gmail.com> References: <20140419131019.GA29561@roeckx.be> <20140419195434.GA21513@roeckx.be> To: Kurt Roeckx X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Vixz6HWUgchS1vlrS1BYCKwGxoU Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 depreciation path (Re: Deprecating more (DSA?)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 20:41:02 -0000 On Apr 19, 2014, at 10:54 PM, Kurt Roeckx wrote: >=20 > For stats about servers, see: > https://www.trustworthyinternet.org/ssl-pulse/ > https://jve.linuxwall.info/blog/index.php?post/TLS_Survey Oh. Doing ephemeral diffie-hellman just to then use the results to = encrypt with DES. And over a quarter of the servers do this. I have to = wonder how many of the (at least) 379 servers that support NULL ciphers = actually meant it. Or of the 14% who support RC2. From nobody Sat Apr 19 13:51: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 3CB611A00CF for ; Sat, 19 Apr 2014 13:51:08 -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 pxP22s5lGnKz for ; Sat, 19 Apr 2014 13:51:03 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6761A00A7 for ; Sat, 19 Apr 2014 13:51:03 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c13so2587031eek.37 for ; Sat, 19 Apr 2014 13:50:58 -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=UF8JQQqXcOTs6fq+fNoWoFwFNdO727oqTG5Rf4mpujo=; b=RzPdhRSF65s9CwDqcaFl+FYK6oftCYACff5vjlcHltZbjxyB6wx/NSduT/JeLU/cQG p5z9A66ARwP9w90OB2J6k/zHC+8SGPxtUhgXamNmaOvxe7rswPrwl7LjPD7W5klZuVSb kKBAxLBquaEjYBcrUr+92LOq9ZnmZ0q0+us4W8+AjvckZXgRBpv2WPUY3nsbzaCEpK6y 59vPdfMaYGs177TUseOzYfqI1rKL6RlivFs/OqRhnmQmVHu20Iegz2u8Qrt9Jq5p+5OW xzqS3ofzyh57EFu3yb6YerOmYG5AX+0TzCL6rav8WOeG7blbs+bvuuG9b0As1DIlZXuJ zKAQ== X-Received: by 10.15.51.141 with SMTP id n13mr33285717eew.17.1397940658687; Sat, 19 Apr 2014 13:50:58 -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 z48sm88612551eel.27.2014.04.19.13.50.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 13:50:58 -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: <5352D82C.2030302@akr.io> Date: Sat, 19 Apr 2014 23:50:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> To: Alyssa Rowan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kfMOODX4YH2YGIKiFo1M4XOEGXg Cc: tls@ietf.org Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 20:51:08 -0000 On Apr 19, 2014, at 11:10 PM, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 19/04/2014 20:28, Yoav Nir wrote: >=20 >> As long as the client is required to support such servers, I guess=20 >> we have to live with it. >=20 > I think the only correct deprecation path to recommend is the one > that's on the table right now: the off switch. >=20 > Warn your users if you have to. But don't negotiate RC4 without a > click-through warning. I can probably do it, as long as I provide a configuration to re-enable = it. But that=92s me.=20 Check out the survey that Kurt posted a link to. 1.56% or TLS servers = support only RC4. Browsers are distributed for free, and each of the big = ones is installed in hundreds of millions of copies. They can=92t afford = having support calls, and they can=92t afford the bad publicity that = comes with =93some sites don=92t work with this browser=94. What = Microsoft is doing is the best we can hope for for now. Yoav From nobody Sat Apr 19 14: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 4E2F01A00C9 for ; Sat, 19 Apr 2014 14:07: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 S5z-lchmVzRZ for ; Sat, 19 Apr 2014 14:07:32 -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 B0AD51A00A5 for ; Sat, 19 Apr 2014 14:07:32 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so2358357yks.33 for ; Sat, 19 Apr 2014 14:07:28 -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=KeY4JZ7omW6Kwz7P3D0qGrh8GfbxMwP8OhfA1mUOgCU=; b=uxjlCiPAerdjnYw42O6dqz4ksKTki0VcTSaWvf3p7GdhadvmbRkzkblG0mLIEDCflp bc0tkVYEUHPxgGm0ES8w5LmX6R7P7R6EumhaFbZAfzMoVNriJXNAOSeB60QzJp+MDH+U CAJSCnIUoo95tSPMeQhAl/MpsTgfRwcCyUPYXG7iK2H2f/pMUd8JEan5yw9wYexU9iO/ HSAERetTe6iYjfo5QTgUI72yWJ6zNN0BdfwByqNNhvp5I/vL+1xfaa8DAFLJWBTLH5y5 7lVxiQnA1EQv3QGbeNBfn9IjtYB3FpZjHFsAdUCcL7hkqsYxGJP3/3ZWZEIIDC6j/8kj KTmg== MIME-Version: 1.0 X-Received: by 10.236.147.10 with SMTP id s10mr4472272yhj.88.1397941648205; Sat, 19 Apr 2014 14:07:28 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sat, 19 Apr 2014 14:07:28 -0700 (PDT) In-Reply-To: <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com> Date: Sat, 19 Apr 2014 14:07:28 -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/pUJv4M3prPN3WtYe7EPfhafaX5Y Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 21:07:47 -0000 On Sat, Apr 19, 2014 at 1:50 PM, Yoav Nir wrote: > > On Apr 19, 2014, at 11:10 PM, Alyssa Rowan wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 19/04/2014 20:28, Yoav Nir wrote: >> >>> As long as the client is required to support such servers, I guess >>> we have to live with it. >> >> I think the only correct deprecation path to recommend is the one >> that's on the table right now: the off switch. >> >> Warn your users if you have to. But don't negotiate RC4 without a >> click-through warning. > > I can probably do it, as long as I provide a configuration to re-enable i= t. But that=E2=80=99s me. > > Check out the survey that Kurt posted a link to. 1.56% or TLS servers sup= port only RC4. Browsers are distributed for free, and each of the big ones = is installed in hundreds of millions of copies. They can=E2=80=99t afford h= aving support calls, and they can=E2=80=99t afford the bad publicity that c= omes with =E2=80=9Csome sites don=E2=80=99t work with this browser=E2=80=9D= . What Microsoft is doing is the best we can hope for for now. What happens 5 years from now when those servers still aren't updated? I think the best we can do is stop configurations of new software from supporting it. Furthermore, we need to ensure that we never face this situation again. RC4 needed to be depreciated starting with WEP. In the future we will need to have much more aggressive depreciation, better guidance on what to support and in what order to prefer ciphersuites. Sincerely, Watson Ladd > > 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 Sat Apr 19 14:39: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 C80671A0033 for ; Sat, 19 Apr 2014 14:39:28 -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 ZLg3XOizxdqH for ; Sat, 19 Apr 2014 14:39:25 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id AD2811A00A5 for ; Sat, 19 Apr 2014 14:39:25 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x3so2790236qcv.40 for ; Sat, 19 Apr 2014 14:39:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HQMq3ptDmAAjFVDpePxpzpg2ObAgrvEBVSg8g9TJDCk=; b=LoDnW/S/ZTdm0oh8xFVN5m4i25ybaofIHc+dup/zY5RkVGeYWkhM8tK7nUHtR8D3LH jzAZ/emHzvMiph8Vpk+y212usb00xadVtNfcFuReZFmKO6ZFy7J52tpMVIzpYp848nMh KoEClGxjtJc4kdEbUgzHQLyC1W/zWRIThGbNPO+iG5/dLiIrg3YLewfxfE3C4oCWjkZk sMeSSimmY4HsTdZzbFi+j6oN3CruvtAtdj3wUHZY5FRQaznzF5Pu9sxRMR1XehTgQSFQ wr5rpmgDNvlwXDgT7bIOr7bxWOmAJjxnO+wkawtUOUfpnJBp4RtTGv3ZLnJoWQ7fiA67 +yUA== X-Gm-Message-State: ALoCoQlkwXGUjUgM0XT4k88sHYMD1KTGXFe5LDV/8qLpg5LSl4x0qU0ZNZjTOYVv59ZOBu46X7Gl X-Received: by 10.224.2.131 with SMTP id 3mr28325034qaj.71.1397943561143; Sat, 19 Apr 2014 14:39:21 -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 r4sm63721750qat.16.2014.04.19.14.39.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Apr 2014 14:39:20 -0700 (PDT) Message-ID: <5352ED0E.4090203@nthpermutation.com> Date: Sat, 19 Apr 2014 17:39:26 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Martin Thomson , Paul Lambert References: <53513F36.7050106@nthpermutation.com> <53515BDF.7010909@nthpermutation.com> <7BAC95F5A7E67643AAFB2C31BEE662D0197DEF8FAC@SC-VEXCH2.marvell.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/Vjln43c54H6fJoDZk6xwSFv7pbk Cc: "tls@ietf.org" Subject: Re: [TLS] PRF Negotiation - Finished "gotcha" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 21:39:29 -0000 On 4/18/2014 4:28 PM, Martin Thomson wrote: > On 18 April 2014 13:26, Paul Lambert wrote: >> Specifically for the data path. SHA-256 is appropriate key management, generation etc. > The PRF is only needed for key management, generation, extractors, > etc... I think that (perhaps) Mike wants to go one further and be > able to ship a stack that doesn't even HAVE SHA-256. > > Exactly. There are a pile of cheap chips out there that implement AES but don't implement a hashing algorithm (and strangely vice versa). On the software side, the tradeoffs between performance and space for the SHA functions are interesting choices. On the other hand, I can't find any "standard" block cipher based hashing functions. There are a number of proprietary and a number of "standards proposals" (e.g. to the SHA3 competition), but none that's showing up as a NIST/ISO/IEEE/IETF approved hashing function. And please ignore my CMAC('0', data) suggestion. It was pointed out to me (something that I used to know) that CMAC with a known key lacks collision resistance. Mike From nobody Sat Apr 19 15:41: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 CF2D51A0090 for ; Sat, 19 Apr 2014 15:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcMn4xUA0dMm for ; Sat, 19 Apr 2014 15:41:19 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4692C1A0102 for ; Sat, 19 Apr 2014 15:41:18 -0700 (PDT) Message-ID: <5352FB8A.3070109@akr.io> Date: Sat, 19 Apr 2014 23:41:14 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com> In-Reply-To: <2E68BD96-A94F-4965-82AA-E8E6B314F1E7@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/59Ui5ZW-igHNR7z2f5-QWTDYiiE Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 22:41:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19/04/2014 21:50, Yoav Nir wrote: > I can probably do it, as long as I provide a configuration to > re-enable it. But that’s me. Great. A good start. (Suggestion: Put a big fat warning on that config option so no-one who re-enables it can say they didn't know what they were getting into?) > Check out the survey that Kurt posted a link to. I'm well aware. Sorry state of affairs: so, what can we do here to make it better? Maybe a little. > 1.56% or TLS servers support only RC4. Partly because of PCI compliance testers making noise about BEAST, I'm thinking. An RFC strongly deprecating RC4 can only help reduce that number: those same PCI compliance testers can be pointed towards that as 'best industry practice' - and may fail them for that? Their remaining solution? Probably TLSv1.2 AES-GCM. It _could_ work? I'm not saying it will, but it's the best option I can come up with. > they can’t afford the bad publicity that comes with “some sites > don’t work with this browserâ€. What I'm suggesting is: Don't blame the browser. Blame the site. It's the site that only wants to use a bad cipher. A warning lets you place blame where it belongs, depending on how you frame it.... "! The site uses insecure ciphers! You attempted to reach %s but the server only offered to use an insecure cipher, RC4. [RFCabcd, 2014] specifically warns that the RC4 cipher MUST NOT be used anymore, because it is dangerously weak. You should not proceed. If you proceed, an attacker could capture data that you send and read it in the future, including passwords and credit card numbers." ...blah blah, evil hackers will eat your babies etc. The point is, the impression you want to give to the user is not "browser X throws up errors with this site, shouldn't X fix it?", but "I'm seeing warnings that site Y is insecure, shouldn't Y fix it?". Of course, I'm being thoroughly idealistic here, assuming anyone ever reads anything, no matter the colour or font size, and users won't click through agreements for their mortal soul and give up their passwords on the street to a woman with a clipboard for a Mars bar. The cynical side of me is more aware that browser veterans are pragmatic, headdesk about this issue regularly and are used to whatever changed most recently getting the blame for whatever happens, no matter what. That's why I'm suggesting a warning with an option to retry insecurely rather than fail, or something kind of like that, but I'm broadly aware of the difficulties they face. That's more a matter for them, of course. What we can do here is, well, what we _are_ doing. What we can. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTUvuKAAoJEOyEjtkWi2t6uj4QALYYY3+dWiBUiihdoQYVA01S +S6c4Vgg/+xMRIirruIyQQhXkMRdAKIZk5rFIEv+cpjSm8flx6a5AdXCErcKrCnp t2GPtk+K8fBjEGBziPsOGTEtOtI7M/rN5r9uoWO+lIeW7yX7tntyYpP1MYd8/GBQ h4MNZ4ScPYCWJTsrn2h77QFFWxjK0KyhzFj3d7+dB2Z7iaGN44ubz+BijPBxmWuL OvL7cqduO7hUZ+G9rGTUZH4mlez9b4tDpg99780ekjbBap8GE3iUuM5aDZ/zDk3R istwUrREfq3VGk+NcecN2Jz1tayC7RIF8puvoi2PFPeTYXXdYXeVozyVtxFZWE45 i9TeU5V4AvSdQpxHzPIqpa+wDc2T7NGBOxfm2vRJI0D/IGt0ADsP9MaF3SCKP1zu ls8gv/hzwo/fOgoKd4gbzqWhVIUval0HUMmRbNmqwXD+hpoF2FZh7OAvPFl8FRRp 5VU8kYKIZqdrgiCHxV8TxR+A7yPc7nAvO7jaG7MYMCzdYIvBwSSWtNQ0HSlV24Em 8SZBxM653V7YdNHsPGMaBxd0nJ/fIvbktAgcTxxmkQO9tux4XM9ImD9EZfDIxgKJ LvxQGMIPDAXHPVqvswg/jLtLT3b1ZY16KZk9gxJxKiLkfeo76ev1E28JxJzR26qU mLgPRjiH/qSKDlsVNsFS =HsbX -----END PGP SIGNATURE----- From nobody Sat Apr 19 16:17: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 963F01A008A for ; Sat, 19 Apr 2014 16:17:11 -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 3vCJC8NWv9wP for ; Sat, 19 Apr 2014 16:17: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 F423B1A00B2 for ; Sat, 19 Apr 2014 16:17:06 -0700 (PDT) Received: from [174.252.33.205] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WbeVI-0006XH-SK; Sat, 19 Apr 2014 19:17:01 -0400 Date: Sat, 19 Apr 2014 16:17:00 -0700 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7953dfa3f948be7a31f2d292e02d531489350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.252.33.205 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R2XwUlO2b0HmNJnpmACPTpHUEqA Cc: tls@ietf.org Subject: Re: [TLS] Deprecating more (DSA?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 23:17:12 -0000 On 4/19/14 at 10:44 AM, watsonbladd@gmail.com (Watson Ladd) wrote: >On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz wrote= : >>The other use case to always keep in mind is limited performance devices. >>With the Internet of Things, we will continue to see new 8 bit, and possi= bly >>even 4 bit processors as manufactures drive in the direction of the small= , >>low power, and cheap. These devices will be much safer if they have >>authentication and replay protection. While secrecy is probably not as >>important, it might also be vital in certain applications of these device= s. > >So AES-CCM fixes one issue (the wire PDU), but we really, really, need >a hash for the handshake. These devices also might not even have >random number generators that aren't deterministic or a counter to >avoid replays. There's a lot to be done: benchmarking, thinking hard >about protocol problems that might cause issues, determining what we >can and cannot provide. One way to address the random number problem is to use the=20 protocol that most web sites used with SSL. In that protocol,=20 the client generated the random number and encrypted it with the=20 server's public key. With the Internet of Things (IoT), having=20 the controller end, which usually has a UI and lots of=20 opportunity to generate good, unguessable numbers, generate the=20 random number and the "thing" accept it might work well. A way=20 to be agnostic about which was the client and which was the=20 server is a protocol where if either end had good unguessable=20 numbers, the resulting connection was secure would be nice.=20 Getting perfect forward security in this environment might be hard. >From some cursory research, hash functions are the real issue here. >AES is byte-oriented, but Keccak is slow as molasses at big capacities >sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR >benchmark data? We should think about the performance requirements here. If I am=20 instructing my Nest thermostat to warm up the house because i'm=20 coming home, several seconds is more than acceptable. If I am=20 building a light show for the bulbs in my living room, probably=20 1/10 of a second is acceptable, and 1/100 of a second is=20 certainly good enough. >... > >With ECC life can get interesting. Drop the idea of RSA and DHE over >F_p: too slow. 8 bit saturated arithmetic is probably the best. >Timings are pretty slow: lots of verifications are a terrible idea. >With PSK you don't need any of this, but I think that some embedded >CPUs have the horsepower to do ECC, even at 8 bits. Make sure that >this happens rarely, i.e. mostly static keys so results can be cached, >and I think we are good. Due to memory pressure ladders are great. Hmmm, my first read had ECC as Error Correction Codes but the=20 paragraph reads a lot better if I read Elliptic Curve=20 Cryptography. :-) When we look at these processors, although the slower the clock,=20 the less power required, there is a limit. If we run the clock=20 much below 1 MHz, we have reached the point of seriously=20 diminishing returns. 100 MHz is much more realistic. Since=20 Elliptic Curve Cryptography gives more security/cycle than=20 discrete logs, it is a very attractive technology. >I've never seen a 4 bit micro. Anyone got details on what they are >like and can do? Look up the Intel 4004 for an early example. I don't know we=20 will see the 4 bit wide ALUs again, but the drive for low cost,=20 low power, and cheap is certainly still alive and well. 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 Sat Apr 19 16:59: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 480281A008F for ; Sat, 19 Apr 2014 16:58:57 -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 5MIpKtwchx9A for ; Sat, 19 Apr 2014 16:58:53 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24F1A00A2 for ; Sat, 19 Apr 2014 16:58:53 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id f51so947736qge.10 for ; Sat, 19 Apr 2014 16:58:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a3k5FQOlQt7OHPFoff6ppCQqtCMhDPqvT8yHQTOoT/s=; b=Oq5NNM4DmL8skvVkY/xDZ0XUYxcLKns0VJgPfTVSaS25cDPERHj7gCcFDAYkISv5En lICHkSkGiJAr1sxBHshT/5lTzEPxF8SlJWPuW3TImfuOq/QWGgopHNSc6Hnp1gZ6XPu/ gSHi5AXp/m1T2GkI7Z1Q6pnWkuvlk91OyxxhOSkWyoCHhi40D91mJl4bYH2ytgjL5A4A 2Ve+xB55nOvlFCYYxnEpYfWDHzIT71YrCk7DuP3j9t+W43VVVPBGlBUBVJXa/vGADsQV mGyfKWST5/XEePGd+AlEiEzIS55Wub+/y0/e0wVFbDwfOx1fOb5upHAW892eoxqhGZYd dkKQ== X-Gm-Message-State: ALoCoQla/xIggI7DxGqtrbJKNyf3+jCtNGFKKh3FruI1bIkQR+wtThVh0DXrPhHNUlFkHv6oGQK1 MIME-Version: 1.0 X-Received: by 10.140.47.206 with SMTP id m72mr23759309qga.21.1397951928308; Sat, 19 Apr 2014 16:58:48 -0700 (PDT) Received: by 10.140.100.205 with HTTP; Sat, 19 Apr 2014 16:58:48 -0700 (PDT) X-Originating-IP: [109.201.138.210] In-Reply-To: <5352D82C.2030302@akr.io> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> Date: Sat, 19 Apr 2014 23:58:48 +0000 Message-ID: From: Jacob Appelbaum To: Alyssa Rowan Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fiQSevUvRU6iWyKpAYHggutkiMs Cc: tls@ietf.org Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Apr 2014 23:58:57 -0000 On 4/19/14, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 19/04/2014 20:28, Yoav Nir wrote: > >> As long as the client is required to support such servers, I guess >> we have to live with it. > > I think the only correct deprecation path to recommend is the one > that's on the table right now: the off switch. > > Warn your users if you have to. But don't negotiate RC4 without a > click-through warning. > > RC4 is either on the brink of being cracked, given the serious known > weaknesses pointed out in Section 1 of the draft, or it is already > over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were > talking about that they got from NSA, and that seems plausible to me, > and to several others, including Schneier). > I think that RC4 is completely broken for certain adversaries. It should be totally abandoned. > If it's on the brink, then when it's cracked, captured traffic can > (and will) be retroactively decrypted. If it's over the brink, that's > already happening. > Yes, I agree. I believe that this is already happening. > That window of opportunity was widened by advice given to use RC4-SHA > to avoid BEAST, which is why some servers prefer RC4 to AES-128. (That > was very bad advice, with 20:20 hindsight.) > > We need to close that window now. As you've seen in this discussion, > there is only one safe way to close that window: disable RC4 > completely. Any delay in disabling RC4 leaves that window open for > longer, and leaves users subject to a false sense of security about > their connections that should be protected by that little 'lock icon'. > > I don't think we can in good conscience recommend any delay. That's > why the draft we have strong consensus on is crystal-clear: > > o TLS clients MUST NOT include RC4 cipher suites in the ClientHello > message. > > o TLS servers MUST NOT select an RC4 cipher suite when a TLS client > sends such a cipher suite in the ClientHello message. > > o If the TLS client only offers RC4 cipher suites, the TLS server > MUST terminate the handshake. The TLS server MAY send the > insufficient_security fatal alert in this case. > > In short: RC4 is Considered Harmful. Kill it with fire. > I agree entirely. RC4 needs to die in a fire. A celebratory TLS 1.3 fire. All the best, Jacob From nobody Sun Apr 20 01:47: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 A6BD81A004A for ; Sun, 20 Apr 2014 01:47:39 -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_20=-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 N_eBacayPu5q for ; Sun, 20 Apr 2014 01:47:35 -0700 (PDT) Received: from vsp4.ballou.se (vsp4.ballou.se [91.189.40.102]) by ietfa.amsl.com (Postfix) with SMTP id 4FBDF1A0045 for ; Sun, 20 Apr 2014 01:47:34 -0700 (PDT) Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp4.ballou.se (Halon Mail Gateway) with ESMTP; Sun, 20 Apr 2014 10:44:23 +0200 (CEST) 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 C1B041DEB7; Sun, 20 Apr 2014 10:47:26 +0200 (CEST) Message-ID: <5353899E.8070601@streamsec.se> Date: Sun, 20 Apr 2014 10:47:26 +0200 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: Watson Ladd , "" References: <5350BF46.7000608@pobox.com> <535141E7.2000001@streamsec.se> 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/mTqU-BqQJvTRQrtaZA2TfFEitYU Subject: Re: [TLS] Kill Finished (and other tricks for hardware) 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: Sun, 20 Apr 2014 08:47:39 -0000 On 2014-04-18 17:39, Watson Ladd wrote: > On Fri, Apr 18, 2014 at 8:16 AM, Henrick Hellström wrote: >> On 2014-04-18 07:59, Michael D'Errico wrote: >>> >>> This is a much weaker failure indication than checking the Finished >>> messages, so I'd prefer to keep them. Can you think of an alternate >>> construction for the Finished message that doesn't use the PRF? >> >> >> Indeed. The client (being the last peer of the connection to send a random >> handshake message, and being in a position to pick the pre_master_secret) >> will have a quadratically improved chance of picking a specific >> master_secret Please note that this relevant in the context of removing the Finished messages and including the handshake hash in the KDF step, because of the following questions: #1. How easy is it for an attacker to pick one specific master_secret as the output of a handshake? #2. How easy is it for an attacker to pick any master_secret, that happens to produce the correct finished messages and a partially chosen key block (e.g. with only one write key chosen) when the handshake hash is not included in the KDF step? #3. How easy is it for an attacker to pick any master_secret, that happens to produce a partially chosen key block (e.g. with only one write key chosen) when the handshake hash is included in the KDF step? (I am not elaborating on exactly what kind of practical attacks would become possible if the attacker picks a partially correct master_secret. It suffice to say that it doesn't seem to be something that should be easy to do.) It seems reasonable to assume that case #1 and case #2 are equivalent, i.e. since the PRF is invoked three times with the same key material (master_secret) and different labels and seeds, picking a partially correct master_secret is not easier than picking the exactly correct master_secret. However, if the PRF is only invoked once with the master_secret as key material and the handshake hash as seed, it is not self-evident that case #3 is as hard as case #1. In particular, #3 might be significantly easier for some PRF algorithms than other. Generally speaking, though, irregardless of the security properties of the PRF, the case of collision attacks ought to be considered. Suppose an attacker is trying to get two different connections to have the same client_write_encryption key. With a 128 bit security cipher suite, this key will be 128 bits, and getting a collision in 128 bits only require an 2^64 effort, even if the PRF is completely perfect. > Care to expand on this? For noncontributory exchanges you may be > correct, but ECDHE is contributory. I am comparing the chances the server has to choose the master_secret, to the chances the client has. - When the server_key_exchange is sent, the server doesn't know what the client will send, so the server has no better chance than random to pick the master_secret. - When the client_key_exchange is generated, the client will in principle be able to predict the master_secret before sending the client_key_exchange message. In particular, if e.g. ECDHE-P256 is used, then presuming the TLS PRF preserves entropy up to at least 256 bits, the server will have on average a one in 2^255 chance of picking the "right" master_secret, because the server is gambling on what 256 bit ephemeral private key the client will pick. The client will however be able to pick the pre_master secret with a 2*2^128 effort (based solely on the DLP strength of EC-P256). Now, for the same reason, if someone proposes a cipher suite that significantly weakens the PRF/KDF (e.g. by basing it solely on AES without ensuring the function is one way), eliminating the finished messages will potentially enable a man-in-the-middle to have significantly better chance than 1 on 2^256 to pick a master secret that is "almost" right and at least results in a chosen client_write_key. From nobody Sun Apr 20 07:13: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 351931A018E for ; Sun, 20 Apr 2014 07:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 v2v8kj5DeMHd for ; Sun, 20 Apr 2014 07:12:58 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with SMTP id 323EF1A018C for ; Sun, 20 Apr 2014 07:12:57 -0700 (PDT) Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKU1PV5U07rwpuhsWDKtpZtUtJ5pB2c9GU@postini.com; Sun, 20 Apr 2014 07:12:54 PDT Received: by mail-wi0-f174.google.com with SMTP id d1so1042051wiv.7 for ; Sun, 20 Apr 2014 07:12: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ymf/TZA/tBt/SWh8j+gRjWg/DPHFyUExe7n4XPGg1V0=; b=V5eQ/Bj0ZYHx+TV5nR4ARS+YW8Gn+9OgFC+4wqqBM0k+71o4alzWLN7iStzIGgk/Uh se3MbZFx+RKgXnNZ1xgLjt8xRfpfIJs3HBUofKZlXSHBQsE6GAzFNfL2FMqHj2Kxj/DK 2iVn9/qUPxZn2WpvqMJc7IbDeSIYrTAWBQcZl9jNXsAAt9CWks7LYejGme4aUKnOIxXE iR1rOfz9Mv0WmSOG2n/AWgUcoNhznAsWPRVASXTYQCsJd1TE8xe16csHfC+YiiVvCtVI gRu1UKWm1rkvpkcPEn1l6OxRFVHAvGUabt9GHtAf1m3waOcRSpYEBrjGoW+5Y0cx4AzA dDSQ== X-Gm-Message-State: ALoCoQki3qbdtbxrKuTDnmcjp7wy3hpkjVnCChr+VAIlM6cELrB0IsmoCnuCkeCxHr2jWmVKCm8KZnNzYSlmgcIQfyev4SCkYBOEyUmx2LzJmOUSmamjjNVF5PKBZZkar2BQkFgYeb9T X-Received: by 10.194.171.167 with SMTP id av7mr24419888wjc.32.1398003172342; Sun, 20 Apr 2014 07:12:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.171.167 with SMTP id av7mr24419884wjc.32.1398003172245; Sun, 20 Apr 2014 07:12:52 -0700 (PDT) Received: by 10.194.77.205 with HTTP; Sun, 20 Apr 2014 07:12:52 -0700 (PDT) In-Reply-To: References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> Date: Sun, 20 Apr 2014 15:12:52 +0100 Message-ID: From: Michael Procter To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tbmCu-1laYzghWA-NjJ5rLUGO9k Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2014 14:13:03 -0000 On 18 April 2014 21:21, Martin Thomson wrote: > On 18 April 2014 12:09, Michael D'Errico wrote: >> IANAC but using a long-enough "magic number" for Finished seems fine >> if the handshake hash is moved to the key generator. >> >> But how long should that magic number be? Currently we use 12 bytes, >> but should it be 16 or maybe even 32 bytes (when negotiating 256-bits >> of security)? Can it be a simple string of zeros? > > Why would it need to be anything at all? As long as you can identify > the message as a Finished unambiguously, that should suffice. > HandshakeType is one byte. Does a single byte Finished message mean that a MiTM attacker that modifies, say, the ClientHello, has a 1 in 256 chance that the server's Finished message will be decoded correctly by the client? Clearly the whole session isn't going to work well after this, but the client is likely to emit a bunch of ciphertext before either end realises the problem. Regards, Michael From nobody Sun Apr 20 09:10: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 B92FF1A000B for ; Sun, 20 Apr 2014 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Mwmp47T3Wt-q for ; Sun, 20 Apr 2014 09:09:58 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 7E74D1A0008 for ; Sun, 20 Apr 2014 09:09:58 -0700 (PDT) Received: from mail-we0-f175.google.com ([74.125.82.175]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKU1PxUVXOMNymhCbRKDExRrybTJPFsqzO@postini.com; Sun, 20 Apr 2014 09:09:54 PDT Received: by mail-we0-f175.google.com with SMTP id q58so3059999wes.34 for ; Sun, 20 Apr 2014 09:09: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LU9kt0EJSLAhmGITrfVnx0aHPbyWxGL1QZ81zs2xgvo=; b=EfMJRmoZB4gm2hRwRqMsRGRHon/4GVy/qnxbwx7RkJLGKXGeIWyNgt7p/eUQ8c6F1B fsxD5gt6TDijeHitjroN2a48Xs+kk1iS7go329RZyiva+NTSdhyzLJT1wJ2qvKJMVcrT KLHQxy0uK+Q/ufvc1VHVurKl+iBZ1dytE5NBY9e4q/qUc1k4PgrO//g1j8t21PF5pqg4 734ujZrAz+SM0kQ5QQ4eBqXKV5r58GUVxpZA1EgxT61QKm22hxzpToqDyFs7tGWD27Lt 0tRGhbcXHL1/xmxj43rpUbeaXraUT36cDAsNdXQlWJXX4t739LUcxQW2dhZb/Xy5tLgb XkSQ== X-Gm-Message-State: ALoCoQmWI9E6P3IhWMNcivreLAA466kfqYu8qVovC0EXAdCrmo/nvByIcp6Q7+tQgu8iCgJnNkMWIYb3K0m0vdN9uFrsqwgThOKT3xfHpn/SlQK2ph2Dyr6NJkE3ybh7gWkOOQNLFwiw X-Received: by 10.180.96.225 with SMTP id dv1mr10419281wib.37.1398010192576; Sun, 20 Apr 2014 09:09:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.96.225 with SMTP id dv1mr10419268wib.37.1398010192402; Sun, 20 Apr 2014 09:09:52 -0700 (PDT) Received: by 10.194.77.205 with HTTP; Sun, 20 Apr 2014 09:09:52 -0700 (PDT) In-Reply-To: References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> Date: Sun, 20 Apr 2014 17:09:52 +0100 Message-ID: From: Michael Procter To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qnhXax9NxfLCGfP5XeynJ_pkDbk Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2014 16:10:05 -0000 I've been reminded off-list about the write_mac key! Whilst my comment is basically true in terms of not verifying the encryption key, it is wrong in that for the Finished byte to be authenticated correctly, the same write_mac key will need to be derived at both ends. On 20 April 2014 15:12, Michael Procter wrote: > On 18 April 2014 21:21, Martin Thomson wrote: >> On 18 April 2014 12:09, Michael D'Errico wrote: >>> IANAC but using a long-enough "magic number" for Finished seems fine >>> if the handshake hash is moved to the key generator. >>> >>> But how long should that magic number be? Currently we use 12 bytes, >>> but should it be 16 or maybe even 32 bytes (when negotiating 256-bits >>> of security)? Can it be a simple string of zeros? >> >> Why would it need to be anything at all? As long as you can identify >> the message as a Finished unambiguously, that should suffice. >> HandshakeType is one byte. > > Does a single byte Finished message mean that a MiTM attacker that > modifies, say, the ClientHello, has a 1 in 256 chance that the > server's Finished message will be decoded correctly by the client? > Clearly the whole session isn't going to work well after this, but the > client is likely to emit a bunch of ciphertext before either end > realises the problem. > > Regards, > > Michael From nobody Sun Apr 20 12:54: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 C204F1A0016 for ; Sun, 20 Apr 2014 12:54:28 -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 MKzCKVtfcSgs for ; Sun, 20 Apr 2014 12:54:22 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by ietfa.amsl.com (Postfix) with ESMTP id E94DE1A000C for ; Sun, 20 Apr 2014 12:54:21 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so3300133qgf.7 for ; Sun, 20 Apr 2014 12:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fujt3PgYcGM/DA0KpaeKLNJf03A7a1OUVoJqyszo8Dw=; b=DGoNQ9eWJDv2gRR3cft+8H6eswsGnZENEDKfeerlg7IltE0KuwNzK1sNx8V2uoTxyG 8RuCfg+U0zwdpuD5jk/ZcilsZe1HIb/9Hh35Iu0QZFHsP06LR2hAjGexkDGWd/8K857A U/7ikbtOZPjCBssCIYwK4qP5AuHiZyHsYu4KJuDNlkWHR17AlB0jU+DkogyliNasT8Ac ZxzLPLluIE0VVluzqloW/rkrC7XJOZqKgX+Y/AhRKTvt0pL69j+KcanEM8cAw8s6QbJr 5up8ePivavFeMAtOOzoaOboU6oWAiwHXglryZrymy6nbIrbPjVIBFA7F59PgebAqFjJr /xZg== X-Gm-Message-State: ALoCoQlyr+UTXUKDxggmOBWagHMdO18/O51KpuYTezKdq3mVUTq1hzBATNHRJtK317OanQmsHGSX X-Received: by 10.224.4.133 with SMTP id 5mr501386qar.22.1398023657068; Sun, 20 Apr 2014 12:54:17 -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 c16sm950441qaw.4.2014.04.20.12.54.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Apr 2014 12:54:16 -0700 (PDT) Message-ID: <535425E8.4050808@nthpermutation.com> Date: Sun, 20 Apr 2014 15:54:16 -0400 From: Michael StJohns 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: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> <53518A8D.4080107@pobox.com> In-Reply-To: <53518A8D.4080107@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tVawMITBsu3Yp0jyMY21b2POgz0 Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2014 19:54:29 -0000 On 4/18/2014 4:26 PM, Michael D'Errico wrote: > Martin Thomson wrote: >> On 18 April 2014 12:09, Michael D'Errico wrote: >>> IANAC but using a long-enough "magic number" for Finished seems fine >>> if the handshake hash is moved to the key generator. >>> >>> But how long should that magic number be? .... >> >> Why would it need to be anything at all? As long as you can identify >> the message as a Finished unambiguously, that should suffice. >> HandshakeType is one byte. > > Oh, I see, as long as you can decrypt the record layer, you know it's > working. There's a question here as to whether or not there's an attack that's enabled by changing things in the handshake that don't affect the production of the key material. E.g. addition or subtraction of offered or accepted extensions for example. In some ways, the right answer might be to do a finished signature not over the messages, but over the content of SecurityParameters - with assumption that the SecurityParameters pseudo-structure is extended to provide enough information about offers and acceptances. Mike > > Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Sun Apr 20 13:22: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 730F01A002B for ; Sun, 20 Apr 2014 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHEY4b4xb4-E for ; Sun, 20 Apr 2014 13:21:54 -0700 (PDT) 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 E6EB31A0020 for ; Sun, 20 Apr 2014 13:21:53 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so2959934yha.16 for ; Sun, 20 Apr 2014 13:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gVszYKuH4UX9+IjTCqnZ1/wisG31E8UeTt3BCpesHBg=; b=wf3mr7Nu1tUevVSPy22ORX6QmLwUFZ25gza2CBIBpbw02eXp81bvteAh3PvvjxHPgi REN4HnrphFFxdIH6D1hEA//Zc5v1jaV5wKS9E+pu2hD2VC7gjpVkXd8mQ7aYu0rBfe3U KApcilMt/y+rBLME5NKCKsmDfSuV5Q7Y3rL584W2JqUUmTsXovrkG65S7rSzpFTz8LN0 UjcbGp5wHozruviRuwia/UJrWQrgp2ZtjZzkkdS7K2o1QHOmmzZHzGzT2DysDR9GoyaU rRKRyVvKybawOomDhjfcSOQW/HMj3GhsRYwfgvQnZ/U4T0Iqw8VMQFDuVlZB/+VAFKlQ 0k+A== MIME-Version: 1.0 X-Received: by 10.236.206.7 with SMTP id k7mr4447128yho.84.1398025308791; Sun, 20 Apr 2014 13:21:48 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 20 Apr 2014 13:21:48 -0700 (PDT) In-Reply-To: <535425E8.4050808@nthpermutation.com> References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> <53518A8D.4080107@pobox.com> <535425E8.4050808@nthpermutation.com> Date: Sun, 20 Apr 2014 13:21:48 -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/RVaXj8-Hw5WvWFWYzZosDlFmt_8 Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Apr 2014 20:21:58 -0000 On Sun, Apr 20, 2014 at 12:54 PM, Michael StJohns wrote: > On 4/18/2014 4:26 PM, Michael D'Errico wrote: >> >> Martin Thomson wrote: >>> >>> On 18 April 2014 12:09, Michael D'Errico wrote: >>>> >>>> IANAC but using a long-enough "magic number" for Finished seems fine >>>> if the handshake hash is moved to the key generator. >>>> >>>> But how long should that magic number be? .... >>> >>> >>> Why would it need to be anything at all? As long as you can identify >>> the message as a Finished unambiguously, that should suffice. >>> HandshakeType is one byte. >> >> >> Oh, I see, as long as you can decrypt the record layer, you know it's >> working. > > > There's a question here as to whether or not there's an attack that's > enabled by changing things in the handshake that don't affect the production > of the key material. E.g. addition or subtraction of offered or accepted > extensions for example. There absolutely is in TLS 1.2 and lower. Remove a supported curves extension and you cause a fallback to non-PFS ciphersuite. Maybe that is "affecting the production of the key material", but it's only noticeable in the ClientHello. Also, remove secure_renegotation and life can get interesting again. > > In some ways, the right answer might be to do a finished signature not over > the messages, but over the content of SecurityParameters - with assumption > that the SecurityParameters pseudo-structure is extended to provide enough > information about offers and acceptances. Why bother when we have the transcript which gives us exactly that? What you propose can work, but if we mess it up it won't be pretty. Furthermore, if an extension isn't actually authenticated that's a rather big semantic gap. Suppose ALPN wasn't authenticated, and the same string could have two different meanings under two different protocols. The right answer is never to remove properties TLS provides today. Sincerely, Watson Ladd > > > Mike > >> >> Mike >> >> >> _______________________________________________ >> 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 Mon Apr 21 08:40: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 CA1281A0004; Mon, 21 Apr 2014 08:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTgcgGix-dK3; Mon, 21 Apr 2014 08:40:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6311A0221; Mon, 21 Apr 2014 08:40:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421154018.21785.72950.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 08:40:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H-0UlYSqN5wLDwK30YzAW_Lbqao Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension' to Proposed Standard (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, 21 Apr 2014 15:40:22 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension' (draft-ietf-tls-applayerprotoneg-05.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ Technical Summary This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. Working Group Summary The main point of controversy with this document was on encryption of the extension. The working group decided a cleartext extension with the future general facility to encrypt extensions in TLS 1.3 was preferable to an extension specific encryption mechanism for ALPN. Document Quality A number of vendors have implemented the protocol specified in this document. This document was also reviewed by members of the HTTPbis working group as it is useful for indicating what protocol is carried by TLS. Personnel Joe Salowey is the document shepherd. Sean Turner was the responsible AD. Stephen Farrell took over. RFC Editor Note Please modify the abstract as follows: OLD: 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. NEW: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. From nobody Mon Apr 21 11:54: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 21DB71A0251 for ; Mon, 21 Apr 2014 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id segOi0EVWq4e for ; Mon, 21 Apr 2014 11:54:09 -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 F2C791A0240 for ; Mon, 21 Apr 2014 11:54:07 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so2179470wib.11 for ; Mon, 21 Apr 2014 11:54: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=knfkVO6V1y5U/itDWYqSuG9q1EJa9WIlKK1fbrHlq1s=; b=TprVsGFk2kggPuOFK0vCIzYDplR4jfUwvCs7YK+HONm2GSKKXxUIkPM9X1hXZOxH2e dmYzFfclxEqRDiKsN6CmahafndtO+JP1YUrw6T3NuxXT1lnI9/da1198o7aetkTfxq89 MODZNaP0hV6qd8fC+hlBM9jBLCXjiuVhG5/+Df0ej6qTOZfz6vg4O8l3qrCOVD9LcjcL 8iLl77zhHOGs8CLj5Rx/LaeG9gSH32VNhp0CXaOtATwzli//H30xAtiAgowWlkti8SQ3 hmOfR0iLz3bYX12mYkODLugmXezVGZq7Qu+cbYC7sD2KFaZWqMSmsCjkeT6sZfHS+Wpk DGbg== MIME-Version: 1.0 X-Received: by 10.180.189.65 with SMTP id gg1mr15107226wic.56.1398106442227; Mon, 21 Apr 2014 11:54:02 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Mon, 21 Apr 2014 11:54:02 -0700 (PDT) In-Reply-To: References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> <53518A8D.4080107@pobox.com> <535425E8.4050808@nthpermutation.com> Date: Mon, 21 Apr 2014 11:54:02 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5MwCRVl-VK5TuOLGa94xCGAfog0 Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2014 18:54:11 -0000 On 20 April 2014 13:21, Watson Ladd wrote: > Suppose ALPN wasn't authenticated, and the > same string could have two different meanings under two different > protocols. The right answer is never to remove properties TLS provides > today. I certainly have a use case that depends on ALPN being protected by the handshake. And I think that Watson's more generally right here. The basic guarantee is that the entire handshake is covered, either by Finished (as in TLS 1.2 and earlier), or by using it as input to the PRF (as Watson has proposed). From nobody Mon Apr 21 18:01: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 AB2EE1A0329 for ; Mon, 21 Apr 2014 18:01:02 -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 wdNqFxwvE7BM for ; Mon, 21 Apr 2014 18:01:01 -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 8DCC81A00C2 for ; Mon, 21 Apr 2014 18:01:01 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so4003554ykp.6 for ; Mon, 21 Apr 2014 18:00:56 -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=6E2vnK0mWyqb/NucY1ynnkNJnv9AzvkYZvuDsZEr5Qk=; b=eCjdf+s+31IMeSGV3yVY49KVXjo9GA7VG1PQKSgtBqHQsIMEs82EBNJ88EWnUhga+4 ciN7+bRfcDOsfEnQ0gyCoY50SjLE2ZVcKP1no8UTkTD5chQlqw3iR+CJMMnnoFq4d3UE Fn7iqRtbWTZOo2oZxUhkvt92+5v9ZsL5XZXQSU7wGGC8iG1QCHIOHARmiRFByvVcwb/9 XKh/vt57aezUHdU/FI8pRUlowZQPaXVfSjUvKPhUDb4hO09Ms+CoLxSh9ixOHJRa8m2D 7NJRTuwcddYFG/d+A4AK5+zeHhibhcq2kyA/Jj8NU8vLcWcr29iIUOMn97Mw9+bkbwFr Ec6w== MIME-Version: 1.0 X-Received: by 10.236.142.204 with SMTP id i52mr56228862yhj.6.1398128456247; Mon, 21 Apr 2014 18:00:56 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 21 Apr 2014 18:00:56 -0700 (PDT) Date: Mon, 21 Apr 2014 18:00:56 -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/cf6iH9arK01Sa0k5IENXIDtFtLo Subject: [TLS] RFC 4492 and HSM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2014 01:01:02 -0000 Dear all, RFC 4492 specifies an ECDSA signature of the server's curve parameters and ephemeral point, but not any fresh data. As a result the ephemeral exponent is equal in sensitivity to the long-term exponent of the ECDSA key, forcing an HSM to protect both, and thus do three exponentiations per connection. If an HSM has limited signing power compared to the CPU of the machine it is attached to this is a real limitation. An extra layer of indirection, in which a time limited key is signed by the certificate, avoids this issue, but is not currently supported if I'm reading everything correctly. Triple-DH handshakes partially mitigate this issue, reducing the online impact to one exponentiation per connection. If this wrinkle doesn't get ironed out I'm not terribly unhappy. But if we are going to do major surgery on the PRF and related things, the ECDHE handshake is exposed anyway. Sincerely, Watson Ladd From nobody Mon Apr 21 21:07: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 9DFC71A004A for ; Mon, 21 Apr 2014 21:07:37 -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 605spaqEuLCQ for ; Mon, 21 Apr 2014 21:07:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B1E031A002F for ; Mon, 21 Apr 2014 21:07:23 -0700 (PDT) Received: from [192.168.13.159] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 83074F984; Tue, 22 Apr 2014 00:07:16 -0400 (EDT) Message-ID: <5355EAF4.1020603@fifthhorseman.net> Date: Tue, 22 Apr 2014 00:07:16 -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: Watson Ladd , "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="C08B3pUgc9PmM0VbWrkV9HKiNR8wsXLIi" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0X0KtJZeyRR2MwasyBBpWD4tsZE Subject: Re: [TLS] RFC 4492 and HSM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2014 04:07:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C08B3pUgc9PmM0VbWrkV9HKiNR8wsXLIi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/21/2014 09:00 PM, Watson Ladd wrote: > RFC 4492 specifies an ECDSA signature of the server's curve parameters > and ephemeral point, but not any fresh data. As a result the ephemeral > exponent is equal in sensitivity to the long-term exponent of the > ECDSA key, forcing an HSM to protect both, and thus do three > exponentiations per connection. It looks to me like RFC 4492 specifies that the data signed includes both the ClientHello.random and the ServerHello.random: https://tools.ietf.org/html/rfc4492#page-20 fwiw the traditional discrete-log-based DHE key exchange includes the same data in the signature: https://tools.ietf.org/html/rfc5246#page-52 I would consider this "fresh data", particularly the inclusion of the ClientHello.random. I agree that if there were no fresh data, then every single ephemeral key used would be equivalent to the server's static public key for reuse by an active attacker, which seems like it would a problem (especially given any attacker's ability to trivially harvest new signatures over novel ephemeral keys). > If an HSM has limited signing power compared to the CPU of the machine > it is attached to this is a real limitation. An extra layer of > indirection, in which a time limited key is signed by the certificate, > avoids this issue, but is not currently supported if I'm reading > everything correctly. Triple-DH handshakes partially mitigate this > issue, reducing the online impact to one exponentiation per > connection. if the ClientHello.random isn't enough protection for you, how are you proposing that the key be time-limited? are we assuming some minimal clock skew? Would stuffing a timestamp in the SignedParams satisfy your concern? What guidelines would we suggest for a client for deciding whether to accept or reject the timestamp? inclusion of a timestamp raises similar concerns about fingerprinting as discussed in: https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime-00#section-1.3= Do you see other ways to mitigate those concerns? > If this wrinkle doesn't get ironed out I'm not terribly unhappy. But > if we are going to do major surgery on the PRF and related things, the > ECDHE handshake is exposed anyway. I think the triple-DH handshake has some very nice properties in general, by avoiding any sort of non-repudiable signature; i'm not convinced that we need to make that radical a change for TLS 1.3, but i'm open to the argument. --dkg --C08B3pUgc9PmM0VbWrkV9HKiNR8wsXLIi 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/ iQJ8BAEBCgBmBQJTVer0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc8WsQAJxo8fsiR2TASTVbKGml5fow cCBU+fbHtcbNbWRCIyF+/hnV1nEujfBEMTN+XvW/GESU42cIOym96EfybQrZT2kw ileXJaMqn2wLz/U6qNztvYwZ0/bRAHCmwUDni7nH8iDvRGksTALX3Pb7EFrQatFv Jc0rY1XsRvfNkDnmq16p7Avs12VNuzwbW9lvI6mTP65QVZ0fbtqgi71ZJBTsOJxh U+1Kh3owxB5mRG5UCopYO0ih7OPMuJmtWJ7i/9uZIoKQMS96lKl45PblBAl1tQ8c CK5QtG0ejztyhGSlUAzGSl9viQPjxfwCwAuVUSC/iBFC/IucwXjW1CrUyjV3nmC9 YZJabHkDRJlcYtd5G8gxM6FyRqY9KBwyPNV1tcP7vPJ7HH+c1tpENvNFxKVdTFu3 w9sKQ/Q1wY2BjoO4M4xYyY8l0rTGVjSCKdeawwB2q+fZqJ6RVncFqOLCwo0z0vv0 RFUzMrNdBSY+3uZkt0mrk4NQQ3r1K6tq8GU3QekcduSUNOKn8i4H4ZcJX0+Bjan3 lOmBaj4BwH/PsCHLqrE7Ci4QVHdQZOxcceOlq+HhfEPNEwHZaSANisoVM7VVvxTX N1jNQ+HaSI2osqYjq04IF/MDeDqZ36O0AuF3ONegY9dV/Jk12zdGXeco7v4/z6tz jNMu/9RjXMMjY6DfTLL5 =+z+A -----END PGP SIGNATURE----- --C08B3pUgc9PmM0VbWrkV9HKiNR8wsXLIi-- From nobody Mon Apr 21 21:10: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 204F01A002F for ; Mon, 21 Apr 2014 21:09: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 8MRg3lhmD_yJ for ; Mon, 21 Apr 2014 21:09:50 -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 C56051A0040 for ; Mon, 21 Apr 2014 21:09:50 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so4110773ykp.20 for ; Mon, 21 Apr 2014 21:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SgOjlGbPdyTpeJwGYF1pBHfsy+deZsiKriVvIWjJ+yg=; b=qFZWAx1vqJOiqkDRY8U5KCGjx72TeJ/rfBDCVsSzNKURS/SdRC2XHYsgz66E+G5eek RJl+/XQcBzm8Ih1gcg1BIF8pwigR00GBNRjNAlF5uwRkTBczetFL0tvmvD9ON0g9KlyK LgmB853O9TRf3lDql5mPnFwCcbl2G26tCGGsGI31THBTSHtzqLfI8+8Wk5PU59O0ByPW HYZ428ALSoCfkpDGgU7Ma3gc4O4u1gb9V4pnMG+lNhXWsyYw1SVJzawM0eCyO5K5y+WX C4EtznyVcAXcZq6yJkJn5LIJtwyssOvmhGgSsbNSSBIez4A9vQoXK6wVdylzmcCF21OH Xekw== MIME-Version: 1.0 X-Received: by 10.236.86.113 with SMTP id v77mr634101yhe.125.1398139785533; Mon, 21 Apr 2014 21:09:45 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 21 Apr 2014 21:09:45 -0700 (PDT) In-Reply-To: <5355EAF4.1020603@fifthhorseman.net> References: <5355EAF4.1020603@fifthhorseman.net> Date: Mon, 21 Apr 2014 21:09:45 -0700 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ghWDRdQTR9CTPiZGtLD3QFip9yg Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 4492 and HSM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Apr 2014 04:09:57 -0000 On Mon, Apr 21, 2014 at 9:07 PM, Daniel Kahn Gillmor wrote: > On 04/21/2014 09:00 PM, Watson Ladd wrote: > >> RFC 4492 specifies an ECDSA signature of the server's curve parameters >> and ephemeral point, but not any fresh data. As a result the ephemeral >> exponent is equal in sensitivity to the long-term exponent of the >> ECDSA key, forcing an HSM to protect both, and thus do three >> exponentiations per connection. > > It looks to me like RFC 4492 specifies that the data signed includes > both the ClientHello.random and the ServerHello.random: > > https://tools.ietf.org/html/rfc4492#page-20 This is correct. I was confused because section 2.2 says the parameters are signed, but doesn't mention the fresh data. Ignore previous email. 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 Tue Apr 22 15: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 915BB1A027C for ; Tue, 22 Apr 2014 15:09: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, 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 QFN7lc2mz5s3 for ; Tue, 22 Apr 2014 15:08:55 -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 1D2031A025D for ; Tue, 22 Apr 2014 15:08:52 -0700 (PDT) Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.921.12; Tue, 22 Apr 2014 22:08:46 +0000 Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.33]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.33]) with mapi id 15.00.0921.000; Tue, 22 Apr 2014 22:08:45 +0000 From: Marsh Ray To: "Sniffen, Brian" , Eric Rescorla Thread-Topic: [TLS] About encrypting SNI Thread-Index: Ac9SbYXhdiDYEiy3R5ypSW7DwlHnYAFrg7cAAAF5JoAAAihjAAAEDgQAAAduIoAABKNTgAAjtNIAAAtlDQAAFRL3gAABWWmAAABDDoAACPT9gAAAc8kAAA/5B4AAAMGRAAAVQESAAANUywAAA59MgAAAme4AAAaECQAAALFTAAAAPnCAAP5kZjA= Date: Tue, 22 Apr 2014 22:08:45 +0000 Message-ID: <84ecbf7b69ca4eccba697e93b287e905@BY2PR03MB074.namprd03.prod.outlook.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <534DB18A.4060408@mit.edu> <566E6D8E-ACD5-4B21-9586-84C149F6A1B9@akamai.com> <5204AB60-0B32-4953-9D3D-C2756883D39D@akamai.com> <5C1699C1-A67E-4CD9-92DA-996451C97B2B@akamai.com> In-Reply-To: <5C1699C1-A67E-4CD9-92DA-996451C97B2B@akamai.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: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(189002)(199002)(24454002)(99396002)(86362001)(83322001)(81342001)(81542001)(20776003)(19580395003)(80022001)(19580405001)(76482001)(99286001)(77982001)(46102001)(15975445006)(79102001)(551544002)(76176999)(50986999)(4396001)(74316001)(74502001)(2656002)(54356999)(76576001)(74662001)(33646001)(80976001)(31966008)(85852003)(92566001)(87936001)(83072002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; FPR:D590C601.2FF25F29.31F3A1EE.52E8D041.2024F; 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/1Ol6_2bubhOiKIZ5VyBUTqpcN7c Cc: "tls@ietf.org" , Andy Lutomirski Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 22:09:00 -0000 On Apr 17, 2014, at 3:20 PM, "Eric Rescorla" wrote: >=20 > One concern I would have is whether we understand the problem well=20 > enough to actually specify this. I'm not an expert in this area, but=20 > weren't there a bunch of concerns about designing puzzles that were=20 > effective without being prohibitively expensive for mobile devices? We think about this problem a lot in the Password Hashing Competition (PHC) See https://password-hashing.net/ The primary driver of the decision to add work factor is the entropy presen= t in the secret, in this case the server name. Too much entropy and the wor= k factor is wasteful, too little entropy and the work factor is hopeless. If the defenders tune the work factor to allow them to process 10000 items = a day with tolerable CPU consumption, then an attacker with similar resourc= es can apply 10000 guesses brute force a single secret. =20 How often is any amount of work factor that's suitable for the defender goi= ng to present a significant obstacle to a real attacker attempting to guess= the contents of SNI? My first impression is to think SNI is unlikely to represent enough entropy= to attackers in practice to make an additional work factor useful. - Marsh -------------------- Boilerplate disclaimers apply. From nobody Tue Apr 22 17:14:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80E1A02AE for ; Tue, 22 Apr 2014 17:14:57 -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 XvRub4j_wWOJ for ; Tue, 22 Apr 2014 17:14:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B7ADC1A02B4 for ; Tue, 22 Apr 2014 17:14:55 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3N0EmF9016798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 02:14:48 +0200 (MEST) In-Reply-To: <5352FB8A.3070109@akr.io> To: Alyssa Rowan Date: Wed, 23 Apr 2014 02:14:48 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140423001448.3E6EA1ACDC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sTAIg9vnzZN_ShVVS2sSCHtPsNE Cc: tls@ietf.org Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) 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, 23 Apr 2014 00:14:57 -0000 Alyssa Rowan wrote: > > > 1.56% or TLS servers support only RC4. > > Partly because of PCI compliance testers making noise about BEAST, I'm > thinking. BEAST was and still is a pretty stupid hype. Even the ssl test at qualys is still making bogus claims about servers not being BEAST-patched. Unless your server is a SSL-VPN server or will boldly execute client-supplied active content, there can not possibly be a BEAST vulnerability in the TLS server. The larger problem with the use of RC4 is that a number of dense TLS clients (e.g. Java) send RC4 cipher suites at the very beginning of the list of cipher suites, and a number of dense TLS server choose the first shared cipher from the list proposed by the client rather then the first shared cipher from the list configured by the server admin. -Martin From nobody Tue Apr 22 21:10: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 552631A0029 for ; Tue, 22 Apr 2014 21:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja0FEWahss8y for ; Tue, 22 Apr 2014 21:09:53 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 252161A001F for ; Tue, 22 Apr 2014 21:09:53 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so382340yha.31 for ; Tue, 22 Apr 2014 21:09: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=PFENIB/oKJEq2lXmkb+8WQqmxD1EnlpGOMdV2J7PpNU=; b=RQauxtlbSAraGQJt0kFKirpVZm5gP1YfLFTm3HFsXdX1JCHg/G1uMBq2sjprGeB6p8 I2ruJFAB+YG4cn4Yw4nOB/FAExK2G865VOCrAHM2ZMa4dchji/3yYF5l9ui+uoMcQPsR jzw1IJQCQMzD0cKelo/kGMVogfNXtQQZTZHmnCI9ZWgjrLgs+t/l1D13XG25IdyPP8kV TMlTIrPNsAmHw3/JzqBvi6N5sg+ZABXSoFhG4HzykcyQV8Z5eEvsQyiQJ3bpABhLztb/ 5QKRXqJ2ATREP4C2AwCKPuJO/3a9eKJPxJi8+eFRWqr7vP7XP8vWHqC+D5rDgJDBUl8L pJ/Q== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr16880988yhi.83.1398226187530; Tue, 22 Apr 2014 21:09:47 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 22 Apr 2014 21:09:47 -0700 (PDT) In-Reply-To: <20140423001448.3E6EA1ACDC@ld9781.wdf.sap.corp> References: <5352FB8A.3070109@akr.io> <20140423001448.3E6EA1ACDC@ld9781.wdf.sap.corp> Date: Tue, 22 Apr 2014 21:09:47 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/94xJn9mu_GCDf98N-bJ6Z1UU6Uw Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 04:09:58 -0000 On Tue, Apr 22, 2014 at 5:14 PM, Martin Rex wrote: > Alyssa Rowan wrote: >> >> > 1.56% or TLS servers support only RC4. >> >> Partly because of PCI compliance testers making noise about BEAST, I'm >> thinking. > > BEAST was and still is a pretty stupid hype. > > Even the ssl test at qualys is still making bogus claims about > servers not being BEAST-patched. Unless your server is a SSL-VPN server > or will boldly execute client-supplied active content, there can not > possibly be a BEAST vulnerability in the TLS server. It's not about the server: if I only offer TLS 1.0, then clients who connect to me who aren't 1/(n-1) patched are vulnerable to BEAST, which leads to theft of credentials. Force RC4, and it isn't exploitable, no matter how bad the client is. (BEAST was demonstrated against PayPal on a fully patched browser, with cookies stolen live on stage. I don't see how it is "stupid hype") With modern clients this isn't a concern: TLS 1.1 or higher fixes the problem, as does 1/(n-1). However, there are enough old clients out there to apparently make this an issue, and the fix usually forces all of them to RC4. The one saving grace is BEAST requires a plugin. So far. At some point RC4 needs to be removed. The question is now, or after someone demonstrates the sort of attack that we have nightmares about. Actually, given the talk about a removal path, 5 years from now or 3 years after someone demonstrates an attack. > > > The larger problem with the use of RC4 is that a number of dense > TLS clients (e.g. Java) send RC4 cipher suites at the very beginning > of the list of cipher suites, and a number of dense TLS server > choose the first shared cipher from the list proposed by the client > rather then the first shared cipher from the list configured by the > server admin. One side or the other needs patching, preferably both. End of the day we can't do anything without some actual work getting done on deployed stuff. But yes, this is a good reminder that not everything is a web browser that calls home every week for an update. 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 Tue Apr 22 22:53: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 A61B01A0073 for ; Tue, 22 Apr 2014 22:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAREbjn7ymvK for ; Tue, 22 Apr 2014 22:53:24 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 949301A030C for ; Tue, 22 Apr 2014 22:53:24 -0700 (PDT) Message-ID: <53575551.9090702@akr.io> Date: Wed, 23 Apr 2014 06:53:21 +0100 From: Alyssa Rowan MIME-Version: 1.0 To: tls@ietf.org References: <5352FB8A.3070109@akr.io> <20140423001448.3E6EA1ACDC@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MPMX9PkRCJXuonbX84kq69EXcUk Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 05:53:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 23/04/2014 05:09, Watson Ladd wrote: > At some point RC4 needs to be removed. The question is now, or > after someone demonstrates the sort of attack that we have > nightmares about. Actually, given the talk about a removal path, 5 > years from now or 3 years after someone demonstrates an attack. The only correct response to a probably-broken cipher is to turn it off _right now_ and replace it with something better (TLSv1.2 AES-128-GCM, say). Unless you're doing SSL/TLS for purely decorative purposes, it is preferable that insecure endpoints are unreachable or warned about - and are fixed - than the very real hazard that people will _go back_ and decrypt all of your sensitive traffic. > One side or the other needs patching, preferably both. End of the > day we can't do anything without some actual work getting done on > deployed stuff. I see a draft like this as being the writing on the wall the slowpokes need to start getting them moving; more importantly, the writing on the wall that we can show their auditors. - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTV1VRAAoJEOyEjtkWi2t6HcwP/21wmOrDoR+WDeNtFWZMc1/+ qqrP9jeKkwgpUlBhXBWYabe5cf4JNv9r2McbZ6T3vtHEy7uNjhwnkZI5SFen48bU 1UqBReB9OYNU5QPB0NBhW5Mu0Cv7aKFpxYwjcZ02kQbQXv3vqAx/b9JzweUWxJVu gA7M7EzczwGsNZIrvBcdn0T+9IgmqHXBORGDbhnGHc/QN5iSnhemtarCqNXYNTCc sggc16wZqmZ7LtjSLSr2rsT+6nSDUnGZARHgoy5qzEIaOsRPmyiSVOVdoNdRcLjA Q1etyRyRWuVn4k7EOdgV+f729oBGOpkn5Exuc74T/Uwyp4Hfct2j2sryxEU3ekvA pj5QJ+s8LfNuwq4907uaYn1an3MLYoD9S5DIZeW83e7QNipalsNpOmceXgBivurT gIMY+OKqqJ+YUeYHXut+gWH6qIHqXFI1HUQnJ1PR5fvD6S47bhnT7OofHnowncKs m/JbT2hZJvKbSAiPZuFrwPkER8zpU5IRqUaaN6xXJvITynVHK6W8AB7x09evB9NW /lMoTdzHfoyvp5H/hN/758oEj+ro9iMZLWYHZFOhSO0gQeHUE9rNipyu4N6UaGJ9 xg0IEJOgABQGB7DNEhfDnKHwyFTQqbQN8LVB0ESpeCBEu8KmOXEDgaGp5mqUP89t xX1YHdHIj9foAiHMnwV7 =ZkiG -----END PGP SIGNATURE----- From nobody Wed Apr 23 06:25:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95D61A03A7 for ; Wed, 23 Apr 2014 06:25:56 -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 7MnWFHTVB8AE for ; Wed, 23 Apr 2014 06:25:54 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 496B51A0362 for ; Wed, 23 Apr 2014 06:25:54 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3NDPk4E020957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 15:25:46 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Wed, 23 Apr 2014 15:25:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140423132546.5DC4E1ACDB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ISuAHRVvHfAsA8j4NH3GRaUcuFM Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) 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, 23 Apr 2014 13:25:56 -0000 Watson Ladd wrote: [ Charset UTF-8 unsupported, converting... ] > On Tue, Apr 22, 2014 at 5:14 PM, Martin Rex wrote: > > Alyssa Rowan wrote: > >> > >> > 1.56% or TLS servers support only RC4. > >> > >> Partly because of PCI compliance testers making noise about BEAST, I'm > >> thinking. > > > > BEAST was and still is a pretty stupid hype. > > > > Even the ssl test at qualys is still making bogus claims about > > servers not being BEAST-patched. Unless your server is a SSL-VPN server > > or will boldly execute client-supplied active content, there can not > > possibly be a BEAST vulnerability in the TLS server. > > It's not about the server: if I only offer TLS 1.0, then clients who > connect to me who aren't 1/(n-1) patched are vulnerable to BEAST, > which leads to theft of credentials. So what? The server isn't vulnerable to BEAST, and when the client will blissfully execute any attacker-supplied content, then the silly BEAST demonstration is of no interest at all. As long as the client keeps executing arbitrary attacker-supplied active content, that active content can submit whatever nefarious requests it wants to have performed on the server, and no amount of 1/(n-1) splitting and TLSv1.2+AES-GCM can prevent that. > > Force RC4, and it isn't exploitable, no matter how bad the client is. > (BEAST was demonstrated against PayPal on a fully patched browser, > with cookies stolen live on stage. I don't see how it is "stupid hype") It wasn't a "fully patched" browser, it was a wide-open browser. A fully patched browser would have *NO* active content plugins (no java, no flash, no pdf, no media, no office, whatever) and lots of other crap disabled (no scripting, no downloadable fonts, etc). BEAST only demonstrated that Web Browsers, in the configuration that they're shipping, are a *HUGE* security problem by themselves. > > With modern clients this isn't a concern: TLS 1.1 or higher fixes the > problem, as does 1/(n-1). It fixes the most irrelevant part of the BEAST prerequisites. > > However, there are enough old clients out there to apparently make > this an issue, and the fix usually forces all of them to RC4. > The one saving grace is BEAST requires a plugin. So far. BEAST requires a willingness to execute attacker-supplied active content. > > At some point RC4 needs to be removed. The question is now, or after > someone demonstrates the sort of attack that we have nightmares about. > Actually, given the talk about a removal path, 5 years from now or 3 > years after someone demonstrates an attack. Look at the rfc5746 (TLS extension renegotiation_info) adoption rate. The necessary change was rather small and could be added to *ANY* version of TLS. Anything more complicated will take longer to get deployed in the installed base. For some vendors, it seems to be primarily a sales strategy issue to deploy more complex TLS updates. Microsoft never shipped support for AES TLS cipher suites (rfc34268) for Windows XP, although this would have been *trivial* for them. They had shipped AES for XP with KB917021 (WPA2 hotfix) in late 2006, and for Windows 2003 / XP 64-bit they shipped an update with AES TLS cipher suites with KB948963 in 2008. Hotfixes for secure renegotiation and the 1/(n-1) record splitting were shipped for XP as well. For some usage scenarios, record splitting like 1+1+1+1+1+1+1+1+1+1+1/(n-11) might potentially help somewhat where the RC4 cipher suite can not be avoided. -Martin From nobody Wed Apr 23 08:07: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 58CA11A03E7 for ; Wed, 23 Apr 2014 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ku-qALRQDK0 for ; Wed, 23 Apr 2014 08:07:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E78271A03EB for ; Wed, 23 Apr 2014 08:07:15 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3NF78d7024250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 17:07:08 +0200 (MEST) In-Reply-To: To: Jacob Appelbaum Date: Wed, 23 Apr 2014 17:07:07 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aFGhdgzHnYl4rK4eE3J-2lJAPXo Cc: tls@ietf.org Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) 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, 23 Apr 2014 15:07:30 -0000 Jacob Appelbaum wrote: > On 4/19/14, Alyssa Rowan wrote: >> >> RC4 is either on the brink of being cracked, given the serious known >> weaknesses pointed out in Section 1 of the draft, or it is already >> over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were >> talking about that they got from NSA, and that seems plausible to me, >> and to several others, including Schneier). > > I think that RC4 is completely broken for certain adversaries. It > should be totally abandoned. While I have heard claims that RC4 would be "completely broken", I am still not aware of the slightest indication why or how this break would be performed. RC4 is a stream cipher, and operates by xoring plaintext with a pseudo-random keystream. In order to "completely break" RC4, it would be necessary to precompute future RC4 outputs from some amount of *known* RC4 keystream, essentially re-creating the internal state of the RC4 algorithm. HTTP is a protocol with often quite a lot of known plaintext, so recovering *some* amount of RC4 keystream will often be possible with a low probability of error. So that leaves us with the questions - are parts of the RC4 algorithm invertible? - is it possible to recreate the RC4 internal state from a certain amount of keystream octets. - how many keystream octets would be necessary - will those known keystream octets have to be from specific locations (or consecutive) - how big is the workfactor? I'm _not_ saying that this hasn't happened. But without the slightest indication about a _real_ problem with the RC4 algorithm internals, I refuse to be terrorized. -Martin PS: the most attractive target for breaking is the key exchange algorithm, because that would make the traffic protection keys (MAC and encrypt) available independent of the crypto an mac algorithms and their strength. Considering that NSA has been pushing ECDSA+ECDHE for quite a while (Suite B with NIST curves), I'm more worried about EC weaknesses than RC4 bias or chained CBC-IVs. ECDHE with Curve25519 and single-use(!!) DHE keypairs looks OK, but that might not interoperable with a large fraction of the installed base for another decade. From nobody Wed Apr 23 08:54: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 617281A02A2 for ; Wed, 23 Apr 2014 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMralGHoy_EL for ; Wed, 23 Apr 2014 08:54:12 -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 C787E1A00CB for ; Wed, 23 Apr 2014 08:54:11 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so1039019yha.12 for ; Wed, 23 Apr 2014 08:54: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=oidtIRk7Lv4ysqRyy3kDKAlOuacZHRvT831YgZKXFw8=; b=BxaMlYacoheiTDd/nC0CMl9G7dBzChX+d4SD7PbI/mQTuSus45Jbcc5FjSTEw6p3lN OgglBYhRmid84SaCqYDJ8MkHD/fs9zWVS9yl6SuzazwoMCORucpRjjr/Qi/a3Vk++A5V /vT82ImapQfVMojSyinpRZhULpLNXg7hzJOHB0lCWL5MhU9AeUPljZ8bNjebF5jFGETK p62w+YPLKbCsb5e51nksBU6d4A7XjWZRU91BbojgNi/3IaU09idSuG2kPAovv49txplj POZ4cKjSgBcmZp6neCB4jjyliLI1Dh2eR/aH8NKNjnET/P0XHoG/Qn7rAw5KBM5/uCjO BlYw== MIME-Version: 1.0 X-Received: by 10.236.120.66 with SMTP id o42mr36541812yhh.66.1398268445850; Wed, 23 Apr 2014 08:54:05 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Wed, 23 Apr 2014 08:54:05 -0700 (PDT) In-Reply-To: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> Date: Wed, 23 Apr 2014 08:54:05 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ymWZXexmKkRbCy7o1LEo5HhRLl8 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 15:54:13 -0000 On Wed, Apr 23, 2014 at 8:07 AM, Martin Rex wrote: > Jacob Appelbaum wrote: >> On 4/19/14, Alyssa Rowan wrote: >>> >>> RC4 is either on the brink of being cracked, given the serious known >>> weaknesses pointed out in Section 1 of the draft, or it is already >>> over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were >>> talking about that they got from NSA, and that seems plausible to me, >>> and to several others, including Schneier). >> >> I think that RC4 is completely broken for certain adversaries. It >> should be totally abandoned. > > While I have heard claims that RC4 would be "completely broken", I am > still not aware of the slightest indication why or how this break > would be performed. > > RC4 is a stream cipher, and operates by xoring plaintext with > a pseudo-random keystream. In order to "completely break" RC4, > it would be necessary to precompute future RC4 outputs from > some amount of *known* RC4 keystream, essentially re-creating > the internal state of the RC4 algorithm. Yes, that would be terribly bad of a break. We don't have one like that now. 5 years from now I would not be surprised. We need to start moving now to be ready for the inevitable. I would prefer not to have my banking secrets spread across the Internet before we decide we have a problem. However, even before you predict keystream from a handful of bytes you can do the following: -Use multiple connections sharing similar data together with hidden markov models to recover text -Use byte biases to determine what kind of information is flowing into and out of a server: yes we can tell if you have binaries or text and serve them up over RC4. -Remember wepcrack? RC4 leaks key information The RC4 state update is weak: it always changes an even permutation to an odd one. There are probably other rep theoretic issues: I've not thought very hard about it. All of this is possible today. It won't stop being possible, and our understanding of the weaknesses in RC4 will only grow. Already, users assumptions of the security they have is not met by RC4. Given uptake times, we need to start pushing for a fix now if we want it ready in 5 years. Supposedly, algorithm agility was supposed to work for this eventuality: it should be relatively trivial to change configurations to use block ciphers if you don't care about BEAST and Lucky 13. If you do, upgrade to TLS 1.2. We have a fix: it needs to be deployed, and people need to know they have to. > > > -Martin > > PS: the most attractive target for breaking is the key exchange algorithm, > because that would make the traffic protection keys (MAC and encrypt) > available independent of the crypto an mac algorithms and their strength. > Considering that NSA has been pushing ECDSA+ECDHE for quite a while > (Suite B with NIST curves), I'm more worried about EC weaknesses than > RC4 bias or chained CBC-IVs. You shouldn't be. EC has been around since 1985 with no real scratches. Do you know something we don't? Show me a discrete log on P256 (with all the usual points about how to do it so I know you didn't cheat) and I'll get worried. Show me a new weak class of curves (prime fields only) and I'll be interested. > > ECDHE with Curve25519 and single-use(!!) DHE keypairs looks OK, but > that might not interoperable with a large fraction of the installed > base for another decade. Single-use only because implementors don't take elementary precautions against side channels. The Curve25519 impl. has no side-channels. The security difference between Curve25519 and P256 is entirely a result of poor implementations. The speed difference is a result of careful choices. There is no known attack against properly implemented Suite B protocols known in the open literature. Nor is there likely to be one anytime soon: extensive analysis over the past decades has found nothing. However, implementation quality can be low. 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 Wed Apr 23 10:48: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 DB6D41A0439 for ; Wed, 23 Apr 2014 10:48:56 -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 dOAPEv4xnDga for ; Wed, 23 Apr 2014 10:48:52 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id A264C1A0435 for ; Wed, 23 Apr 2014 10:48:52 -0700 (PDT) Received: from mail52-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 17:47:44 +0000 Received: from mail52-va3 (localhost [127.0.0.1]) by mail52-va3-R.bigfish.com (Postfix) with ESMTP id 9033C401D1; Wed, 23 Apr 2014 17:47:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT005.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dIzz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h17326ah8275bh1de097h186068h5eeeKz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: pass (mail52-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=AMSPRD0310HT005.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(479174003)(243025003)(24454002)(19580405001)(76482001)(2656002)(80976001)(77982001)(83322001)(15975445006)(46102001)(15202345003)(19580395003)(86362001)(4396001)(20776003)(83072002)(92566001)(77096999)(92726001)(74502001)(74482001)(99396002)(74662001)(31966008)(87936001)(54356999)(76176999)(85852003)(79102001)(36756003)(81342001)(81542001)(50986999)(66066001)(80022001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:BEE27525.3D0C0419.3FF01FC0.9EE913D9.2013F; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail52-va3 (localhost.localdomain [127.0.0.1]) by mail52-va3 (MessageSwitch) id 1398275262794775_9667; Wed, 23 Apr 2014 17:47:42 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.233]) by mail52-va3.bigfish.com (Postfix) with ESMTP id 51E9F1600A0; Wed, 23 Apr 2014 17:47:26 +0000 (UTC) Received: from AMSPRD0310HT005.eurprd03.prod.outlook.com (157.56.248.5) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 17:47:25 +0000 Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT005.eurprd03.prod.outlook.com (10.255.40.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 23 Apr 2014 17:48:25 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 17:48:25 +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.0921.000; Wed, 23 Apr 2014 17:48:24 +0000 From: "Paterson, Kenny" To: "mrex@sap.com" , Watson Ladd Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXBEeN4qqsUtzzkCETpYoPXpAkJsZiM0AgATRIwCAAEGogIAAm1cAgABaFgA= Date: Wed, 23 Apr 2014 17:48:23 +0000 Message-ID: References: <20140423132546.5DC4E1ACDB@ld9781.wdf.sap.corp> In-Reply-To: <20140423132546.5DC4E1ACDB@ld9781.wdf.sap.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [134.219.227.30] x-forefront-prvs: 01901B3451 Content-Type: text/plain; charset="us-ascii" Content-ID: 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/bqANBI5jrGAtnM8_V2jT7OpHqds Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 17:48:57 -0000 On 23/04/2014 14:25, "Martin Rex" wrote: >For some usage scenarios, record splitting like >1+1+1+1+1+1+1+1+1+1+1/(n-11) >might potentially help somewhat where the RC4 cipher suite can not be >avoided. No, this doesn't help, because of the double byte bias attacks. Moreover, the interesting content (from the attacker's perspective) is rarely in the first few bytes of the TLS connection. For an analysis of this and other "countermeasures" to the RC4 attacks, please read the paper at: http://www.isg.rhul.ac.uk/tls/RC4biases.pdf especially Section 7. Cheers Kenny From nobody Wed Apr 23 11: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 6990A1A0429 for ; Wed, 23 Apr 2014 11:06:54 -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 QnC-uVMHuPgH for ; Wed, 23 Apr 2014 11:06:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 549B31A0430 for ; Wed, 23 Apr 2014 11:06:50 -0700 (PDT) Received: from mail213-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 18:05:43 +0000 Received: from mail213-ch1 (localhost [127.0.0.1]) by mail213-ch1-R.bigfish.com (Postfix) with ESMTP id 03A8B3A028D; Wed, 23 Apr 2014 18:05:43 +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: -5 X-BigFish: PS-5(zzbb2dI98dI9371Id772h1432I1418Izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: pass (mail213-ch1: 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)(24454002)(377454003)(479174003)(189002)(199002)(51704005)(99396002)(31966008)(74662001)(74482001)(92726001)(74502001)(76176999)(87936001)(54356999)(83072002)(77096999)(92566001)(81542001)(80022001)(50986999)(66066001)(85852003)(81342001)(79102001)(36756003)(77982001)(80976001)(83322001)(19580405001)(551544002)(2656002)(76482001)(86362001)(4396001)(20776003)(46102001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:E45FF2E5.97BA9311.7ED7F173.42256970.205A4; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail213-ch1 (localhost.localdomain [127.0.0.1]) by mail213-ch1 (MessageSwitch) id 1398276340668937_20011; Wed, 23 Apr 2014 18:05:40 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail213-ch1.bigfish.com (Postfix) with ESMTP id 93C23180031; Wed, 23 Apr 2014 18:05:40 +0000 (UTC) Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 18:05:39 +0000 Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT004.eurprd03.prod.outlook.com (10.255.40.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 23 Apr 2014 18:06:39 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 18:06: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.0921.000; Wed, 23 Apr 2014 18:06:38 +0000 From: "Paterson, Kenny" To: Watson Ladd , "mrex@sap.com" Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCtzaRoqs6xj002Wq6Mdi5x8AJsfUwuAgAANH4CAADXHgA== Date: Wed, 23 Apr 2014 18:06:38 +0000 Message-ID: References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> 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.4.1.140326 x-originating-ip: [134.219.227.30] x-forefront-prvs: 01901B3451 Content-Type: text/plain; charset="us-ascii" Content-ID: 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/vPjL4tVYERy05SGohyttKorl2Qc Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 18:06:54 -0000 On 23/04/2014 16:54, "Watson Ladd" wrote: >On Wed, Apr 23, 2014 at 8:07 AM, Martin Rex wrote: >> Jacob Appelbaum wrote: >>> On 4/19/14, Alyssa Rowan wrote: >>>> >>>> RC4 is either on the brink of being cracked, given the serious known >>>> weaknesses pointed out in Section 1 of the draft, or it is already >>>> over the brink (if that's the 'cryptanalytic breakthrough' GCHQ were >>>> talking about that they got from NSA, and that seems plausible to me, >>>> and to several others, including Schneier). >>> >>> I think that RC4 is completely broken for certain adversaries. It >>> should be totally abandoned. >> >> While I have heard claims that RC4 would be "completely broken", I am >> still not aware of the slightest indication why or how this break >> would be performed. Me neither.=20 Jacob Applebaum has said this kind of thing in various fora. I think it's time he put some detail behind the claim (or stopped making it). However, whether this is correct or not does not diminish the other well-justified arguments for deprecating RC4. It's looking distinctly unwell to me. >> RC4 is a stream cipher, and operates by xoring plaintext with >> a pseudo-random keystream. In order to "completely break" RC4, >> it would be necessary to precompute future RC4 outputs from >> some amount of *known* RC4 keystream, essentially re-creating >> the internal state of the RC4 algorithm. > >Yes, that would be terribly bad of a break. We don't have one like >that now. 5 years from now I would not be surprised. We need to start >moving now to be ready for the inevitable. I would prefer not to have >my banking secrets spread across the Internet before we decide we have >a problem. > >However, even before you predict keystream from a handful of bytes you >can do the following: >-Use multiple connections sharing similar data together with hidden >markov models to recover text Indeed, the use of language models is mentioned as an enhancement in our paper. Based on my experience of using such models in a different context, I think they would make a big difference in reducing the attacks' ciphertext requirements when the plaintext being targeted is "natural language", and possibly even passwords. But this is less likely to be effective for session cookies. It would be a great student project to investigate this angle. >-Use byte biases to determine what kind of information is flowing into >and out of a server: yes we can tell if you have binaries or text and >serve them up over RC4. I don't immediately know how you'd do that, but I'm willing to be educated! Maybe you're assuming ASCII or binary plaintext, and then aggregating most significant bit estimates over many ciphertext positions? Do you have an estimate for how much ciphertext would be needed to achieve a certain confidence level here? >-Remember wepcrack? RC4 leaks key information Right now, we do not know how to exploit key leakage into the keystream when RC4 is used in TLS. To understand why, you have to look at how the RC4 key for each session/connection is computed in TLS compared to how it is computed for each frame in WEP. If you can make progress here, then you would have a very nice research paper (and probably an improved attack on RC4 in TLS). >The RC4 state update is weak: it always changes an even permutation to >an odd one. There are probably other rep theoretic issues: I've not >thought very hard about it. But then it's unwise to speculate, Watson! By contrast, many people have studied RC4 fairly intensively over the years, and the state of the art is what it is (modulo claims by Jacob Applebaum). I'd recommend you either do think about RC4 hard, or go read the literature, rather than just speculating. >All of this is possible today. It won't stop being possible, and our >understanding of the weaknesses in RC4 will only grow. Already, users >assumptions of the security they have is not met by RC4. I can almost agree with this, except for your comments about key leakage into the keystream. Cheers, Kenny From nobody Wed Apr 23 11:12: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 CA9351A0437 for ; Wed, 23 Apr 2014 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJZEcUZu14vg for ; Wed, 23 Apr 2014 11:12:42 -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 61ADB1A038E for ; Wed, 23 Apr 2014 11:12:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 46E234755C; Wed, 23 Apr 2014 18:12:36 +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 F0D7A47524; Wed, 23 Apr 2014 18:12:35 +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 E4B19FE054; Wed, 23 Apr 2014 18:12: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; Wed, 23 Apr 2014 14:12:35 -0400 From: "Salz, Rich" To: "Paterson, Kenny" Date: Wed, 23 Apr 2014 14:12:34 -0400 Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCtzaRoqs6xj002Wq6Mdi5x8AJsfUwuAgAANH4CAADXHgP//8LYA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E25E@USMBX1.msg.corp.akamai.com> References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> 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/nRdfmS52wOvv28OvWKbkQ8Tsjaw Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 18:12:44 -0000 Thanks for posting; it's great to have a cryptographer weigh in. So, at the risk of putting you on the spot: what do you think we (TLS-WG) = should do? -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Wed Apr 23 11:16: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 BA03C1A0499 for ; Wed, 23 Apr 2014 11:16:17 -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 X5hHjK8kU4PP for ; Wed, 23 Apr 2014 11:16:15 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1811A0495 for ; Wed, 23 Apr 2014 11:16:15 -0700 (PDT) Received: from mail59-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE015.bigfish.com (10.3.207.137) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 18:15:07 +0000 Received: from mail59-am1 (localhost [127.0.0.1]) by mail59-am1-R.bigfish.com (Postfix) with ESMTP id 06CB0405BF; Wed, 23 Apr 2014 18:15:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.5; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0310HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: PS-5(zzbb2dI98dI148cI1dbaI1432Izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h8275bh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: pass (mail59-am1: 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=AMSPRD0310HT003.eurprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(479174003)(51704005)(24454002)(19580405001)(76482001)(2656002)(80976001)(77982001)(83322001)(46102001)(19580395003)(86362001)(4396001)(20776003)(83072002)(92566001)(77096999)(92726001)(74502001)(74482001)(99396002)(74662001)(31966008)(87936001)(54356999)(76176999)(85852003)(79102001)(36756003)(81342001)(81542001)(50986999)(66066001)(80022001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod Received: from mail59-am1 (localhost.localdomain [127.0.0.1]) by mail59-am1 (MessageSwitch) id 13982769007582_28962; Wed, 23 Apr 2014 18:15:00 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.237]) by mail59-am1.bigfish.com (Postfix) with ESMTP id E8EF73A0091; Wed, 23 Apr 2014 18:14:59 +0000 (UTC) Received: from AMSPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.5) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 18:14:51 +0000 Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AMSPRD0310HT003.eurprd03.prod.outlook.com (10.255.40.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Wed, 23 Apr 2014 18:15:52 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 18:15:52 +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.0921.000; Wed, 23 Apr 2014 18:15:51 +0000 From: "Paterson, Kenny" To: "Salz, Rich" Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCtzaRoqs6xj002Wq6Mdi5x8AJsfUwuAgAANH4CAADXHgP//8LYAgAAR3QA= Date: Wed, 23 Apr 2014 18:15:50 +0000 Message-ID: References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E25E@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E25E@USMBX1.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [134.219.227.30] x-forefront-prvs: 01901B3451 Content-Type: text/plain; charset="us-ascii" Content-ID: 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/U8HsPk-8b8QFiPE9wW6Sn1_RoKo Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 18:16:17 -0000 On 23/04/2014 19:12, "Salz, Rich" wrote: >Thanks for posting; it's great to have a cryptographer weigh in. > >So, at the risk of putting you on the spot: what do you think we >(TLS-WG) should do? > I think we should deprecate RC4 now, in the hope that in the medium term, we can reduce the amount of RC4 being negotiated in TLS. As others have said, the RFC, if published, gives a useful stick with which to beat the appropriate people/argue for change. Cheers Kenny=20 From nobody Wed Apr 23 12:25: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 D631B1A0422 for ; Wed, 23 Apr 2014 12:25: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 v8bSaOx4enJQ for ; Wed, 23 Apr 2014 12:25:07 -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 0A1E01A050E for ; Wed, 23 Apr 2014 12:25:05 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so1114570eek.7 for ; Wed, 23 Apr 2014 12:24: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 :content-transfer-encoding:message-id:references:to; bh=ERZT2wqSwoQ5a333CQECrWwMT/9t6hQdJU1bq5eXx9Y=; b=FgezpSSY1mt+nfEWkjJLbkno8dJx+3GeJYn/zS9PeuL56IL7l7O952HceN60RQ72EY 1S2tRb4oiIddXSGA+Nv336k0ZeTRlrffFIjE+/XiWCDtXFCFh5RFu+sNPE61OcFQnj04 IggOrMRDEwuh8olzsyfMlOWz85t9FlHy2Y3y9c0/fTxQP4DLnWUdeN+s9/DJybtM//13 uSNtU0bH8dTCHj60rwciiWCPVUAq/ToQ92mzihK8aMD2x/hFQOuiZTd3h2YcpSTUAahp uej5xfRZQTBFkwtE7GUpRFXam6mIhgw8ZSls9iJmK0Dl6bwStVu+g7Yxh08nBhZIBGJ+ V56A== X-Received: by 10.14.109.201 with SMTP id s49mr18847474eeg.88.1398281099783; Wed, 23 Apr 2014 12:24:59 -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 u1sm8868298eex.31.2014.04.23.12.24.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Apr 2014 12:24:59 -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, 23 Apr 2014 22:24:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E25E@USMBX1.msg.corp.akamai.com> To: "Paterson, Kenny" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kasrZXZRrrrU5X99RziHSdT4U-8 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 19:25:10 -0000 On Apr 23, 2014, at 9:15 PM, Paterson, Kenny = wrote: > On 23/04/2014 19:12, "Salz, Rich" wrote: >=20 >> Thanks for posting; it's great to have a cryptographer weigh in. >>=20 >> So, at the risk of putting you on the spot: what do you think we >> (TLS-WG) should do? >>=20 >=20 > I think we should deprecate RC4 now, in the hope that in the medium = term, > we can reduce the amount of RC4 being negotiated in TLS. >=20 > As others have said, the RFC, if published, gives a useful stick with > which to beat the appropriate people/argue for change. I agree. Just let=92s not overestimate our influence. In January 1999 = RFC 2459 said this: Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It is still reasonable to use MD5 to verify existing signatures. 10 years later it turned out that some public CAs (not just RapidSSL) = were signing new certificates with MD5. Yoav From nobody Wed Apr 23 12:28: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 0A6BF1A04CD for ; Wed, 23 Apr 2014 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.273 X-Spam-Level: X-Spam-Status: No, score=-7.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFv8uLFtRI3E for ; Wed, 23 Apr 2014 12:28:21 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id B68051A049A for ; Wed, 23 Apr 2014 12:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1398281296; x=1429817296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O8gfsEkXoWo7HjGFiUQlqs3K6alEe9M+t44XjbjDabA=; b=cTQBAXQ1OhJqHJSsvfzfMHrH1Qt/EoGknnbkapiJngHzFQovfud0TDIH WVIMBhQQ5ubK1uoNuat5qZkAdGw/PejRDXYiRA4zozoKiqjFNhlPes6zB cX9veDlx8rKIgZFbCA5SNP0oIF2p18pOuROtMCjfpUQ2b4aTz4bNX3+na I=; X-IronPort-AV: E=Sophos;i="4.97,913,1389744000"; d="scan'208";a="108722064" X-IPAS-Result: AjELABUTWFPAqArr/2dsb2JhbABahCylewoBnjKBMnSCJQEBAQECATo/BQsCAQgNFRQQMiUCBAENDYgxuT6VFBeOJzEHgySBFQSfd48Egis Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 23 Apr 2014 19:28:16 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0181.006; Wed, 23 Apr 2014 12:28:15 -0700 From: David Holmes To: Jacob Appelbaum , "akr@akr.io" Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCtrN4qqsUtzzkCETpYoPXpAkJsfdAbA Date: Wed, 23 Apr 2014 19:28:14 +0000 Deferred-Delivery: Wed, 23 Apr 2014 17:12:00 +0000 Message-ID: <859F43324A6FEC448BFEA30C90405FA9025312@SEAEMBX02.olympus.F5Net.com> References: <20140419131019.GA29561@roeckx.be> <5352B328.1080006@pobox.com> <20140419175352.GA9090@roeckx.be> <238BBDD5-DDE5-4627-AF4D-BC57DC0E61D7@gmail.com> <5352D82C.2030302@akr.io> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9z-1h1eq7QUOZAacRcZI9a7R_gA Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 19:28:23 -0000 > I think that RC4 is completely broken for certain adversaries. It should = be totally abandoned. Like Martin, I too am wondering if there was some RC4 attack I'm not aware = of that is causing people to say it's "completely broken". Last I heard the= best attack still had a 2^24 message requirement. Ciphers appear to have r= elative strength over time; absolute statements like "completely broken" wo= rk against the ability to weigh ciphers as options in a given threat enviro= nment over time. From nobody Wed Apr 23 12:36: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 D905D1A0354 for ; Wed, 23 Apr 2014 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCy9tUNEnyCF for ; Wed, 23 Apr 2014 12:36:11 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E52851A0242 for ; Wed, 23 Apr 2014 12:36:10 -0700 (PDT) Received: from [174.236.35.149] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wd2xg-0000Gq-Gm; Wed, 23 Apr 2014 15:36:04 -0400 Date: Wed, 23 Apr 2014 12:36:04 -0700 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791f3651a8b4fc725782f2ac9515626da2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.236.35.149 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OvfvveGtuXtsHrYxnAvR9sHZSXY Cc: tls@ietf.org Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 19:36:13 -0000 On 4/22/14 at 9:09 PM, watsonbladd@gmail.com (Watson Ladd) wrote: >One side or the other needs patching, preferably both. End of the day >we can't do anything without some actual work getting done on deployed >stuff. But yes, this is a good reminder that not everything is a web >browser that calls home every week for an update. Should we have a best practices standard for the Internet of=20 Things (IoT) which provides for updating their cryptography? If=20 we do, we'll quickly get into the bind of function vs. cost. If=20 we don't, we probably will see LED bulbs, with their 20+ year=20 life span, which are vulnerable to unauthorized control and=20 therefor must be run on a closed network. That configuration=20 will require a gateway through a more capable, and frequently=20 updated, machine. If the LEDs are controlled through their power=20 connection it will also require power line isolation. This last=20 suggestion may be a nightmare for the IoT dreamers. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345=20 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos,=20 CA 95032 From nobody Wed Apr 23 13: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 CA5201A0648 for ; Wed, 23 Apr 2014 13:40:52 -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 kpMPcgrmuZA4 for ; Wed, 23 Apr 2014 13:40:50 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 341C51A063B for ; Wed, 23 Apr 2014 13:40:50 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 83AA433D118; Wed, 23 Apr 2014 20:40:44 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Yoav Nir References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E25E@USMBX1.msg.corp.akamai.com> From: Geoffrey Keating Date: 23 Apr 2014 13:40:44 -0700 In-Reply-To: Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pUg-q7TFHKe9yPEnivMyS7UROu8 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 20:40:52 -0000 Yoav Nir writes: > On Apr 23, 2014, at 9:15 PM, Paterson, Kenny = wrote: >=20 > > I think we should deprecate RC4 now, in the hope that in the medium ter= m, > > we can reduce the amount of RC4 being negotiated in TLS. > >=20 > > As others have said, the RFC, if published, gives a useful stick with > > which to beat the appropriate people/argue for change. >=20 > I agree. Just let=C2=92s not overestimate our influence. In January 1999 = RFC 2459 said this: >=20 > Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, > but there are no other known cryptanalytic results. The use of MD5 > for new applications is discouraged. It is still reasonable to use > MD5 to verify existing signatures. >=20 > 10 years later it turned out that some public CAs (not just RapidSSL) wer= e signing new certificates with MD5. Yes, but look at the full part of the glass: 10 years later almost all CAs were *not* signing new certificates with MD5, which made the cleanup & recovery much easier. Imagine if today, the major web browser vendors turned off RC4 support. Sure, in a year there'd probably still be 50% of the web vulnerable, but the other 50% would be safe... and in 3 years, it'd be 20% vulnerable, and they'd probably still be running XP anyway :-). From nobody Wed Apr 23 14:02: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 2EA8A1A0656 for ; Wed, 23 Apr 2014 14:02:54 -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 jRs9jU6W1xsh for ; Wed, 23 Apr 2014 14:02:52 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F11B61A019E for ; Wed, 23 Apr 2014 14:02:51 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3NL2h2k004295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Apr 2014 23:02:43 +0200 (MEST) In-Reply-To: To: "Paterson, Kenny" Date: Wed, 23 Apr 2014 23:02:43 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140423210243.B43451ACDD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9ffSpmBz0LrqASjMnu_pCv4XRS8 Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) 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, 23 Apr 2014 21:02:54 -0000 Paterson, Kenny wrote: > > "Watson Ladd" wrote: >> >> Martin Rex wrote: >>> >>> RC4 is a stream cipher, and operates by xoring plaintext with >>> a pseudo-random keystream. In order to "completely break" RC4, >>> it would be necessary to precompute future RC4 outputs from >>> some amount of *known* RC4 keystream, essentially re-creating >>> the internal state of the RC4 algorithm. >> >>Yes, that would be terribly bad of a break. We don't have one like >>that now. 5 years from now I would not be surprised. We need to start >>moving now to be ready for the inevitable. I would prefer not to have >>my banking secrets spread across the Internet before we decide we have >>a problem. >> >>However, even before you predict keystream from a handful of bytes you >>can do the following: >>-Use multiple connections sharing similar data together with hidden >>markov models to recover text > > > Indeed, the use of language models is mentioned as an enhancement in our > paper. Based on my experience of using such models in a different context, > I think they would make a big difference in reducing the attacks' > ciphertext requirements when the plaintext being targeted is "natural > language", and possibly even passwords. But this is less likely to be > effective for session cookies. It would be a great student project to > investigate this angle. Quantify "multiple connections sharing similar data" / the attacks' ciphertext requirements. I'm doing like 300 web-based purchases with OTP-authentication tokens (TAN) year and maybe 4 Credit Card purchases per year online from various different shops and would repeat a single failing purchase at most 5 times before I would give up. The numbers I've seen so far do not scare me for a significant number of usage scenarios. That doesn't mean that there would be no usage scenarios where the weaknesses could be sufficient to make an attack practical. But I'm not using any of those. Problems like the recent shortcut in the certificate validation for (EC)DHE cipher suites in Apple's TLS stack and GnuTLS, or the recent Heartbleed (Heartbloat) attack is stuff that worries me much more. -Martin From nobody Wed Apr 23 14:32: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 2C63F1A0537 for ; Wed, 23 Apr 2014 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJAP23TOsVsF for ; Wed, 23 Apr 2014 14:32:19 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 57F251A0654 for ; Wed, 23 Apr 2014 14:32:19 -0700 (PDT) Received: from mail51-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.22; Wed, 23 Apr 2014 21:31:10 +0000 Received: from mail51-ch1 (localhost [127.0.0.1]) by mail51-ch1-R.bigfish.com (Postfix) with ESMTP id C3E2B340300; Wed, 23 Apr 2014 21:31:10 +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: -4 X-BigFish: PS-4(zzbb2dI98dId772h1432I1453Izz1f42h1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1de098h17326ah8275bh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26d3h1155h) Received-SPF: pass (mail51-ch1: 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)(52034003)(479174003)(199002)(189002)(83506001)(86362001)(80976001)(2656002)(15202345003)(46102001)(31966008)(74662001)(81342001)(79102001)(20776003)(80022001)(87936001)(4396001)(83072002)(76482001)(85852003)(76176999)(50986999)(77982001)(77096999)(74502001)(19580395003)(92726001)(19580405001)(99396002)(92566001)(83322001)(36756003)(15975445006)(54356999)(551544002)(74482001)(66066001)(81542001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:DEDCF2D4.97F2AD11.7ED91EFB.EE57051.20490; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail51-ch1 (localhost.localdomain [127.0.0.1]) by mail51-ch1 (MessageSwitch) id 1398288668558529_28757; Wed, 23 Apr 2014 21:31:08 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail51-ch1.bigfish.com (Postfix) with ESMTP id 84C962007C; Wed, 23 Apr 2014 21:31:08 +0000 (UTC) Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 23 Apr 2014 21:31:08 +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.435.0; Wed, 23 Apr 2014 21:32:08 +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.921.12; Wed, 23 Apr 2014 21:32:07 +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.0921.000; Wed, 23 Apr 2014 21:32:07 +0000 From: "Paterson, Kenny" To: "mrex@sap.com" Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCtzaRoqs6xj002Wq6Mdi5x8AJsfUwuAgAANH4CAADXHgIAAIHWAgAAY7wA= Date: Wed, 23 Apr 2014 21:32:07 +0000 Message-ID: References: <20140423210243.B43451ACDD@ld9781.wdf.sap.corp> In-Reply-To: <20140423210243.B43451ACDD@ld9781.wdf.sap.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [80.42.211.108] x-forefront-prvs: 01901B3451 Content-Type: text/plain; charset="us-ascii" Content-ID: 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/_SERDvcNJzkysioTM4CkqC0eG3U Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 21:32:23 -0000 On 23/04/2014 22:02, "Martin Rex" wrote: >Paterson, Kenny wrote: >> >> "Watson Ladd" wrote: >>> >>> Martin Rex wrote: >>>>=20 >>>> RC4 is a stream cipher, and operates by xoring plaintext with >>>> a pseudo-random keystream. In order to "completely break" RC4, >>>> it would be necessary to precompute future RC4 outputs from >>>> some amount of *known* RC4 keystream, essentially re-creating >>>> the internal state of the RC4 algorithm. >>> >>>Yes, that would be terribly bad of a break. We don't have one like >>>that now. 5 years from now I would not be surprised. We need to start >>>moving now to be ready for the inevitable. I would prefer not to have >>>my banking secrets spread across the Internet before we decide we have >>>a problem. >>> >>>However, even before you predict keystream from a handful of bytes you >>>can do the following: >>>-Use multiple connections sharing similar data together with hidden >>>markov models to recover text >>=20 >>=20 >> Indeed, the use of language models is mentioned as an enhancement in our >> paper. Based on my experience of using such models in a different >>context, >> I think they would make a big difference in reducing the attacks' >> ciphertext requirements when the plaintext being targeted is "natural >> language", and possibly even passwords. But this is less likely to be >> effective for session cookies. It would be a great student project to >> investigate this angle. > >Quantify "multiple connections sharing similar data" / >the attacks' ciphertext requirements. Sure, I'll be able to quantify it for you just as soon as I've done the research. Someone with better coding skills than me could probably knock something up in a day or two, but I'm not that guy. >I'm doing like 300 web-based purchases with OTP-authentication tokens >(TAN) year and maybe 4 Credit Card purchases per year online from various >different shops and would repeat a single failing purchase at most 5 times >before I would give up. > >The numbers I've seen so far do not scare me for a significant number >of usage scenarios. That doesn't mean that there would be no usage >scenarios where the weaknesses could be sufficient to make an attack >practical. But I'm not using any of those. Perhaps you are not, but people who use your company's systems may be (but then you don't consider the use of client side javascript to recover session cookies to be an attack, right?) >Problems like the recent shortcut in the certificate validation >for (EC)DHE cipher suites in Apple's TLS stack and GnuTLS, or the >recent Heartbleed (Heartbloat) attack is stuff that worries me much more. I completely agree. But both of these specific problems are much easier to solve, once identified, than removing RC4 support seems to be. By the way, it seems SAP relies on OpenSSL in at least some of its products [1]. Hope your company is planning on making a big donation to the OpenSSL foundation real soon now :-) Cheers Kenny [1]=20 http://scn.sap.com/community/bi-platform/blog/2014/04/11/sap-business-intel ligence-and-the-openssl-heartbleed-vulnerability From nobody Wed Apr 23 16:14: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 73AF81A072A for ; Wed, 23 Apr 2014 16:14:52 -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 0121UybUGkgm for ; Wed, 23 Apr 2014 16:14:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7C1A0299 for ; Wed, 23 Apr 2014 16:14:49 -0700 (PDT) Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.921.12; Wed, 23 Apr 2014 23:14:42 +0000 Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.33]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.33]) with mapi id 15.00.0921.000; Wed, 23 Apr 2014 23:14:41 +0000 From: Marsh Ray To: "mrex@sap.com" , Jacob Appelbaum Thread-Topic: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) Thread-Index: AQHPXCttVkycqBLyFEOgpA3HqhwABJsfUwuAgACDaqA= Date: Wed, 23 Apr 2014 23:14:41 +0000 Message-ID: References: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> In-Reply-To: <20140423150707.F18C11ACDB@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.181.204.234] x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(189002)(377454003)(51704005)(74662001)(83072002)(33646001)(74316001)(4396001)(76576001)(54356999)(74502001)(2656002)(85852003)(92566001)(87936001)(80976001)(31966008)(50986999)(20776003)(99286001)(76482001)(80022001)(66066001)(86362001)(99396002)(83322001)(81542001)(81342001)(77982001)(551544002)(76176999)(79102001)(46102001)(86612001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; FPR:965FF225.A7FA44FA.3CDD75A9.42E7D82D.202E0; 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/e1qKU3S3PBaHnw2w8507o2npMaI Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2014 23:14:52 -0000 -----Original Message----- From: Martin Rex Sent: Wednesday, April 23, 2014 8:07 AM > > - are parts of the RC4 algorithm invertible? Yes, in the sense that knowledge of the ~1600 bit state allows one to deter= mine forward *and backwards* in the stream. > - is it possible to recreate the RC4 internal state from a certain amount of keystream octets. This was done for WEP, which is particularly pathological in the way it use= s the raw password as the key.=20 TLS uses a unique 128 bit PRF-derived key on every handshake. I haven't hea= rd of anyone being able to attack this method of keying. > - how many keystream octets would be necessary (Speculation) At least 1600/8 =3D 200 bytes or so. > - will those known keystream octets have to be from specific locations (or consecutive) Known attacks rely on specific locations. (Speculation) Other attacks probably would benefit from specific locations,= but would probably not require perfectly contiguous known plaintext. > - how big is the workfactor? Who knows? > I'm _not_ saying that this hasn't happened. But without the slightest in= dication > about a _real_ problem with the RC4 algorithm internals, I refuse to be t= errorized. There are real, known attacks on the RC4 algorithm internals, even with the= solid keying as used by TLS. > PS: the most attractive target for breaking is the key exchange algorithm= , because > that would make the traffic protection keys (MAC and encrypt) available > independent of the crypto an mac algorithms and their strength. That doesn't mean the cipher won't be attacked *too* :-) - Marsh ----------------------------------- Usual boilerplate disclaimers apply. From nobody Wed Apr 23 18:17: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 773111A0770 for ; Wed, 23 Apr 2014 18:17:05 -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 ltp748RfGwAk for ; Wed, 23 Apr 2014 18:17:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B33241A02BE for ; Wed, 23 Apr 2014 18:17:02 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3O1Gshk024677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Apr 2014 03:16:55 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Thu, 24 Apr 2014 03:16:54 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140424011654.CEA211ACDD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rQEjIjgpxh0mu3NeSxTBIw995Sk Cc: "tls@ietf.org" Subject: Re: [TLS] RC4 Considered Harmful (Was: RC4 deprecation path) 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, 24 Apr 2014 01:17:05 -0000 Watson Ladd wrote: > > Martin Rex wrote: >> >> ECDHE with Curve25519 and single-use(!!) DHE keypairs looks OK, but >> that might not interoperable with a large fraction of the installed >> base for another decade. > > There is no known attack against properly implemented Suite B > protocols known in the open literature. Nor is there likely to be one > anytime soon: extensive analysis over the past decades has found > nothing. However, implementation quality can be low. I'm sorry, but theoretical results mean nothing to me. For me, the quality of real-world implementations is what really counts, and there have been several quite epic failures with (EC)DSA which are *nowhere* clear from the specification. One of these severe problems is still present in FIPS 186-4. (EC)DSA is the cryptoglycerin among cryptographic algorithms, with casualties all over the place. -Martin From nobody Thu Apr 24 12:27: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 1910A1A03D6 for ; Thu, 24 Apr 2014 12:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.072 X-Spam-Level: X-Spam-Status: No, score=-12.072 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 5ShrCX1Cv3zD for ; Thu, 24 Apr 2014 12:27:50 -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 EE7421A036B for ; Thu, 24 Apr 2014 12:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1001; q=dns/txt; s=iport; t=1398367664; x=1399577264; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jCazcakalxTtMudTupZaesGbpvIN1xW8XR538gKeR8c=; b=mooFUO4VmGZH3HZA/5RtDqqSz2Z+iLJ/yanCy+H3+FSXZj706jbzegsq 6/thf/77VZnAIdAXbi0IZl8K2BaIWLXVy9jxf17J4ZL/WQ1J1FfzW4NTJ axYW/SyW9MZaL8BcG6F5bm1mWyO7HKnXYN3v4XXC/kYflwKmBi2MglTJj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANlkWVOtJV2c/2dsb2JhbABZgwaBJsViFnSCLDpNBAE+JhwnBIhUmT2yIhcEkgCBFQSVCINxklmDMYIr X-IronPort-AV: E=Sophos;i="4.97,921,1389744000"; d="scan'208";a="320149192" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 24 Apr 2014 19:27:43 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3OJRh8I023330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Apr 2014 19:27:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 24 Apr 2014 14:27:43 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS Interim - Hotel Suggestions Thread-Index: AQHPX/NDx0CTAOMLiEKn5D1MqxRbCw== Date: Thu, 24 Apr 2014 19:27:42 +0000 Message-ID: <1587B71C-38BD-400C-B068-1C26B0270C0B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.220] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F4BBA4B0509A646A01A99665417928B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xiDYAHl7ATpZ4kXXD2WYT6uwgwk Subject: [TLS] TLS Interim - Hotel 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: Thu, 24 Apr 2014 19:27:51 -0000 Hi Folks, Below are some suggestions for hotels near the meeting site. Its suggested= that you do not rent a car since the site is downtown and parking is expen= sive. If you are looking at another area hotel let me know and I can put yo= u in contact with a local host you can let you know if it is close and in a= good area. Also note that the site is near the Rockies stadium and there = is a Rockies game on Friday evening (6:40PM). =20 Embassy Suites - 1420 Stout, free hot breakfast, made to order omelets, etc= , free evening cocktails. =20 Westin - 1672 Lawrence Courtyard Marriott - 934 16th St Residence Inn Marriott - 1725 Champa, free full b-fast, free evening cockta= ils and food. Marriott - 1701 California Sheraton - 1550 Court Place Crowne Plaza - 1450 Glenarm Place SpringHill Suites - 1190 Auraria Prkwy, a little farther but from the offic= e .7 miles. Free hot b-fast and free shuttle within 3 miles. The Oxford, 1600 17th Street=20 Cheers, Joe= From nobody Thu Apr 24 18: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 9D1441A02B9 for ; Thu, 24 Apr 2014 18:32:48 -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 qIifw5cCLP7r for ; Thu, 24 Apr 2014 18:32:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 754471A0173 for ; Thu, 24 Apr 2014 18:32:46 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3P1WdEa026970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Apr 2014 03:32:39 +0200 (MEST) In-Reply-To: <0B76075A-D9F1-4780-8834-7FF0A1C82999@vigilsec.com> To: Russ Housley Date: Fri, 25 Apr 2014 03:32:39 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140425013239.7FE5E1ACE1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-m2XsbSy6KW_btrM4OkJdEKoQAg Cc: IETF TLS Subject: Re: [TLS] About encrypting SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 01:32:48 -0000 Russ Housley wrote: > > > I think Rich Salz has outlined very compelling reasons not to support SNI. > > While I might quibble with a detail here or there, I do agree with the > conclusion. If you need to protect SNI, then TOR or to a lesser extent > TLS-in-TLS can be used. I agree. If you need TOR, you should use TOR. Encrypted SNI comes at a huge cost, and could at best provide a benefit somewhere between completely negligible and absolutely none. Whether the service provider uses multiple services on a host at all, is up to the service provider. What name the service provider chooses is up to the service provider. Whether the content of the individual hosts is (close to) 100% distinguishable by its traffic patterns is up to the hosting provider, the service providers, the nature of their contents and the amount of (or lack of) cooperation/synchronization among the service providers. It would be crazy if any of the secret three agencies would spent a huge amount of protective efforts so that they could refer to their "secret hideout at 17, umpteen street" under the term "secret hideout at 17, umpteen street", instead of simply calling it an office or a laundry, or whatever. The server name is simply routing information. And it is not just load-balancers that may want to be able to use that information without having to open/terminate/participate the TLS communication, it's also easier and cleaner for implementations at the endpoint to do the server-side of TLS extension SNI "outside" of the TLS stack. -Martin From nobody Fri Apr 25 06:28: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 AC7A51A04AE for ; Fri, 25 Apr 2014 06:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6n2N9e3yffp for ; Fri, 25 Apr 2014 06:27:59 -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 F33141A01D4 for ; Fri, 25 Apr 2014 06:27:58 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6A738475AC for ; Fri, 25 Apr 2014 13:27:52 +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 4EF3D475A6 for ; Fri, 25 Apr 2014 13:27:52 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 0E4FE2026 for ; Fri, 25 Apr 2014 13:27:52 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 25 Apr 2014 09:27:51 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Fri, 25 Apr 2014 09:27:50 -0400 Thread-Topic: chacha/poly state? Thread-Index: Ac9gihTdQNy38vOiTIW8p/+P2Nth4g== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p20D3uKRPKZcWr09iP6xf_q9hA0 Subject: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 13:28:00 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What's the current state of the Cha-Cha/Poly document? Do things need chan= ging, identifiers assigned, or what? /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What’s the= current state of the Cha-Cha/Poly document?  Do things need changing,= identifiers assigned, or what?

&nb= sp;

       = ;         /r$

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge, MA

IM: rsalz@jabber.me; Twitte= r: RichSalz

 

<= /body>= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915USMBX1msgcorp_-- From nobody Fri Apr 25 07:53: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 D75231A04CD for ; Fri, 25 Apr 2014 07:53: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 Vem_gpubXroL for ; Fri, 25 Apr 2014 07:53:25 -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 0E3051A0300 for ; Fri, 25 Apr 2014 07:53:24 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so3432496ykq.28 for ; Fri, 25 Apr 2014 07:53:18 -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=O32iPF42SeeQ1bY6j9YeB/0GGYxxQQ1J/tlV9XsnPOY=; b=R1l5TY9KUvHlx7f14NoBC+hnhu4XaIB7bOpYJBYesmNLmXYOqalbgld0U6H882VNQN a7n6uBPMb2hoQetSIkNCqM+TdYu+LLAxXhXuEvSDjZOX8wLLNiVejEOp/semT82G7qRB TEOwdbn9hhm3KWu63/5+SlRh2lnUzSWghe8A8TZLinJ3VGaEjXK3AsbgK7vvuq4JsAAb ZzOBO/slAQLP1PxfA/Wx1f3+4t9jLzO9NeDiw8PAEKMb6wnLz3txK+6OEaSqhFiJ6gPD sfii2MXBKOMvurRJp8Wq4/oQEG34wLPn7w89haX+5XgokhlYz9BQYwXtam9iRUxtX1ee Gq9A== MIME-Version: 1.0 X-Received: by 10.236.134.71 with SMTP id r47mr12239414yhi.83.1398437598501; Fri, 25 Apr 2014 07:53:18 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 25 Apr 2014 07:53:18 -0700 (PDT) Date: Fri, 25 Apr 2014 07:53:18 -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/ydtOxch2tqbf9Wz4Jgjo49TpMlk Subject: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 14:53:27 -0000 Dear all, Some extensions aren't used by the TLS layer, like ALPN. One of the goals is to encrypt them. However, in a zero-RTT handshake this will require knowing a server key to encrypt them with. In a one-RTT handshake one can do the same thing. The challenge is the case where the client knows nothing about the server: here it cannot be encrypted until after the client hears from the server, and since this is a negotiation, another round trip after that. Having the server make the offer and the client accept one fits nicely into the 1-RTT handshake with no problems. However, this is not what we decided to do with ALPN. Any ideas? Sincerely, Watson Ladd From nobody Fri Apr 25 08:34: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 E77171A03B3 for ; Fri, 25 Apr 2014 08:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NAKznbtQOd0 for ; Fri, 25 Apr 2014 08:33:54 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2631A063F for ; Fri, 25 Apr 2014 08:33:48 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so3806537wgh.19 for ; Fri, 25 Apr 2014 08:33: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=T8r6Nb+HSxAFaHLYFfBXISPa5ycguclNa9PkKKkigJE=; b=JzlScii8v8mHMWQROK2UoSMGYSD3GvOlHZX10U5yrCycWtFbQDxTpoLoec6JbpzCMD DAJQ+QaCueaXFllZAejiJ6jDsg1Pmh6belBms3jKasoDfwH6OSFLLIzZgMkQEjEB1K+O kJ23zQ9f7s1q849IP/Sc8crrtB8L5Pjfkv3J7RVe8dn1urnyY2rFEpzHur2uWWtjvhxG jZ5GlgfrcFPr0q9ubN9h0E7R+3GpB/xBJW0x97UrdWlRSn0/OtVBpVUezoNC5lJ64ttn CWbdQi051n7ABZrViGC3vTyeXlLv1ptSSY43y2Myh2ajfFrS4x6MCGiJFiEzKtLEakX5 /K/Q== X-Gm-Message-State: ALoCoQk3Arq1TX0mfTuSkLa6KQ98O+lJjOGtptUWGjKxrITUnqqg2N1goEQ7yHoTbEmI0L1zsw/k X-Received: by 10.180.81.228 with SMTP id d4mr4173481wiy.49.1398440021298; Fri, 25 Apr 2014 08:33:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Fri, 25 Apr 2014 08:33:00 -0700 (PDT) X-Originating-IP: [173.196.57.82] In-Reply-To: References: From: Eric Rescorla Date: Fri, 25 Apr 2014 08:33:00 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d043bdb0eb6dae604f7dfb04d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1IgphutUbtoSRQ1w9m_7t1JahBs Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 15:34:00 -0000 --f46d043bdb0eb6dae604f7dfb04d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 25, 2014 at 7:53 AM, Watson Ladd wrote: > Dear all, > Some extensions aren't used by the TLS layer, like ALPN. One of the > goals is to encrypt them. However, in a zero-RTT handshake this will > require knowing a server key to encrypt them with. In a one-RTT > handshake one can do the same thing. > I think you mean this, but just for clarity, 0-RTT handshakes generally assume that the client knows the server's key, since the client is going to encrypt data to the server in the first flight using that key. The challenge is the case where the client knows nothing about the > server: here it cannot be encrypted until after the client hears from > the server, and since this is a negotiation, another round trip after > that. > > Having the server make the offer and the client accept one fits nicely > into the 1-RTT handshake with no problems. However, this is not what > we decided to do with ALPN. > It's worth mentioning that this actually entails a delay for the server in server-speaks-first protocols. I.e., in ALPN as soon as the server has selected the protocol it can start emitting data, whereas in a mode where the protocol selection is in the client's second flight, the server now has to wait for it. Of course, with HTTP, because the client speaks first, the client can piggyback the protocol selection message on the first request. > Any ideas? > draft-rescorla-tls13-new-flows-01 explores this a bit. First, if the client is really totally naive about the server, then if it wants to do ALPN it pretty much needs to send the ALPN information in the clear in the ClientHello, since the server might be TLS 1.2 or below and this is the time it can send it. However, if the client believes that the server is likely to be TLS 1.3, then there are some options... A. If we're attempting to encrypt SNI using an anonymous DH exchange as in Section 6, then we obviously get passive protection of the ALPN information for free. It's more work to get active protection, but since (a) SNI is probably more sensitive than ALPN and (b) the attacker can generally simulate being TLS 1.2 or below for naive clients, it's not clear how much that would help in any case. B. If we're not attempting to encrypt SNI (or we are using something like Andy's suggestion), then it seems like there are roughly four options: 1. Only encrypt the server's side of the ALPN negotiation, which contains the selection but not the client's side which contains the offer, as in Figure 6 in: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C 2. Allow only clients with previous state to encrypt the ALPN information, in both 0-RTT and 1-RTT cases, as in Figure 3 in: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.1 3. Have some in-band mechanism for the client to discover the server's keys, though this could be simplified from the flows in draft-rescorla-tls-new-flows-01, since the client can reveal the SNI in its first message and just get the server's keys then. 4. Have some out-of-band mechanism for the client to discover a server key and then encrypt it along with the rest of the ClientHello (basically what Andy suggested for SNI). Obviously, you could mix-and-match these to some extent. I.e., one could allow the client to either send the ALPN information in the clear if it has no previous state or encrypt it if it did, with DNS being one way to acquire said state. As Andy pointed out, the handshake state machine and message flows would be basically the same in both cases, except that the ClientHello would be encrypted in one and not the other. The major drawback, of course, is that you have two otherwise similar appearing modes with different privacy properties. -Ekr --f46d043bdb0eb6dae604f7dfb04d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 25, 2014 at 7:53 AM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
Dear all,
Some extensions aren't used by the TLS layer, like ALPN. One of the
goals is to encrypt them. However, in a zero-RTT handshake this will
require knowing a server key to encrypt them with. In a one-RTT
handshake one can do the same thing.

I = think you mean this, but just for clarity, 0-RTT handshakes generally
=
assume that the client knows the server's key, since the client is=
going to encrypt data to the server in the first flight using that key= .


The challenge is the case where the client knows nothing about the
server: here it cannot be encrypted until after the client hears from
the server, and since this is a negotiation, another round trip after
that.

Having the server make the offer and the client accept one fits nicely
into the 1-RTT handshake with no problems. However, this is not what
we decided to do with ALPN.

It's wo= rth mentioning that this actually entails a delay for the server
<= div>in server-speaks-first protocols. I.e., in ALPN as soon as the server
has selected the protocol it can start emitting data, whereas in a
mode where the protocol selection is in the client's second flig= ht,
the server now has to wait for it. Of course, with HTTP, beca= use
the client speaks first, the client can piggyback the protocol
selection message on the first request.

=A0
Any ideas?

draft-rescorla-tls13-new-flo= ws-01 explores this a bit.

First, if the clien= t is really totally naive about the server, then if it wants
to do ALPN it pretty much needs to send the ALPN information in the
clear in the ClientHello, since the server might be TLS 1.2 or below
and this is the time it can send it. However, if the client believes=
that the server is likely to be TLS 1.3, then there are some options..= .


A. If we're attempting to enc= rypt SNI using an anonymous DH exchange
as in Section 6, then= we obviously get passive protection of the ALPN
information for free. It's more work to get active protection, but= since
(a) SNI is probably more sensitive than ALPN and (b) the a= ttacker
can generally simulate being TLS 1.2 or below for naive c= lients,
it's not clear how much that would help in any case.

B. If we're not attempting to encrypt SNI (o= r we are using something
like Andy's suggestion), then it see= ms like there are roughly four
options:

1. Only encrypt the server's sid= e of the ALPN negotiation, which
contains the selection but not t= he client's side which contains
the offer, as in Figure 6 in:=


2. Allow only cl= ients with previous state to encrypt the ALPN information,
in both 0-RTT and 1-RTT cases, as in Figure 3 in:


3. Have some in-band mechanism for= the client to discover the server's
keys, though this could = be simplified from the flows in
draft-rescorla-tls-new-flows-01, = since the client can reveal the SNI
in its first message and just get the server's keys then.

4. Have some out-of-band mechanism for the client to disco= ver
a server key and then encrypt it along with the rest of t= he ClientHello
(basically what Andy suggested for SNI).


=
Obviously, you could mix-and-match these to some extent. I.e., o= ne
could allow the client to either send the ALPN information in = the clear
if it has no previous state or encrypt it if it did, with DNS being on= e way
to acquire said state. As Andy pointed out, the handshake s= tate machine
and message flows would be basically the same in bot= h cases, except
that the ClientHello would be encrypted in one and not the other.
The major drawback, of course, is that you have two otherwise
similar appearing modes with different privacy properties.

-Ekr



=
--f46d043bdb0eb6dae604f7dfb04d-- From nobody Fri Apr 25 09:28: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 E2A711A06A3 for ; Fri, 25 Apr 2014 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrOe1XR1x2fc for ; Fri, 25 Apr 2014 09:28:37 -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 E3E881A06EB for ; Fri, 25 Apr 2014 09:27:35 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id C75861145F; Fri, 25 Apr 2014 12:27:28 -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=6cAa4YHw7kbd RKi8ZEJsQQzY3q8=; b=SZqpiBF4JYYl3kY0YBNEz6oXglr+U2ct4/+A7/vh67yi 27F8LYGPBFwB4CGzqPIinOJ8HtgeZUt0bBDUng280SdXOkeriKTxbMskCqcUjeeS oFe2f/I7ObCwg6voTqDNxO77BgrLkxMw3xJCGj2dJjQc13PKHz/yWzlivRqnYG8= 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=ceu9dL KoWyqP0rI2PLe28mPD6jN8LPR79P/E6AcBbdDOmZ+0mJFBB9ajqzLyvuNkV2lHDN v8BsC3hf2w6+WmjSb3Qr83BD8aQD+BolQt3H/qbHx/sQ8E6kJwl/cg/kCMij4FP8 wLjhpIxr7BeKBvOkLrWRA21KpAKrAU1sTf42w= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BFC421145E; Fri, 25 Apr 2014 12:27:28 -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 E93D71145C; Fri, 25 Apr 2014 12:27:26 -0400 (EDT) Message-ID: <535A8CED.7030805@pobox.com> Date: Fri, 25 Apr 2014 09:27:25 -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: 7D57165E-CC96-11E3-B250-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tnlVusKBR20UZZ-DAnEbHhA3Hiw Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 16:28:40 -0000 Watson Ladd wrote: > > Some extensions aren't used by the TLS layer, like ALPN. ALPN is used by the TLS layer. The requested protocol is one of several inputs to a server's certificate selection algorithm, along with the SNI. Mike From nobody Fri Apr 25 09:58: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 95DA01A063B for ; Fri, 25 Apr 2014 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq6Bfr6OExWI for ; Fri, 25 Apr 2014 09:58:26 -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 E904E1A05CB for ; Fri, 25 Apr 2014 09:58: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 D6371115A8 for ; Fri, 25 Apr 2014 12:58:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=W8rvpecUJaC6bYxbdhBiIPTNh hc=; b=mefKvl0W/nwloPZREgOaThVdERX8NCIX+zs5jL6FN8FcJwSbh3EGOjynY cGpYE581TRwf8IX4kn7eONqM/Mlvp7byI8U6ZC+THmiUWoOOKR2AUiD9oHwYqDuz oU0R5ircsgzqUOXbykb/F44utyh+43yDe2SiyK+xRU6VKXubxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=yjqDxIKeG106JxzPAxt xH4SaFJTA1QY0rBEyY6mcnwxpIvysHVpa+Yvlyr/pgfsOCjpts6jDEXPOffMKJ4W U3FcXCVnJKS3ILcabb1+0mTLZe27zOyW0zyfaihxCa5XDK7G28AirP8Too/qZYEN tOCp5s4d4eHxRWxVZtceanPI= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id CC8F4115A0 for ; Fri, 25 Apr 2014 12:58:18 -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 F0DA71159D for ; Fri, 25 Apr 2014 12:58:16 -0400 (EDT) Message-ID: <535A9427.70207@pobox.com> Date: Fri, 25 Apr 2014 09:58:15 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CBFFE660-CC9A-11E3-9AE4-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3P08k0LzcZvUx1_-gmCuAWffgA4 Subject: [TLS] SSL v2 Client Hello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 16:58:27 -0000 Does anyone have any statistics on how often clients use SSL v2 client hello messages, while attempting to connect with SSL v3 or TLS, and won't retry with a "normal" hello if that fails? Thanks, Mike From nobody Fri Apr 25 10:06: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 192C81A0664 for ; Fri, 25 Apr 2014 10:06: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 M4SbDnEVuTAA for ; Fri, 25 Apr 2014 10:06:25 -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 2D6541A0669 for ; Fri, 25 Apr 2014 10:06:25 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so3006307wiv.3 for ; Fri, 25 Apr 2014 10:06:18 -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=Q2u8Yr7uGd5UJ4WMHpy7gRieil1cZSoIvz6dBHYYpuc=; b=CuzOXk6pXfvigWftWsk1TAPEJIQo5DooqZfT1tBBH6IeYVoev8iGP5v8XBciquj8i3 XdR10qItqT47q6aiCRh7ehiqYwQijNR3IFgtWp4MeaM5Zc5sXUg6Rx9h/hT6gghnJ/gQ /mKMjSjfGEI3z+7hlysx3Wew7wEaNDLip7Sb8RGj2E0Se5gNG5LYmHa4G2vYslEkL+qb z8o7l6rrkF/rlLfUg1iqTnyzAsyDqU/vu/4YIQcWBHd7ptf53iOrvkbnKNl30YmzH5N/ kejI7lV0AHqFU6qElVMwX/JWV/VmvE9MNlu/75yHAoriwKCZlMDfmq5clY1uyz5UA97x TAaA== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr7786289wjx.8.1398445578228; Fri, 25 Apr 2014 10:06:18 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 25 Apr 2014 10:06:18 -0700 (PDT) In-Reply-To: <535A8CED.7030805@pobox.com> References: <535A8CED.7030805@pobox.com> Date: Fri, 25 Apr 2014 10:06:18 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wRTZELVuTAGcg_F8942pqRKmJZA Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 17:06:30 -0000 On 25 April 2014 09:27, Michael D'Errico wrote: > ALPN is used by the TLS layer. The requested protocol is > one of several inputs to a server's certificate selection > algorithm, along with the SNI. I knew that this was going to be a possibility, but are people actually doing that already? From nobody Fri Apr 25 10:36:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B01A068B for ; Fri, 25 Apr 2014 10:36:20 -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 S-aqGNRBiYoj for ; Fri, 25 Apr 2014 10:36:18 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D21A0229 for ; Fri, 25 Apr 2014 10:36:17 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3PHa8la018393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Apr 2014 19:36:09 +0200 (MEST) In-Reply-To: <535A8CED.7030805@pobox.com> To: "Michael D'Errico" Date: Fri, 25 Apr 2014 19:36:08 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/INRDfyrvtxrAjlfnfYn4phBcF8s Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions 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, 25 Apr 2014 17:36:20 -0000 Michael D'Errico wrote: > Watson Ladd wrote: > > > > Some extensions aren't used by the TLS layer, like ALPN. > > ALPN is used by the TLS layer. The requested protocol is > one of several inputs to a server's certificate selection > algorithm, along with the SNI. I agree that the information is conveyed within the TLS protocol, so the TLS stack may need to be able to pass this information between TLS stack an application, but there is no need that the TLS stack uses this information for anything. With TLS extension SNI, the server side TLS stack might even completely ignore the information, i.e. not implement it. A Hosting provider could set up an SNI-aware load balancer and dispatch/NAT incoming TLS sessions in opaque fashion to individual TLS servers, and the individual server can just ignore the contents of TLS extension SNI (or may not even implement it), and virtual hosting would still work just fine. There would be no server name confirmantion in ServerHello extensions, but that is a quite irrelevant part of TLS extension SNI. -Martin From nobody Fri Apr 25 11: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 3918E1A06A5 for ; Fri, 25 Apr 2014 11:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhyx-ENwVm0w for ; Fri, 25 Apr 2014 11:21:01 -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 1E2A91A0665 for ; Fri, 25 Apr 2014 11:21:01 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AAE834821E; Fri, 25 Apr 2014 18:20: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 9E960481BD; Fri, 25 Apr 2014 18:20:54 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 35D8947C14; Fri, 25 Apr 2014 18:20:54 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 25 Apr 2014 14:20:42 -0400 From: "Gero, Charlie" To: "'mrex@sap.com'" , Michael D'Errico Date: Fri, 25 Apr 2014 14:20:42 -0400 Thread-Topic: [TLS] Encrypting ALPN and other unused extensions Thread-Index: Ac9grN2TA9DwgEGIQ7ej+ttogDJABwABR4ww Message-ID: References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> In-Reply-To: <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> 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/_vIRa4UQhZe_BrEenBJjZ8nJeNk Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2014 18:21:05 -0000 Why is there no need for the TLS stack to use this information? If SNI is = enabled, it can be what the server uses to select the certificate and possi= bly the cipher it chooses to use on servers where IP space is limited. In = your example, the dispatch server needs to use SNI (if not using distinguis= hable VIPs) in order to relay to the other machines. Cipher selection and = certificate presentation is part of TLS, and SNI can be used as a selector = for both. Additionally, Michael is correct in that ALPN could be used in t= he certificate selection process, but also in the cipher selection process.= If the argument is that the application is really the layer that is using= this information to inform the TLS layer what to do next, then that is sem= antics and hard to argue. But the intent is the same. SNI and ALPN can be= used to alter the path the rest of the handshake takes (and for many hosts= , will be the case). -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Friday, April 25, 2014 1:36 PM To: Michael D'Errico Cc: tls@ietf.org Subject: Re: [TLS] Encrypting ALPN and other unused extensions Michael D'Errico wrote: > Watson Ladd wrote: > >=20 > > Some extensions aren't used by the TLS layer, like ALPN. >=20 > ALPN is used by the TLS layer. The requested protocol is one of=20 > several inputs to a server's certificate selection algorithm, along=20 > with the SNI. I agree that the information is conveyed within the TLS protocol, so the TL= S stack may need to be able to pass this information between TLS stack an a= pplication, but there is no need that the TLS stack uses this information f= or anything. With TLS extension SNI, the server side TLS stack might even completely ign= ore the information, i.e. not implement it. A Hosting provider could set up an SNI-aware load balancer and dispatch/NAT= incoming TLS sessions in opaque fashion to individual TLS servers, and the= individual server can just ignore the contents of TLS extension SNI (or ma= y not even implement it), and virtual hosting would still work just fine. = There would be no server name confirmantion in ServerHello extensions, but = that is a quite irrelevant part of TLS extension SNI. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Apr 25 19:34: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 BDC861A02D2 for ; Fri, 25 Apr 2014 19:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCov7rsu8QbF for ; Fri, 25 Apr 2014 19:34:33 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E692A1A03DB for ; Fri, 25 Apr 2014 19:34:32 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id c41so3089868yho.33 for ; Fri, 25 Apr 2014 19:34: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=geEgxF/PIL3hzIm/zujuGAUS6D6FvuDVkeEgB4CqstY=; b=ith61Wbe04AHo5cGvaO8huhxK5uopGL1SDUPPEL7B+06pXEQB5Lo8i+f7GElIKzTpc K0Wn2KoIAdQRRcM7zuCox7q1ObVUQSdY4uQvYzcqmja+rjL4y2t3qhFdAsAgM2z7K1R7 3S7GaTp0f4WAW9wjEhB8lkj+kr2xNCmajGKD+TBQ8KYUAJYBLnXVzIf14YqPkK/Q/EK1 iaWXh5ACt47GzMPO8PuRXJgFaywRTm1bHFj/JvA/6Wx34A5IaSE7KN8jGBcz109Y3xo3 k8E4ucpN4eIlsSFJqWVB7+DQfAmDpq6d0768O/NHPPWyixARAVbVhVeiOy0RPupWFUm+ 9V5w== MIME-Version: 1.0 X-Received: by 10.236.94.197 with SMTP id n45mr17156023yhf.46.1398479666235; Fri, 25 Apr 2014 19:34:26 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Fri, 25 Apr 2014 19:34:26 -0700 (PDT) In-Reply-To: References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> Date: Fri, 25 Apr 2014 19:34:26 -0700 Message-ID: From: Watson Ladd To: "Gero, Charlie" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dVIxCENKMh3SEzgt5h1kaZ1oOEs Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2014 02:34:35 -0000 On Fri, Apr 25, 2014 at 11:20 AM, Gero, Charlie wrote: > Why is there no need for the TLS stack to use this information? If SNI i= s enabled, it can be what the server uses to select the certificate and pos= sibly the cipher it chooses to use on servers where IP space is limited. I= n your example, the dispatch server needs to use SNI (if not using distingu= ishable VIPs) in order to relay to the other machines. Cipher selection an= d certificate presentation is part of TLS, and SNI can be used as a selecto= r for both. Additionally, Michael is correct in that ALPN could be used in= the certificate selection process, but also in the cipher selection proces= s. If the argument is that the application is really the layer that is usi= ng this information to inform the TLS layer what to do next, then that is s= emantics and hard to argue. But the intent is the same. SNI and ALPN can = be used to alter the path the rest of the handshake takes (and for many hos= ts, will be the case). For SNI this is true. But ALPN? Remember it was introduced to handle HTTP 2.0 vs HTTP 1.0: I don't see people rushing out to use different certs per protocol. Authenticating services is an interesting idea, but if I trust a host, I can trust what it tells me about which service I connect to. (Paul Lambert asked me a related question: does TLS ensure that I'm talking to the right *port*? A quick read of RFC 5246 indicates it doesn't) Just because it's possible to pick a certificate based on something, doesn't mean people do it. Secondly, I don't like the idea of having two handshakes with different security properties. The lower one is the only one you can be sure you will get. I also think that forcing 1-RTT to depend on knowing a semi-static key is unnecessary, and while browsers will do it, it's more generally useful and so we should work to preserve it for programmatic clients. (Yes, programmatic clients can use an interface for storing these keys. However, it is more complicated than if they do not, and makes the API a bit messy) 0-RTT requires a semi-static key: no two ways around it. Sincerely, Watson Ladd > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Friday, April 25, 2014 1:36 PM > To: Michael D'Errico > Cc: tls@ietf.org > Subject: Re: [TLS] Encrypting ALPN and other unused extensions > > Michael D'Errico wrote: >> Watson Ladd wrote: >> > >> > Some extensions aren't used by the TLS layer, like ALPN. >> >> ALPN is used by the TLS layer. The requested protocol is one of >> several inputs to a server's certificate selection algorithm, along >> with the SNI. > > I agree that the information is conveyed within the TLS protocol, so the = TLS stack may need to be able to pass this information between TLS stack an= application, but there is no need that the TLS stack uses this information= for anything. > > With TLS extension SNI, the server side TLS stack might even completely i= gnore the information, i.e. not implement it. > > A Hosting provider could set up an SNI-aware load balancer and dispatch/N= AT incoming TLS sessions in opaque fashion to individual TLS servers, and t= he individual server can just ignore the contents of TLS extension SNI (or = may not even implement it), and virtual hosting would still work just fine.= There would be no server name confirmantion in ServerHello extensions, bu= t that is a quite irrelevant part of TLS extension SNI. > > > -Martin > > _______________________________________________ > 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 Apr 25 22:20: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 1DA641A044F for ; Fri, 25 Apr 2014 22:20:23 -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 Ac3gbzYQMZow for ; Fri, 25 Apr 2014 22:20:21 -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 493CB1A0673 for ; Fri, 25 Apr 2014 22:20:21 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id k48so4318095wev.25 for ; Fri, 25 Apr 2014 22:20: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=Y9tT2bJw4ZVac+Nm7ZYiCfCRKFDV0tVO8C151DOiK7I=; b=JsnYvzGcnkCkC7GoZAbYJ6RYlNy8OQOVUQNJsB0w2YU19s1Bh1TdKXZgSoe4MdaHtB TqkekNPx1XK8OmhvoIZvyHzv9D97DFyy6meTn0q2lTBP29v+MAapdUUxkkGuO6da5ap7 cwmQFHm647Kg0fpUR9s89EEx6vUxa3m6iCU5N9ZKrvqossOIfXFmtjLJ7LApsijjjngO sCU+yPkhYq2i5QjBPr7HPhp5PKYHuJwv0m25tutnUVW6EsLKDN3/51x6KA1zX93v3MUM BHKDPwNA1QkTTZ9VnPIyZKyH8oqKwvwsC7sy/fICbiLhwspFRv3c5H2+VeUjPyAFO2B5 UgJg== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr6574152wiy.50.1398489614276; Fri, 25 Apr 2014 22:20:14 -0700 (PDT) Received: by 10.227.144.132 with HTTP; Fri, 25 Apr 2014 22:20:14 -0700 (PDT) In-Reply-To: References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> Date: Fri, 25 Apr 2014 22:20:14 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tUnUoECVAECQcLAdPjcqNV3BETw Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2014 05:20:23 -0000 On 25 April 2014 19:34, Watson Ladd wrote: > does TLS ensure that I'm talking to the right *port*? That's a PKIX function, but the answer is no, mostly [RFC6125]. We authenticate names, even though it is theoretically possible to authenticate URIs, I don't think that it is used in many places and there has been anything in between defined. From nobody Sat Apr 26 00: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 E40CC1A00E3 for ; Sat, 26 Apr 2014 00:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcrVJ0Zh-ZnV for ; Sat, 26 Apr 2014 00:37:36 -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 545CE1A00E2 for ; Sat, 26 Apr 2014 00:37:36 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 910FEF57D; Sat, 26 Apr 2014 03:37:28 -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=qvCmoVUrSVsO 02TKJsCDrj30v24=; b=Gm4OJdBNDl0uME200Z+c5BzG8J9c5qgfZb212Easas7q QaL0DD+THuJmV6H+NRz8yxG/+j66e8yT4tyLL4ealL58ppNQwqh/B/R9hubVQm6u 0ysogmPHesrusIp8SO0xBcm3/UakzQ5+J+L03dzDKYcqO2CA/C4J2uaqrJQLMk0= 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=HYdhMZ UeYBNBPsld3Z+dkkD/HMGW0gcpGZ3FwWc5fN4RP4OmIGCWc6fruQbzdgthZajlG0 yuu6nxzLevVFwygJaNu7nuiDiwpfzcAIlmwxV+9PSdb/rxzB8yR++6cvAQBgKKJB bzuZucGLG1PxCmJGsGlwoXSsgs/ObBvTwZSzE= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 871A7F57C; Sat, 26 Apr 2014 03:37:28 -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 AAAC5F57B; Sat, 26 Apr 2014 03:37:26 -0400 (EDT) Message-ID: <535B6235.9090907@pobox.com> Date: Sat, 26 Apr 2014 00:37:25 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Watson Ladd References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9D54CA9E-CD15-11E3-A125-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rh4Wv-0JmoJN6aPU_fGuAZtG8Cw Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2014 07:37:39 -0000 Watson Ladd wrote: > On Fri, Apr 25, 2014 at 11:20 AM, Gero, Charlie wrote: >> SNI and ALPN can be used to alter the path the rest of the handshake takes (and for many hosts, will be the case). > > For SNI this is true. But ALPN? Remember it was introduced to handle > HTTP 2.0 vs HTTP 1.0: I don't see people rushing out to use different > certs per protocol. It's a bit premature to inter ALPN when it hasn't yet been published as an RFC. Why don't you like it? Mike From nobody Sat Apr 26 07:48: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 EED2E1A04C8 for ; Sat, 26 Apr 2014 07:48:28 -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 V3e5wnsnUWzs for ; Sat, 26 Apr 2014 07:48:28 -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 3911B1A04B4 for ; Sat, 26 Apr 2014 07:48:28 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3QEmIBG059491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Apr 2014 07:48:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Sat, 26 Apr 2014 07:48:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18A8EEAE-86BA-49C8-A54A-370123402B25@vpnc.org> References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> To: Martin Thomson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Ts_6NkRE70MHBvo9jjBC7m-_y8 Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2014 14:48:29 -0000 On Apr 25, 2014, at 10:20 PM, Martin Thomson = wrote: > On 25 April 2014 19:34, Watson Ladd wrote: >> does TLS ensure that I'm talking to the right *port*? >=20 > That's a PKIX function, Not at all true. > but the answer is no, mostly [RFC6125]. =20 And not even there. :-) There are no certificate fields that specify the port on which the = server is running, and even RFC 6125 only talks about services, which = can (and often are) run on ports other than their "default" port. Even = the widely-derided key usage field doesn't specify a port.=20 > We > authenticate names, even though it is theoretically possible to > authenticate URIs, I don't think that it is used in many places and > there has been anything in between defined. RFC 6125 says plenty about naming with URIs, as does the base PKIX spec; = neither specifies any operational way to authenticate past the host = name. --Paul Hoffman= From nobody Sat Apr 26 08: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 88B041A0389 for ; Thu, 24 Apr 2014 12:56: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 EQJAtjtw0GKe for ; Thu, 24 Apr 2014 12:55:59 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BE7411A037A for ; Thu, 24 Apr 2014 12:55:59 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wp4so3224338obc.35 for ; Thu, 24 Apr 2014 12:55:53 -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=ZJ8dXL5WdpsC7J/XA8jEUnfs12Ms0oKNu2Jq3x2hO5I=; b=FAcE/fK7Q3N3wAacat+/XJzI/VDMU7up0cVECRh3uuqRKQ5HpO9FKkKzgDWLOFSuV0 RyP4wyWDIP4EFgqdrqPzqajNw4wdq+jzpWQooGn9DPZtZ51F0KKmFbPn/sAJqxPQ/tZk gYJk/27QNOf+Ocx/Rjcjup4t/KzNJOkjyU3/THia7L2b90upo5e9b/rkvJdql8w+Bnur dEz4mCFYtcUc6H5WToy8EeH7WHvwsiN1NJ/DJmVGyxg9KqJRz8995BstYNdha/zJXxns A5R4uq81L9d1VQK62GpNOAo29OO0WpeqkS+Am8GXIPoJ/4aY619b/Lp2lnOILflV6Ib+ /o8w== MIME-Version: 1.0 X-Received: by 10.60.77.35 with SMTP id p3mr3167722oew.46.1398369353500; Thu, 24 Apr 2014 12:55:53 -0700 (PDT) Received: by 10.182.81.73 with HTTP; Thu, 24 Apr 2014 12:55:53 -0700 (PDT) Date: Thu, 24 Apr 2014 21:55:53 +0200 Message-ID: From: Klemens Baum To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1BXcezHANteoXyHKINRg49smKoQ X-Mailman-Approved-At: Sat, 26 Apr 2014 08:06:12 -0700 Subject: [TLS] Status of X.509v3 TLS Feature 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: Thu, 24 Apr 2014 19:56:01 -0000 After the whole Heartbleed incident, it has become obvious that the current mechanisms for Certificate Revocation are inadequately enforced by clients. To combat the issue, it would seem desirable for a security-conscious server operator to be able to require the use of OCSP stapling on a per-certificate basis. There was already an Internet-Draft (now expired) for an X.509v3 extension which would provide this feature: https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ Clients supporting the extension could display an enhanced security indicator (e.g. "Certificate Status: Not revoked") for certificates carrying the extension which pass validation, which would also motivate more widespread adoption of OCSP stapling in favor of CRLs and client-initiated OCSP requests. Since the draft looked very promising, I suggest that it should be unexpired. If anyone with the authority to do so agrees, please submit a request for resurrection per the guidelines at http://www.ietf.org/ietf-ftp/1id-guidelines.txt. A few minor clarifications may still be needed so that it can be quickly implemented by major browsers and the CAs: - The tls-feature OID is currently specified with a value of { id-pe 1 }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself already an X.509v3 extension). Surely a new OID in the pkix.privateExtension arc will need to be allocated by IANA and if this is the case, it should be noted in the section "IANA Considerations". Please share your opinions! From nobody Sat Apr 26 08:24:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247571A0290 for ; Sat, 26 Apr 2014 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 96mh7I3bX5_j for ; Sat, 26 Apr 2014 08:24:23 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0042E1A022E for ; Sat, 26 Apr 2014 08:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=674; q=dns/txt; s=iport; t=1398525856; x=1399735456; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=FEHzm58+V/irQdqWsqYD1HK4XWx3hPT3dLoAOZAa67o=; b=cY2ekJNE3AJTdmSW/ddHTU1CeA6ui08za845NeO7217lwvXGPgqBKgrL iZhYn3PoZ7wwzGgVX8APVcZRNhVqpSTcT9iYBeoxhxoU3h3Rp3bBlfdma HIgVw0fGNgQn+NureWhBsuqCQW6kBfm42Sa2CdPbqqu3PzEZpIyTIPHSb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAOnOW1OtJV2c/2dsb2JhbABZgwaBJsRagQsWdIIlAQEBAwE6RAsCAQg2EDIlAgQTiDkIyg8XjiY6gySBFQEDmQySXoMxgis X-IronPort-AV: E=Sophos;i="4.97,933,1389744000"; d="scan'208";a="39012088" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 26 Apr 2014 15:24:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3QFOFY0004396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 26 Apr 2014 15:24:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 10:24:15 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Confirmation of Consensus on Removing Compression from TLS 1.3 Thread-Index: AQHPSSMxZ0z0INsV8EeHhSnGu4GmzJskiLQA Date: Sat, 26 Apr 2014 15:24:14 +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: [10.85.164.213] 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/GytiqGDGuyUd9cLLmJCqzW5gX88 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, 26 Apr 2014 15:24:24 -0000 We have strong confirmation of consensus to remove compression from TLS 1.3= . The Editor is requested to make the appropriate changes to the draft on= github. Joe [For the chairs] On Mar 26, 2014, at 11:42 AM, Joe Salowey wrote: > The use of compression within TLS has resulted in vulnerabilities that ca= n 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 thi= s attack vector. If you have concerns about this decision please respond o= n the TLS list by April 11, 2014. >=20 > Thanks, >=20 > Joe > [Speaking for the TLS chairs] From nobody Sat Apr 26 08:24:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03B1A0503 for ; Sat, 26 Apr 2014 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 4SS499PbVMfU for ; Sat, 26 Apr 2014 08:24:32 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1973B1A04F6 for ; Sat, 26 Apr 2014 08:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1214; q=dns/txt; s=iport; t=1398525865; x=1399735465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3vQoDXw2SlJYg4y5yWKzQO95nIfcjGHOOW5cxBZEQoU=; b=LgAl1ODPzmfWcSgJ7XBg7TacbqnBj3NZcobeynHzPl2XMdLGWC2veeFt +OPGLVkRiejjACSMTjTNzn8tMulSEUrwtkbyzMSqg+TMmgfiVlNemUp/M VggmcOCIn35KR6MDxHbElC1zZCzg4tF2yX1r62dlzS/1k9F/4FF4DnN4Y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQFAMDOW1OtJA2B/2dsb2JhbABZgwZPSwEBCr0hhzmBCxZ0giUBAQEDAQEBATc0CwULAgEINhAnCyUCBA4FiDkIDcoCEwSOJjMHgySBFQSZDJJegzGCKw X-IronPort-AV: E=Sophos;i="4.97,933,1389744000"; d="scan'208";a="38999400" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 26 Apr 2014 15:24:24 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s3QFOOGh016475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 26 Apr 2014 15:24:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 10:24:24 -0500 From: "Joseph Salowey (jsalowey)" To: "Joseph Salowey (jsalowey)" Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: AQHPSSM6qiIeFUDRHUase0LCUT6SLpskiL+A Date: Sat, 26 Apr 2014 15:24:22 +0000 Message-ID: <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> In-Reply-To: <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.85.164.213] 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/TFhtZ--Fbed39F7w5l3t3BwL0UA 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: Sat, 26 Apr 2014 15:24:34 -0000 The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record = layer protection of type AEAD. The Editor is requested to make the appropri= ate changes to the draft on github. Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: > TLS has supported a number of different cipher types for protecting the r= ecord 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 t= o be flawed and stream ciphers are not generally applicable to DTLS. Using = a single mechanism for cryptographic transforms would make security analysi= s easier. AEAD ciphers can be constructed from stream ciphers and block c= iphers and are defined as protocol independent transforms. The consensus i= n the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you h= ave concerns about this decision please respond on the TLS list by April 11= , 2014. >=20 > Thanks, >=20 > Joe > [Speaking for the TLS chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Apr 26 08: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 447A41A06A1 for ; Sat, 26 Apr 2014 08:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 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.272, 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 9d1AJP-j0RYN for ; Sat, 26 Apr 2014 08:24:48 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC311A0693 for ; Sat, 26 Apr 2014 08:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1311; q=dns/txt; s=iport; t=1398525882; x=1399735482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2Ws3+BKjMfVVrWcn4b24OV4wktNw69qELzFh4Pr7N00=; b=Re+9ktJPlqN+2ipEG8PjeuJZsUFpGE0ycRmta6tWV6+/0DGJAxzoHlID Kwm30e782aJpOcWiL9VthFtK924sBvuye7lU3VsBJPUb12dVupvJhCbEO HjgvOpvK8AAOGLPo/laMQpBM/acXkhTsvIa7saCssh4GndUJzKv7eXKmL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQFAOnOW1OtJA2J/2dsb2JhbABZgwZPSwEBCr0hhzmBCxZ0giUBAQEDAQEBATc0CwULAgEINhAnCyUCBA4FiDkIDcoCEwSNdjAzB4MkgRUEmQySXoMxgis X-IronPort-AV: E=Sophos;i="4.97,933,1389744000"; d="scan'208";a="39012116" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP; 26 Apr 2014 15:24:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3QFOfxi010784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 26 Apr 2014 15:24:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sat, 26 Apr 2014 10:24:41 -0500 From: "Joseph Salowey (jsalowey)" To: "Joseph Salowey (jsalowey)" Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 Thread-Index: AQHPYWOkH+R/q97eyEeI9DhvY7dbHQ== Date: Sat, 26 Apr 2014 15:24:41 +0000 Message-ID: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.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.85.164.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B93E3486FEE844E9601F4AB36DEE632@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ex3RQtqcM-YN2CND_VGHrczQwt8 Cc: "" Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 15:24:50 -0000 The discussion on this list and others supports the consensus in IETF 89 to= remove RSA key transport cipher suites from TLS 1.3. The Editor is reques= ted to make the appropriate changes to the draft on github. More discussion is needed on both DH and ECDH are used going forward and on= if standard DHE parameters will be specified. Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) 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. >=20 > Thanks, >=20 > Joe > [Speaking for the TLS chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Apr 26 08:36: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 AAFDF1A04E9 for ; Sat, 26 Apr 2014 08:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux-wP9XBtfVo for ; Sat, 26 Apr 2014 08:35:58 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id E65CC1A01DA for ; Sat, 26 Apr 2014 08:35:57 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id z12so3576357wgg.10 for ; Sat, 26 Apr 2014 08:35: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=QGTEsf7isGKg/9bcw6dMruImJwz1XTGX41bHR0khSnY=; b=DqYo1lDumK21K44I39R8E8+2kKEwE3qbi6sUw+gyzR3cZH04CytAvC0SiVsM6JKDFs gDQJoCjvbswT5bpW912ipt+njxftZ3g7gRP3E+DvOG4C5A4Dw4Fl+/xaB2yehDD3+0Ab rugAwdPlGVlDKoNvK5QA6XKNvfOpBL8ZWbx8Ko7nlbchTUHzLAQXTfH+ex4lkG7AF/9N 9Aq7emxSQVrQniQemKO4BDy0vT87OPctxqnbKZhJGuxpamnPNNWbYktXgpyYuYUB033U C+2ZjRBmQCadGUhY8egl7ri1N9XG55GiISfL8Hky/v8nZN3EqpvLqEWhZSBk4YbnOxTM P/mQ== X-Gm-Message-State: ALoCoQnSeES/VnC/5fTb6KE6bs62oKiE6Bo3Iu3qFtm7JyN4ddIcoWnSAlCWMbhRbK0c4RGTtRWf X-Received: by 10.194.187.107 with SMTP id fr11mr36988wjc.70.1398526550625; Sat, 26 Apr 2014 08:35:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sat, 26 Apr 2014 08:35:10 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sat, 26 Apr 2014 08:35:10 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=047d7bb03f604262f704f7f3d66b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ShFIidDSDjSHEUdVbxFF4yF_DLk 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, 26 Apr 2014 15:35:59 -0000 --047d7bb03f604262f704f7f3d66b Content-Type: text/plain; charset=ISO-8859-1 Acknowledged. I will prepare these changes (and those for the other two issues) as git pull requests and notify the list so that people can confirm that the changes accurately capture the consensus of the WG. -Ekr On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > We have strong confirmation of consensus to remove compression from TLS > 1.3. The Editor is requested to make the appropriate changes to the draft > on github. > > Joe > [For the chairs] > On Mar 26, 2014, at 11:42 AM, Joe Salowey 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 > --047d7bb03f604262f704f7f3d66b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Acknowledged.

I will prepare these chan= ges (and those for the other two issues) as git pull
requests and= notify the list so that people can confirm that the changes
accu= rately capture the consensus of the WG.

-Ekr



On Sat, Apr 26, 2014 at 8:24 AM= , Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
We have strong confirmation of consensus to = remove compression from TLS 1.3. =A0 The Editor is requested to make the ap= propriate changes to the draft on github.

Joe
[For the chairs]
On Mar 26, 2014, at 11:42 AM, Joe S= alowey <jsalowey@cisco.com>= wrote:

> The use of compression within TLS has resulted in vulnerabilities that= can be exploited to disclose TLS encrypted application data. =A0 The conse= nsus in the room at IETF-89 was to remove compression from TLS 1.3 to remov= e this attack vector. =A0If you have concerns about this decision please re= spond on the TLS list by April 11, 2014.
>
> Thanks,
>
> Joe
> [Speaking for the TLS chairs]

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

--047d7bb03f604262f704f7f3d66b-- From nobody Sat Apr 26 11:30: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 EBA851A0386 for ; Sat, 26 Apr 2014 11:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN2GamYpigvw for ; Sat, 26 Apr 2014 11:30: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 224B01A02CC for ; Sat, 26 Apr 2014 11:30:17 -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=1398537013; x=1430073013; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=6YaRYXJwNGT6P8Y5Ww3/8q4aJCNgdpAb8dTS47fJKMw=; b=FNXo3nIQoXwhu6JgVt4Xdx+WO2G9e4Yzwd5Bo/rk3Gur+e6kifIcivlF ES2zh4JVY8humWdZmvDHl/ZJreYK7taFuPEwKGAOEmUEuIHYfeR18v/S+ rpxRb13o/nnAGATl2sVWmjA4u9cXjYnCmmieGx+RLrIJqU3zvhdz+4RhR g=; X-IronPort-AV: E=Sophos;i="4.97,934,1389697200"; d="scan'208";a="248785332" 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; 27 Apr 2014 06:30:09 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Sun, 27 Apr 2014 06:30:09 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Encrypting ALPN and other unused extensions Thread-Index: Ac9hfY2ZmNeaL6zMT+a9OyXPtuIAGQ== Date: Sat, 26 Apr 2014 18:30:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC08D0B@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/QHwtHUuPPtjZCob3i1VnYDZ0crY Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Apr 2014 18:30:22 -0000 Paul Hoffman writes:=0A= =0A= >RFC 6125 says plenty about naming with URIs, as does the base PKIX spec;= =0A= >neither specifies any operational way to authenticate past the host name.= =0A= =0A= While they don't specify how to do it, they also don't say that you can't j= ust=0A= say host:port in the standard manner. You'd need to update software to han= dle=0A= this, but at least it's a fail-closed mechanism, if the implementation does= n't=0A= understand host:port then it won't connect.=0A= =0A= (Well, it shouldn't connect, given the hit-and-miss nature of hostname=0A= checking it may connect no matter what the string is).=0A= =0A= Peter.=0A= From nobody Sat Apr 26 17:27: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 A2AAD1A0706 for ; Sat, 26 Apr 2014 17:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FwvLz9jc2oo for ; Sat, 26 Apr 2014 17:27:52 -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 E03F51A0705 for ; Sat, 26 Apr 2014 17:27:51 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5AE58113EA for ; Sat, 26 Apr 2014 20:27:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=Q0gWhVpp2pnikwj5RcQrIQG/v 4A=; b=PnuhdMbiXpyPIdA+dP0WpLQuCF0lr3txlTQ9QcKVb4lLqCGwRawo/T6/I QDAXXy8tgmSNbWjvhZxRo+mvMKzNbsV9lMA9E7gY/llNcLyd2Ss3Op0N7bOWKsVM nx0V1+RhWZRfT2/QSkFT/kACxxPDFBveHKPCDEqD3I79P3fWRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=gpctkuT5GnDsSpIauRK eAGBeQ0gQMYfZCSBfeOw7b54kIoaT6ovbWN8KsKpKhKshgO5iDYvwW5cqne2ytnU dOPZYtWQmFDu5Lk8G+mobvepMmg/n23gdELL4jLwhq59c+896VvMIjk+PxypBZUx Q4BtVEyh5OOvrtkWF8fZHR74= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 53E01113E8 for ; Sat, 26 Apr 2014 20:27:44 -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 64234113E7 for ; Sat, 26 Apr 2014 20:27:42 -0400 (EDT) Message-ID: <535C4EFD.7030608@pobox.com> Date: Sat, 26 Apr 2014 17:27:41 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: BF0D9142-CDA2-11E3-8BC5-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5ZLehPM7EAZUa-VO7cII_8E18XY Subject: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 00:27:53 -0000 Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec. due to the random padding? There is a requirement to add at least 16 bytes of random padding to every message: struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage; ... padding: The padding is random content that MUST be ignored by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. Furthermore, the length of the type field is 1 byte, and the length of the payload_length is 2. Therefore, the padding_length is TLSPlaintext.length - payload_length - 3 for TLS and DTLSPlaintext.length - payload_length - 3 for DTLS. The padding_length MUST be at least 16. The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes. The padding of a received HeartbeatMessage message MUST be ignored. Since the recipient MUST ignore the padding, they can't reverse engineer the peer's PRNG, so maybe this isn't a problem? Mike From nobody Sun Apr 27 05:08:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1546C1A078D for ; Sun, 27 Apr 2014 05:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnJnz3yymO-5 for ; Sun, 27 Apr 2014 05:08:11 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BA5CE1A0782 for ; Sun, 27 Apr 2014 05:08:11 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so6942580veb.29 for ; Sun, 27 Apr 2014 05:08:11 -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=ZrirYfKk0yrFKUgzjwNZwiwUflGcRiTdy1+rke6j8Bw=; b=nCAh3xnNDeKx5a2N1x98iUhNUI8oVybAFueLOTmXDLh4EmX21dTlLrANo9Y39rnuqj Nu9mrx8uhvgrEHWrF/7n139cSdRLkVidz/tpwROTAc9MBokc7zHMfAMc2W5q0nFT6m/V HeEM+f4ikjeow/0POvMry0LUoa9dIbVn57mw8= 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=ZrirYfKk0yrFKUgzjwNZwiwUflGcRiTdy1+rke6j8Bw=; b=U6l6EQQJQSYZQCjGF2MamdJ1+sTlyUILscDjHH87E4nFIrv/SgQ7BAh64gl3tluUSP BUd+ARzC00ShxlwXZOLr2Kqoa0NP74yN19pXbClzdt3Q1JQW0P7bW1h9mFNfy8nHOhF8 ZRyVE0lcxdFkbBDIdPPU80X+mlRRq9W0kE4aAvvY9b0N9hwKB/wyxsab1OrL0iYPhPx6 xg78YRsWWS8l/cj83VIiLujBxQIm9m3TBnXZkZsyWGFZ3T2HTRt0GaIIfpIMsfHNXfQz rXdveLnaIhWgRniDMYIihjZN79prf5jNNdti5xlneNtW+gGLJAxEJS4+nZ8h8SwNUywj 1dWw== X-Gm-Message-State: ALoCoQkjjB2+ro3rHDHuDAG0uYi2FBrEYnjVOmNEZiBXz0SsI2fGm3gfUY03Ytxd7WzOfO0BjF98 X-Received: by 10.52.90.37 with SMTP id bt5mr15219218vdb.7.1398600491128; Sun, 27 Apr 2014 05:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.88.101 with HTTP; Sun, 27 Apr 2014 05:07:51 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Sun, 27 Apr 2014 08:07:51 -0400 Message-ID: To: Klemens Baum Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h7ktagFw7Xse3TclZkxRh-luWoY Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Sun, 27 Apr 2014 12:08:13 -0000 There isn't much gain in requiring it on a per-certificate basis, but on a host basis it makes a lot more sense. (Not that putting it on a cert is bad, just insufficient.) There were a couple ideas for making this a header here: http://www.ietf.org/mail-archive/web/tls/current/msg10351.html I too would like Must Staple to come back. -tom On 24 April 2014 15:55, Klemens Baum wrote: > After the whole Heartbleed incident, it has become obvious that the > current mechanisms for Certificate Revocation are inadequately > enforced by clients. > > To combat the issue, it would seem desirable for a security-conscious > server operator to be able to require the use of OCSP stapling on a > per-certificate basis. There was already an Internet-Draft (now > expired) for an X.509v3 extension which would provide this feature: > https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ > > Clients supporting the extension could display an enhanced security > indicator (e.g. "Certificate Status: Not revoked") for certificates > carrying the extension which pass validation, which would also > motivate more widespread adoption of OCSP stapling in favor of CRLs > and client-initiated OCSP requests. > > Since the draft looked very promising, I suggest that it should be > unexpired. If anyone with the authority to do so agrees, please submit > a request for resurrection per the guidelines at > http://www.ietf.org/ietf-ftp/1id-guidelines.txt. > > A few minor clarifications may still be needed so that it can be > quickly implemented by major browsers and the CAs: > > - The tls-feature OID is currently specified with a value of { id-pe 1 > }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself > already an X.509v3 extension). Surely a new OID in the > pkix.privateExtension arc will need to be allocated by IANA and if > this is the case, it should be noted in the section "IANA > Considerations". > > Please share your opinions! > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Apr 27 08: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 BEE2F1A022E for ; Sun, 27 Apr 2014 08:42:09 -0700 (PDT) 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 qByS973beYHa for ; Sun, 27 Apr 2014 08:42:08 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3C85D1A01D2 for ; Sun, 27 Apr 2014 08:42:07 -0700 (PDT) Received: from localhost ([::ffff:88.128.80.144]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sun, 27 Apr 2014 17:42:05 +0200 id 0000000000020014.00000000535D254E.000056AA Date: Sun, 27 Apr 2014 17:41:49 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20140427174149.7e1fa528@hboeck.de> In-Reply-To: <535C4EFD.7030608@pobox.com> References: <535C4EFD.7030608@pobox.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-22186-1398613326-0001-2" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FVGDXr-4wry-RpcPTlKnebNzNvw Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 15:42:09 -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-22186-1398613326-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 26 Apr 2014 17:27:41 -0700 Michael D'Errico wrote: > Not related to Heartbleed(tm), do we need to revisit the Heartbeat > spec. due to the random padding? I've been trying to find out any uses for Heartbeat in the past weeks and have asked lots of people (also on this list). I got lots of "you could use it for this and that", but not a single pointer to a real piece of software doing anything with it. If you have any use case (a real one, not a fantasy one) come back and talk about fixing it. Until then: The "fix" for all problems with the Heartbeat extension is to disable it. tl;dr: TLS became too complex. Getting rid of unused extensions and features is the first step to fix that. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-22186-1398613326-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) iQIcBAEBCgAGBQJTXSU9AAoJEKWIAHK7tR5COn8QAK8wTW+Sq/7GCueEJgNnQJbu wwOhSmYvzleVHDuVB9M+VEhTFxwQZqg5oRSI7kQI9JowXcchHx7WfArKm9Jq8qqn uaefhANBaXtqeBGkf53EzbDa9zg0OiKXzOJSRNpHy8YFmyaGNsWqxsZr9h8E7YCF LjgD4aw/i72nUjbB30GAZp9z6zeTaG1KjX0avv2koXk6ZZRhJcdXPdP5gjqJ2a8q S0AhI1vacenBqKWmhz8tFOgO2tvGxNqP6gCVDOHoMSlewwTCBG1PcerY4AmVuAFu OjmD3VlNurKz30cfC/ovxhSLGOSufSharMUWP8UfCPCt6ZjTtyxSFtM6EWvCZUS3 feF6rPxY3Lriy8MZZusmtXUX6M/SJ0nXxYT6PoNGoq+IniA0wAstMC4CZNeHDerO XQwEcQNLLfjD3YdgM0Jd2GnYoWRVV1xrksuU6z9yDerZM9LbTOyWNYFvfYS3ieDP ASmtyrLtQq1te8l47ntxXtLr5OVv4gShWI5rLqMBxMG8xqTiEAQf+moiiKxjypqI Sf3PQcHLxJBRQmMB74IlMilsc0PSkqCb3L3UUAoaemD0CApsK3dFcrok00b6X3AN FdzaP6ZSa1s4maD7n+QVC+V76dQ4B9jbHVSYPJepaN9MJjy9wzGVy+HrVnHxkenr FmRnibRFp10svsD5I0Fo =Li25 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-22186-1398613326-0001-2-- From nobody Sun Apr 27 09:05: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 306F81A067E for ; Sun, 27 Apr 2014 09:05: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 7j4qP7KZb_aA for ; Sun, 27 Apr 2014 09:05:07 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7E1A067C for ; Sun, 27 Apr 2014 09:05:07 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id t59so1744389yho.36 for ; Sun, 27 Apr 2014 09:05: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=9E2DLR/gmOgkStBuli2dKcJbTO+w9w6E2dgy28VlppU=; b=ItT2AQo7pm6SAkRa1+kQNzSLwl4LUDvsTiNr8m5S/dgGdD9XM+qK0DiakCGfKEKQBU iJaF1GWmousMlTMpWRrtJHy611rNhT4iy5+/8wMG94LwovsWAwPWm9JKGeyQN5j0mUTY lmhvBFv80Twrv+i45vDMOMjZt4r1REr93DCnAqcSW4rnerY5yJ8DRRhmaJUxPLVgIn4t d3ucFqtP5QfEvuT9AspK/EHtmUQOgqYtxbwB8Mqxq/0gaGz71hOEU0I31dDmqqAxpe3W 5hurykj7ojeWOttbSm/nwLfyiFdlFF7x73RmWE677jJSyOsf5CX1d40qHWgQUXEoqSj0 YnnA== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr30038668yhi.4.1398614707261; Sun, 27 Apr 2014 09:05:07 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 27 Apr 2014 09:05:07 -0700 (PDT) In-Reply-To: <535C4EFD.7030608@pobox.com> References: <535C4EFD.7030608@pobox.com> Date: Sun, 27 Apr 2014 09:05:07 -0700 Message-ID: From: Watson Ladd To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M8gf-BVYUrEaXyq-W8gZUxYl-5w Cc: TLS Mailing List Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 16:05:10 -0000 On Sat, Apr 26, 2014 at 5:27 PM, Michael D'Errico wrote: > Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec. > due to the random padding? There is a requirement to add at least 16 > bytes of random padding to every message: > > struct { > HeartbeatMessageType type; > uint16 payload_length; > opaque payload[HeartbeatMessage.payload_length]; > opaque padding[padding_length]; > } HeartbeatMessage; > > ... > > padding: The padding is random content that MUST be ignored by the > receiver. The length of a HeartbeatMessage is TLSPlaintext.length > for TLS and DTLSPlaintext.length for DTLS. Furthermore, the > length of the type field is 1 byte, and the length of the > payload_length is 2. Therefore, the padding_length is > TLSPlaintext.length - payload_length - 3 for TLS and > DTLSPlaintext.length - payload_length - 3 for DTLS. The > padding_length MUST be at least 16. > > The sender of a HeartbeatMessage MUST use a random padding of at > least 16 bytes. The padding of a received HeartbeatMessage message > MUST be ignored. > > > Since the recipient MUST ignore the padding, they can't reverse engineer > the peer's PRNG, so maybe this isn't a problem? Two points: Your PRNG shouldn't allow state recovery given a sample, and if telling people to ignore things that they shouldn't look at worked, we wouldn't need TLS. That said we need to do some serious removal of unused options. Sincerely, Watson Ladd > > Mike > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Apr 27 09:05: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 9D07C1A07A2 for ; Sun, 27 Apr 2014 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SiiKicdk8lVB for ; Sun, 27 Apr 2014 09:05:42 -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 5BC041A07A0 for ; Sun, 27 Apr 2014 09:05:42 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so5360012wgh.17 for ; Sun, 27 Apr 2014 09:05: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=0JvbZb4RzEyFFad5Ox3Efh5KWeuUVeLhkkQh1on1ut0=; b=hhX0m4ufcYTl25FrYxjbT2fVajtQeuOq046pm8R7PZ6FK5q7Np0LURj8+UozQ3V9zf u+cPx2gfilOM93nkJ9tq56OIkuosctcZepC4ygQq8OUaEQ3pAecPLujiEDkLZjbMNYgV odpCCCLU2I6neSbrb5TxDyzE6mtGLR5SVIbZSU0+uCRAnTFkhWr7+ZXswpRcDjCmlLgz 6d70SSO/jBMaECihPVohUSOaKF5JHCJqUHbWw8EUcEFKOxSjtefV/JnnjXJklE/+K083 R2u4nAGbRCyt0nJ5MeE0PRAjmG9wyy8ZF//Es6zNAPijLsPPtuYzJwEapPPiWcAfOr3e QYmg== X-Gm-Message-State: ALoCoQmeE9JldayZQABeF8TXwanSUHzkd/oAm0zOKjoJILEbZe4JTnT1G/cpg036WLo5QdR2om9C X-Received: by 10.180.91.161 with SMTP id cf1mr11679227wib.49.1398614741582; Sun, 27 Apr 2014 09:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Sun, 27 Apr 2014 09:05:00 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 27 Apr 2014 09:05:00 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=f46d043bdf66d9a10a04f8085e3b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sRLsH0JenVmXAi5wMTV1IDCE6GM 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: Sun, 27 Apr 2014 16:05:45 -0000 --f46d043bdf66d9a10a04f8085e3b Content-Type: text/plain; charset=ISO-8859-1 The pull request is at: https://github.com/tlswg/tls13-spec/pull/29 Please reply on-list by end of Tuesday 4/29 if you see significant errors with this change. (Editorial issues can just be submitted as pull requests to the relevant branch). Note: if you find an issue after I've merged the change, you can just submit an issue as usual. That's what revision control is for... -Ekr On Sat, Apr 26, 2014 at 8:35 AM, Eric Rescorla wrote: > Acknowledged. > > I will prepare these changes (and those for the other two issues) as git > pull > requests and notify the list so that people can confirm that the changes > accurately capture the consensus of the WG. > > -Ekr > > > > On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) < > jsalowey@cisco.com> wrote: > >> We have strong confirmation of consensus to remove compression from TLS >> 1.3. The Editor is requested to make the appropriate changes to the draft >> on github. >> >> Joe >> [For the chairs] >> On Mar 26, 2014, at 11:42 AM, Joe Salowey 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 >> > > --f46d043bdf66d9a10a04f8085e3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The pull request is at:


Please reply on-list by end of Tuesday 4/2= 9 if you see significant
errors with this change. (Editorial issues can just be submitted
=
as pull requests to the relevant branch).

Not= e: if you find an issue after I've merged the change, you can
just submit an issue as usual. That's what revision control is for= ...

-Ekr



On Sat, Apr 26, 2014 a= t 8:35 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Acknowledged.

I will prepare these changes (and those for the other two issues) as = git pull
requests and notify the list so that people can confirm that the chang= es
accurately capture the consensus of the WG.

-Ekr



On Sat, Apr 26, 2014 at 8:24 AM, Joseph Salowey (jsalowey) <jsal= owey@cisco.com> wrote:
We have strong confirmation of consensus to = remove compression from TLS 1.3. =A0 The Editor is requested to make the ap= propriate changes to the draft on github.

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

> The use of compression within TLS has resulted in vulnerabilities that= can be exploited to disclose TLS encrypted application data. =A0 The conse= nsus in the room at IETF-89 was to remove compression from TLS 1.3 to remov= e this attack vector. =A0If you have concerns about this decision please re= spond on the TLS list by April 11, 2014.
>
> Thanks,
>
> Joe
> [Speaking for the TLS chairs]

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


--f46d043bdf66d9a10a04f8085e3b-- From nobody Sun Apr 27 09: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 AA31E1A0691 for ; Sun, 27 Apr 2014 09:06: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 b0eMY7MBjL2h for ; Sun, 27 Apr 2014 09:06:08 -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 42BA11A0797 for ; Sun, 27 Apr 2014 09:06:08 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so606210yha.38 for ; Sun, 27 Apr 2014 09:06: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=btbYmMf1SU7IBB3Gk9FmJbNeaFxV5qDxO2fDXx4phrA=; b=plIYOsA8k6tzTdiuaWzdDTG2ntuqGqzPWKCIK04GsvDJArRFfsIeOGMxIcMTOJEjnx NcIAFyMdfmTW/qDZxKh/2KN2bDIhX8XKBo3PLJLlPFv69GEj9xISdDri+ty8+alJiBDN GS/A282eQrP4QR0JzbxLpKr6v101UdrtkcebkjBwPz1hwhz807OeulqWKAiLI6BsRkQo 1RJYSuC4P4KS/xWthPyn+EAmNjPeRmH0rc3zB2TS6aQde83RVTeTTtgZ/p++jET99MCV 8JwkDCJtv55rLBQ/aMUT4fLFYnKEnuo2s5neQ8Y7XgKn1WGGD9nFOJxn7ezPFIrW7nHc vQtg== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr30045063yhi.4.1398614767878; Sun, 27 Apr 2014 09:06:07 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 27 Apr 2014 09:06:07 -0700 (PDT) In-Reply-To: <535B6235.9090907@pobox.com> References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> <535B6235.9090907@pobox.com> Date: Sun, 27 Apr 2014 09:06:07 -0700 Message-ID: From: Watson Ladd To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4PVfhw1YoVtDQxYiHB-NtInvyZY Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 16:06:10 -0000 On Sat, Apr 26, 2014 at 12:37 AM, Michael D'Errico wrote: > Watson Ladd wrote: >> >> On Fri, Apr 25, 2014 at 11:20 AM, Gero, Charlie wrote: >>> >>> SNI and ALPN can be used to alter the path the rest of the handshake >>> takes (and for many hosts, will be the case). >> >> >> For SNI this is true. But ALPN? Remember it was introduced to handle >> HTTP 2.0 vs HTTP 1.0: I don't see people rushing out to use different >> certs per protocol. > > > It's a bit premature to inter ALPN when it hasn't yet been published as > an RFC. Why don't you like it? "Like it"? The question is whether or not the flexibility gained from letting the server pick its certificate in response to ALPN is worth the cost in protocol complexity. The usecases I've seen do not involve doing this. Remember I'm not proposing removing ALPN: I'm proposing changing the flow to work better with 1-RTT TLS and HTTP. Is there a cost in protocol complexity in supporting this usage? Yes. We haven't figured out a good way to encrypt SNI for much the same reason: how do you know what key to use to encrypt and decrypt data that will tell you which key to use. If we want 1-RTT to require foreknowledge of a key, this solves that problem partially, but at the cost of complicating the implementations that want to take advantage of 1-RTT. Sincerely, Watson Ladd From nobody Sun Apr 27 12:55: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 7E1601A063B for ; Sun, 27 Apr 2014 12:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZSS_1lS_8DM for ; Sun, 27 Apr 2014 12:55:30 -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 37B0A1A03B3 for ; Sun, 27 Apr 2014 12:55:29 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7014611357; Sun, 27 Apr 2014 15:55:28 -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=kFbhjTidlqz3 Oisb8fp+rfXy0EM=; b=fyq5lbzTnqhWwwrqC8M/4mhmfcRLypIivEyCn5PN70w9 ZVg2KPwPgL52wewISwf1LKo9zZkX1074OxOGEfOrlfvDYgEfVYXhgXKTzy0NJJQb ZefXSL8tNlNMO/v0zukVNLcg+gOcGJgtDK+Wcj4UYouWq//ylBk+uZEA4fns7SA= 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=aKP7Pj a5/KRk2/J4EEgDtnvs3mGoLmijCNmm9kgRZV7h7b5wyl6J4EJPDPPv6aVwvqDO3s i9u+r3w2kSY6YxIXLQHrEAngvoAMntBnjdWkHHhtYslacejsP2FCs5AQPsZZCpp+ v+U7/NWW9aO4TGnS8Hqj34oGmNd0qNt/ArO20= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 689CA11356; Sun, 27 Apr 2014 15:55:28 -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 9506711355; Sun, 27 Apr 2014 15:55:26 -0400 (EDT) Message-ID: <535D60AD.4040006@pobox.com> Date: Sun, 27 Apr 2014 12:55:25 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Watson Ladd References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> <535B6235.9090907@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: E0A10DCC-CE45-11E3-B0F0-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dsOh68tTwGe7jSCRUvbu_COFIAg Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 19:55:33 -0000 Watson Ladd wrote: > > I'm not proposing removing ALPN: I'm proposing > changing the flow to work better with 1-RTT TLS and HTTP. > > Is there a cost in protocol complexity in supporting this usage? Yes. > We haven't figured out a good way to encrypt SNI for much the same > reason: how do you know what key to use to encrypt and decrypt data > that will tell you which key to use. If we want 1-RTT to require > foreknowledge of a key, this solves that problem partially, but at the > cost of complicating the implementations that want to take advantage > of 1-RTT. ALPN doesn't add any more protocol complexity than SNI, so I don't see the problem. If you can figure out a way to encrypt SNI such that the server can use it to select a certificate, then you can also encrypt ALPN using the same method. Mike From nobody Sun Apr 27 13:20: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 0E1141A07A2 for ; Sun, 27 Apr 2014 13:20: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 QsZG3omlryCK for ; Sun, 27 Apr 2014 13:20:41 -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 4467F1A06AD for ; Sun, 27 Apr 2014 13:20:41 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so5386146yho.32 for ; Sun, 27 Apr 2014 13:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VEMJupQqzAtNp+QDrNXWZIybkjIvILLJwKod2hRmeUs=; b=k5IiaSufzfX42adIZgwefLvT/vCaQuXNxOk2xrLWpdBm+Qnamx54qlwqFr3S4oTcnU KDiLN7TYLcO21khrHsNMxNPeHaSkq56Kc0GYEc5czicoPyOwCl+mzI65tGIRjHiTRlFx uQn7vXgoE7bViUoicArrNOWJrrkt2357kaLgwkWz+CHiYc3ujyEtLbU41X8PT6spDcEM /8PVyju5qS8xb/JcZGsTOtCtiCuoQlDRx1ND539Sc8pdDCp0wkv3co5bJHkqkhw81cpo vZN0KkEfRAz6TOPS8vB4+U7+Ydmf2ljSpoEu9+sxT6gXSxbCcCU1+SFFo6UHemri7wH/ zYVw== MIME-Version: 1.0 X-Received: by 10.236.10.82 with SMTP id 58mr104163yhu.118.1398630040710; Sun, 27 Apr 2014 13:20:40 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Sun, 27 Apr 2014 13:20:40 -0700 (PDT) In-Reply-To: <535D60AD.4040006@pobox.com> References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> <535B6235.9090907@pobox.com> <535D60AD.4040006@pobox.com> Date: Sun, 27 Apr 2014 13:20:40 -0700 Message-ID: From: Watson Ladd To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Q0j7Pyc3PhU7_ZjU_fSwPfggYg Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Apr 2014 20:20:43 -0000 On Sun, Apr 27, 2014 at 12:55 PM, Michael D'Errico wrote: > Watson Ladd wrote: >> >> >> I'm not proposing removing ALPN: I'm proposing >> changing the flow to work better with 1-RTT TLS and HTTP. >> >> Is there a cost in protocol complexity in supporting this usage? Yes. >> We haven't figured out a good way to encrypt SNI for much the same >> reason: how do you know what key to use to encrypt and decrypt data >> that will tell you which key to use. If we want 1-RTT to require >> foreknowledge of a key, this solves that problem partially, but at the >> cost of complicating the implementations that want to take advantage >> of 1-RTT. > > > ALPN doesn't add any more protocol complexity than SNI, so I don't see > the problem. If you can figure out a way to encrypt SNI such that the > server can use it to select a certificate, then you can also encrypt > ALPN using the same method. True: we can encrypt the handshake. But that's turned out to be harder than expected. What if it turns out we can't encrypt SNI? We have one proposal, relying on encrypting the handshake using a key sent over DNS. It's a good idea, and should work. I'd like it to work. But it might not work. I think it's worth identifying alternative designs and thinking about them before Denver, so that if it turns out we can't encrypt SNI, we can encrypt other extensions in need of encryption. Sincerely, Watson Ladd From nobody Mon Apr 28 00:23: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 E9D011A015E for ; Mon, 28 Apr 2014 00:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuymlBce4yC1 for ; Mon, 28 Apr 2014 00:23:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1041A014C for ; Mon, 28 Apr 2014 00:23:21 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3S7NJE0021531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 03:23:19 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s3S7NH4P007657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 03:23:18 -0400 Message-ID: <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Mon, 28 Apr 2014 09:23:17 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.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.12 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Kego9gQoTApz0BXFeCQr8J6HEk Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 07:23:23 -0000 On Fri, 2014-04-25 at 09:27 -0400, Salz, Rich wrote: > What’s the current state of the Cha-Cha/Poly document? Do things need > changing, identifiers assigned, or what? We have submitted our proposal [0] based on the new chacha construction. It is up to the chairs to ask for WG adoption. [0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 regards, Nikos From nobody Mon Apr 28 02: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 8CF9A1A0983 for ; Mon, 28 Apr 2014 02:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUbaJ7n3k_zi for ; Mon, 28 Apr 2014 02:01:38 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 788651A097C for ; Mon, 28 Apr 2014 02:01:38 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so6116428wes.29 for ; Mon, 28 Apr 2014 02:01:37 -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=ZvJRr+WMIqY2Z1fcfkkoNYa6hazb4zwvv52jx9ozeOE=; b=PpvcKh/TYGKukUGl264Gi77Dy34BjdgD4PGmzMzyWqKWgfGq8UMPBrua5TDPpYxz9S 0T5CPhweFCkTiZOQ07nSpNRRDMFq8giVX13rIR07+Bc7qHc/iNQLg2meZ0ihYJ5T2Fu/ MeUONfTL0Z/TZaiHmJJQmsOOF/O57aqMRuhCmXLJ+Ir99StN2FeQYeqkrbpm6+6Me7PI S5e846EbhSqr/IVM7RVLDurS43VHj+SqtoPBcb26aSwAl+q8lJdqdzOa8rY47fgGqAb7 Jn2CxS1Pc48FqBBwAFeBwdMAT4OwgKtpRDVIFOLip4sBS9rc9YvxgmxZhjhp4n0x7AtV VpPg== X-Received: by 10.194.189.116 with SMTP id gh20mr18132599wjc.41.1398675697416; Mon, 28 Apr 2014 02:01:37 -0700 (PDT) Received: from [172.24.248.99] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id v6sm25061744wjv.21.2014.04.28.02.01.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 02:01:36 -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: <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Apr 2014 12:01:32 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/93aSFFK86VhSJkjcinWfjLCz89Q Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 09:01:40 -0000 On Apr 28, 2014, at 10:23 AM, Nikos Mavrogiannopoulos = wrote: > On Fri, 2014-04-25 at 09:27 -0400, Salz, Rich wrote: >> What=92s the current state of the Cha-Cha/Poly document? Do things = need >> changing, identifiers assigned, or what? >=20 > We have submitted our proposal [0] based on the new chacha = construction. > It is up to the chairs to ask for WG adoption. >=20 > [0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 The chacha in TLS draft depends on draft-nir-cfrg-chacha20-poly1305. That still has to go through three =93stages=94: 1. I need to add a bunch of test vectors and an explanation of = decryption. Shouldn=92t be too difficult with a counter/streamish cipher = such as ChaCha 2. We need to get a review of it. The changes to ChaCha are minor and = do not affect security (IMO), but that=92s just me. If we can get DJB to = review it and say it=92s OK - so much the better 3. We need to find how to get this published. I submitted it as a CFRG = document, but I=92m not sure that=92s the best way to get it published. Yoav From nobody Mon Apr 28 04:02: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 229131A09BF for ; Mon, 28 Apr 2014 04:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 DS3w5LtUc4Dv for ; Mon, 28 Apr 2014 04:02:31 -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 77B881A09A9 for ; Mon, 28 Apr 2014 04:02:20 -0700 (PDT) Received: (qmail 26792 invoked by uid 1000); 28 Apr 2014 11:02:18 -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, 28 Apr 2014 12:02:18 +0100 Message-ID: <535E353A.9030008@comodo.com> Date: Mon, 28 Apr 2014 12:02:18 +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: Tom Ritter , Klemens Baum 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/-6Fgb949dicegQUza1_NBNjW2Ws Cc: "tls@ietf.org" , Phillip Hallam-Baker Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 11:02:35 -0000 On 27/04/14 13:07, Tom Ritter wrote: > There isn't much gain in requiring it on a per-certificate basis, but > on a host basis it makes a lot more sense. (Not that putting it on a > cert is bad, just insufficient.) There were a couple ideas for making > this a header here: > http://www.ietf.org/mail-archive/web/tls/current/msg10351.html I too > would like Must Staple to come back. AIUI, PHB intends to progress the tls-feature draft just as soon as IANA allocates an OID for the new certificate extension. It's not dead, just resting. An OID allocation request was submitted well over a year ago. The reason for the delay is that following the shutdown of the PKIX WG, control of the PKIX OID registry is being transferred to IANA. IINM, the transfer is still not yet complete. > -tom > > On 24 April 2014 15:55, Klemens Baum wrote: >> After the whole Heartbleed incident, it has become obvious that the >> current mechanisms for Certificate Revocation are inadequately >> enforced by clients. >> >> To combat the issue, it would seem desirable for a security-conscious >> server operator to be able to require the use of OCSP stapling on a >> per-certificate basis. There was already an Internet-Draft (now >> expired) for an X.509v3 extension which would provide this feature: >> https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ >> >> Clients supporting the extension could display an enhanced security >> indicator (e.g. "Certificate Status: Not revoked") for certificates >> carrying the extension which pass validation, which would also >> motivate more widespread adoption of OCSP stapling in favor of CRLs >> and client-initiated OCSP requests. >> >> Since the draft looked very promising, I suggest that it should be >> unexpired. If anyone with the authority to do so agrees, please submit >> a request for resurrection per the guidelines at >> http://www.ietf.org/ietf-ftp/1id-guidelines.txt. >> >> A few minor clarifications may still be needed so that it can be >> quickly implemented by major browsers and the CAs: >> >> - The tls-feature OID is currently specified with a value of { id-pe 1 >> }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself >> already an X.509v3 extension). Surely a new OID in the >> pkix.privateExtension arc will need to be allocated by IANA and if >> this is the case, it should be noted in the section "IANA >> Considerations". >> >> Please share your opinions! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Apr 28 05:45: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 06E721A09F9 for ; Mon, 28 Apr 2014 05:45:53 -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 uhzPwAC0PP9x for ; Mon, 28 Apr 2014 05:45:52 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9F1A09F6 for ; Mon, 28 Apr 2014 05:45:51 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id c13so4784410eek.37 for ; Mon, 28 Apr 2014 05:45: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Zxtxro9URFNT/mmL3pnXAYLNFfmoFvV79dcMy4HCKqM=; b=KcCgzuSkZjmszmQKZiGtlWhr7g2qb5LXGGASOrXHFPiKAhCTDrQIGOryA1dWtmYBhC ymDPpPvREaiGeZdrDy6uZIPP5OhRqAj7cD/+O3A/oinyw8pve92p91TKycIghP5svPa6 UyPVDhsz0tSAaVOswkc1+lZRW4Rxd35yz5brljbTrW3098c2Uak2UotIZzQsXudA/CY8 LOwX6Ecu9FTPyA8mU96/wCHsrkhyUx+PMRJNSkjKyQArqPmef26TSsb5wg0ur+IZAUSY 8S5GR7xdhAm73ZCeDMvMh9JE4lSlmw+WrGv2VsK1ECVFJsrWMJ+Y9tyTJnxs55oAB7MM jIdQ== X-Gm-Message-State: ALoCoQkq6BqyUygPI46WvTrq3lcHvaDNwXT+c5bNtOHqOmW1nAoTqROOXOPIXqtyZdvxjTjrT3xc X-Received: by 10.14.199.8 with SMTP id w8mr1056312een.94.1398689150376; Mon, 28 Apr 2014 05:45:50 -0700 (PDT) Received: from [10.60.30.119] ([193.170.94.190]) by mx.google.com with ESMTPSA id bc51sm50119223eeb.22.2014.04.28.05.45.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 05:45:49 -0700 (PDT) Message-ID: <535E4D78.1030307@azet.org> Date: Mon, 28 Apr 2014 14:45:44 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Michael D'Errico References: <535C4EFD.7030608@pobox.com> In-Reply-To: <535C4EFD.7030608@pobox.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig38D5519DE3E00DF0B778299E" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QXrcmrfid99ypf56hkvD3njbYRQ Cc: TLS Mailing List Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 12:45:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38D5519DE3E00DF0B778299E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael D'Errico wrote: > Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec= =2E > due to the random padding? There is a requirement to add at least 16 > bytes of random padding to every message: >=20 > struct { > HeartbeatMessageType type; > uint16 payload_length; > opaque payload[HeartbeatMessage.payload_length]; > opaque padding[padding_length]; > } HeartbeatMessage; >=20 > ... >=20 > padding: The padding is random content that MUST be ignored by the > receiver. The length of a HeartbeatMessage is TLSPlaintext.lengt= h > for TLS and DTLSPlaintext.length for DTLS. Furthermore, the > length of the type field is 1 byte, and the length of the > payload_length is 2. Therefore, the padding_length is > TLSPlaintext.length - payload_length - 3 for TLS and > DTLSPlaintext.length - payload_length - 3 for DTLS. The > padding_length MUST be at least 16. >=20 > The sender of a HeartbeatMessage MUST use a random padding of at > least 16 bytes. The padding of a received HeartbeatMessage message > MUST be ignored. >=20 >=20 > Since the recipient MUST ignore the padding, they can't reverse enginee= r > the peer's PRNG, so maybe this isn't a problem? You should ignore it, but you can still recieve it, right? I was wondering about exactly the same issue a few weeks ago. As far as I know (and some people familiar with implementations have suggested) you do not need to pad with CSPRNG here and implementations allegedly do not do so, I didn't have time to check in codebases of SSL libs though. Aaron --------------enig38D5519DE3E00DF0B778299E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTXk15AAoJEOTbZJL9ubXVRysQAMSs34Kz3RNMYs1WrUPVyZb0 0r+H2+tkBlereVmFDOxyVEyblCb+ejhjpHL1XUHGpsxrWUrUyEXaA8eTNeAAhOkm OPlQKHUcLUTQlVwrfvG3tAUjzV/CuJg9aFZxerisJ6z1zeMVbrHRKfqkQ3niw/QQ 2B3M57ftNDs015PBR//PR/2IeO82+UGhSdckB/Hl3Ey/6dH+C+jzWrs7E37nFdSk JduZcIG54nDdXd3h0xYNnTKKsJMpUHBBouDN1lwcfFnJy+1tAGbc4l1w6c9o8pvm +a0T0HWqB8vO5nO63gnVaxfNx+uij7dzSKNSk4slZVmE9728viVNl1Yt4Se0hS7I ziEgwqN9xGlwSt7Oe0jwf0WqWqJY8r5GbN8CV0VTgZtm3s+HL37q9I7MBjP09X1l 1IPlAeKXJdhVk+P879ft97HNn0fLYz/dLTIsHCgoHej/oWNBS3GZssbTheqJVRxD aioNApXgonw5NyqNmbI1uPHjSYMrap/OF4/BCie5Gu2xd9OK80nrcvgAplozX4QH GhLKsOapoNt6tgSLwlY6C2h1Cu+NZNkeftBQ84WxsWImVUFCWCPj9+tx42V8TlH6 QxRS9sjBzEa/rRLtYXL6rk5VKDxhNEmufP29hpfrf6aSiwzUqJVjH27bJtsQ5jmI c8LrtUL0iDx+pY0xmL37 =tJ0q -----END PGP SIGNATURE----- --------------enig38D5519DE3E00DF0B778299E-- From nobody Mon Apr 28 06:35: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 2A4AF1A015E for ; Mon, 28 Apr 2014 06:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF97-boWg2TD for ; Mon, 28 Apr 2014 06:35:03 -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 7B04F1A0795 for ; Mon, 28 Apr 2014 06:35:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A1BAC4736B; Mon, 28 Apr 2014 13:35:02 +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 95E9F47329; Mon, 28 Apr 2014 13:35:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 88B7FFE055; Mon, 28 Apr 2014 13:35:02 +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; Mon, 28 Apr 2014 09:35:02 -0400 From: "Salz, Rich" To: Watson Ladd , Michael D'Errico Date: Mon, 28 Apr 2014 09:35:01 -0400 Thread-Topic: [TLS] Encrypting ALPN and other unused extensions Thread-Index: Ac9iVi26ozfI9a3LRkeOJKlZsbFfaAAkHIhw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F52C@USMBX1.msg.corp.akamai.com> References: <535A8CED.7030805@pobox.com> <20140425173608.E1A2E1ACE0@ld9781.wdf.sap.corp> <535B6235.9090907@pobox.com> <535D60AD.4040006@pobox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jFt6AKQ5b5JrfvmMbKCqHvVU6W4 Cc: "tls@ietf.org" Subject: Re: [TLS] Encrypting ALPN and other unused extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 13:35:09 -0000 > work. I'd like it to work. But it might not work. I think it's worth iden= tifying alternative designs and thinking about them before Denver, so that = if it turns out we can't encrypt SNI, we can encrypt other extensions in ne= ed of encryption. +1 -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 06:39: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 4432F1A09F8 for ; Mon, 28 Apr 2014 06:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cOimicFnt46 for ; Mon, 28 Apr 2014 06:39:33 -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 268941A0795 for ; Mon, 28 Apr 2014 06:39:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EB32547440; Mon, 28 Apr 2014 13:39:31 +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 7F69047435; Mon, 28 Apr 2014 13:39:31 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 762C0FE054; Mon, 28 Apr 2014 13:39:31 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 28 Apr 2014 09:39:30 -0400 From: "Salz, Rich" To: Rob Stradling Date: Mon, 28 Apr 2014 09:39:29 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9i0WFBmeki9MVCTRqa19Fo2VN1+gAFaqfQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F536@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> In-Reply-To: <535E353A.9030008@comodo.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/r5quPjR3PiMdGBzm87PXocuUV24 Cc: "tls@ietf.org" , Phillip Hallam-Baker Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 13:39:34 -0000 > An OID allocation request was submitted well over a year ago. The reason= for the delay is that following the shutdown of the PKIX WG, control of th= e PKIX OID registry is being transferred to IANA. IINM, the transfer is st= ill not yet complete. You know, the really cool thing about OID's is that just about anyone can g= et an arc and that they are really just distributed opaque identifiers. (Ki= nda like XML namespace UIR's I suppose.) I'm sure there are many folks who= would volunteer if needed. -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 06:44: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 8B4E51A0795 for ; Mon, 28 Apr 2014 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O89hwNIRMI8k for ; Mon, 28 Apr 2014 06:44:23 -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 9496B1A0A16 for ; Mon, 28 Apr 2014 06:44:23 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AB23C28617; Mon, 28 Apr 2014 13:44:22 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 94146285FF; Mon, 28 Apr 2014 13:44:22 +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 923F680044; Mon, 28 Apr 2014 13:44:22 +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; Mon, 28 Apr 2014 09:44:18 -0400 From: "Salz, Rich" To: Michael D'Errico , TLS Mailing List Date: Mon, 28 Apr 2014 09:44:18 -0400 Thread-Topic: [TLS] Heartbeat and padding Thread-Index: Ac9hr4cjTiQsMhElRiyEYq+javEpogBN+wmw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> References: <535C4EFD.7030608@pobox.com> In-Reply-To: <535C4EFD.7030608@pobox.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/lX6n-62li0P5GxZ-rVwSYEXi-qo Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 13:44:24 -0000 > Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec. The original use-case was for DTLS, wasn't it? We only have a single regis= try for extensions, and that's reasonable since the vast majority of them a= re applicable to both TLS (TTLS? :) and DTLS. I think it makes sense to add another column to the extension registry, cal= led "applicability" or something like that with values from the set (both, = tls-only, dtls-only) and the default is both. It's not just out of vengeance, honest! But I think TLS heartbeat should be= at least be deprecated in 1.3. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 07:06: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 88F881A0A23 for ; Mon, 28 Apr 2014 07:06:16 -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 gbP7A6fJONZ1 for ; Mon, 28 Apr 2014 07:06:14 -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 A0EDE1A0A20 for ; Mon, 28 Apr 2014 07:06:12 -0700 (PDT) Received: (qmail 30381 invoked by uid 1000); 28 Apr 2014 14:06:10 -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, 28 Apr 2014 15:06:10 +0100 Message-ID: <535E6052.90605@comodo.com> Date: Mon, 28 Apr 2014 15:06:10 +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: "Salz, Rich" References: <535E353A.9030008@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F536@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F536@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/vpK0FdDgtokx6alpjg-Vk_Qhbas Cc: "tls@ietf.org" , Phillip Hallam-Baker Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 14:06:16 -0000 On 28/04/14 14:39, Salz, Rich wrote: >> An OID allocation request was submitted well over a year ago. The reason for the delay is that following the shutdown of the PKIX WG, control of the PKIX OID registry is being transferred to IANA. IINM, the transfer is still not yet complete. > > You know, the really cool thing about OID's is that just about anyone can get an arc and that they are really just distributed opaque identifiers. (Kinda like XML namespace UIR's I suppose.) I'm sure there are many folks who would volunteer if needed. I'm well aware of that. See https://cabforum.org/pipermail/public/2013-November/002333.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Apr 28 07:14: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 CA8881A0A24 for ; Mon, 28 Apr 2014 07:14:33 -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 y5e_nVvS9b4E for ; Mon, 28 Apr 2014 07:14:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 86C271A1F20 for ; Mon, 28 Apr 2014 07:14:31 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id A9B56F3C026; Mon, 28 Apr 2014 10:14:20 -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 kykLDhEu7go6; Mon, 28 Apr 2014 10:14:00 -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 E47C4F3C032; Mon, 28 Apr 2014 10:13:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <535E353A.9030008@comodo.com> Date: Mon, 28 Apr 2014 10:13:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48E70918-765E-4EAE-8FE0-DCC038C61314@vigilsec.com> References: <535E353A.9030008@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ugXRO99GJvSI5mpYvjDfn-cOmTk Cc: Klemens Baum , "tls@ietf.org" , Phillip Hallam-Baker Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 14:14:34 -0000 Rob: > An OID allocation request was submitted well over a year ago. The = reason for the delay is that following the shutdown of the PKIX WG, = control of the PKIX OID registry is being transferred to IANA. IINM, = the transfer is still not yet complete. The IESG has assigned me as the expert for this IANA registry. If the = document is ready for approval, we can work the review in parallel. Russ From nobody Mon Apr 28 07:20: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 05A621A047E for ; Mon, 28 Apr 2014 07:20:37 -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 rbdVmOvWrWIq for ; Mon, 28 Apr 2014 07:20:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C69011A07A0 for ; Mon, 28 Apr 2014 07:20:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AD5C62AB0DD; Mon, 28 Apr 2014 14:20:29 +0000 (UTC) Date: Mon, 28 Apr 2014 14:20:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428142029.GT27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <535E353A.9030008@comodo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4d3GODw8Nl0Snu1qqzYnEWPH-3Q Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:20:37 -0000 On Mon, Apr 28, 2014 at 12:02:18PM +0100, Rob Stradling wrote: > AIUI, PHB intends to progress the tls-feature draft just as soon as IANA > allocates an OID for the new certificate extension. It's not dead, just > resting. OCSP stapling gives no indication of when a verifier is to consider a particular status response to be stale. Without any indication of how often a server is supposed to provide a (more) fresh response, it is not clear that OSCP stapling enforcement can be implemented scalably in an interoperable manner, with servers obtaining and stapling new OCSP responses before clients decide that the extant response is too old. -- Viktor. From nobody Mon Apr 28 07:26: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 E21E01A0A20 for ; Mon, 28 Apr 2014 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER4swX72zuaS for ; Mon, 28 Apr 2014 07:26:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E380C1A047E for ; Mon, 28 Apr 2014 07:26:13 -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 s3SEQCLX010857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Apr 2014 10:26:12 -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 s3SEQ9Ii004272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Apr 2014 10:26:10 -0400 Message-ID: <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Mon, 28 Apr 2014 16:26:09 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> References: <535C4EFD.7030608@pobox.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@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/4ctLOzqM2RTn0d0szOEpG6qaJuk Cc: TLS Mailing List Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 14:26:19 -0000 On Mon, 2014-04-28 at 09:44 -0400, Salz, Rich wrote: > > Not related to Heartbleed(tm), do we need to revisit the Heartbeat spec. > > The original use-case was for DTLS, wasn't it? We only have a single registry for extensions, and that's reasonable since the vast majority of them are applicable to both TLS (TTLS? :) and DTLS. > > I think it makes sense to add another column to the extension registry, called "applicability" or something like that with values from the set (both, tls-only, dtls-only) and the default is both. > > It's not just out of vengeance, honest! But I think TLS heartbeat should be at least be deprecated in 1.3. Isn't it sufficient to be disabled by default by implementations? Given its pretty sophisticated use cases for TLS I don't see why it should be enabled by default. While I had argued against the heartbeat in TLS at the time it was proposed, we now have it and deprecating it would actually punish any existing uses of it. regards, Nikos From nobody Mon Apr 28 07:32: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 481281A0A20 for ; Mon, 28 Apr 2014 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WLuLS6ZDVGG for ; Mon, 28 Apr 2014 07:32: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 36F421A0983 for ; Mon, 28 Apr 2014 07:32:13 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 158D32860C for ; Mon, 28 Apr 2014 14:32:12 +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 F02012857C for ; Mon, 28 Apr 2014 14:32:11 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id E87BFFE054 for ; Mon, 28 Apr 2014 14:32:11 +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; Mon, 28 Apr 2014 10:32:11 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Mon, 28 Apr 2014 10:32:10 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9i7Q4/YcLXoRk9RHGTvanbnwLzWgAAOiUQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> In-Reply-To: <20140428142029.GT27883@mournblade.imrryr.org> 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/_hEVpd83LrROpU0a8cbYX0Zs8Y4 Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 14:32:14 -0000 > OCSP stapling gives no indication of when a verifier is to consider a par= ticular status response to be stale. Not sure what you mean; thisUpdate, nextUpdate, producedAt aren't sufficien= t? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 07:41: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 D0F5B1A063C for ; Mon, 28 Apr 2014 07:41:02 -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 oFK0Xmgd1-jw for ; Mon, 28 Apr 2014 07:41:01 -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 4FB1A1A0564 for ; Mon, 28 Apr 2014 07:41:01 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 9so1797109ykp.10 for ; Mon, 28 Apr 2014 07:41: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 :content-type; bh=nb/VI6hxU0w5Hfgta49XS/NKbCaWS6q02DaaKpMa7Go=; b=n+kstE7SuiPqoPy5vi72/506uwxnO1eldvDBJL8NtcshZUdB4RbBQv2L0wWdubQadQ KxDFYf1U9P9tOOwGl4t2X49z2iqmaIMfnCMC35IWzjPLOXO6t35d76pB41a07U63cSS9 8+44+Q+UrZMf0dZMwPpp0D5lTbVHUMCisU3FPEeKq4nmsgErsGgYXJVSzBaZNyYA5w9S Xz7yrTuuf3ZQOXohSv2tPIXNCjM2PwBpqS2c2p338ieHn29mSzCgUdJ8NaGP7Sr5QgtU rLpF0IIv5Y9gaba48lGWeqGG4apUdbjJLO/f6hspTKPlq7/ri93qP4eVdLMDkYEpasBO OIQw== MIME-Version: 1.0 X-Received: by 10.236.179.162 with SMTP id h22mr3297955yhm.107.1398696060175; Mon, 28 Apr 2014 07:41:00 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 28 Apr 2014 07:41:00 -0700 (PDT) In-Reply-To: <20140428142029.GT27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> Date: Mon, 28 Apr 2014 07:41:00 -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/7PebFo4u4WLcSnIlmU3sYNHHUjs Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 14:41:02 -0000 On Mon, Apr 28, 2014 at 7:20 AM, Viktor Dukhovni wrote: > On Mon, Apr 28, 2014 at 12:02:18PM +0100, Rob Stradling wrote: > >> AIUI, PHB intends to progress the tls-feature draft just as soon as IANA >> allocates an OID for the new certificate extension. It's not dead, just >> resting. > > OCSP stapling gives no indication of when a verifier is to consider > a particular status response to be stale. Without any indication > of how often a server is supposed to provide a (more) fresh response, > it is not clear that OSCP stapling enforcement can be implemented > scalably in an interoperable manner, with servers obtaining and > stapling new OCSP responses before clients decide that the extant > response is too old. That can be easily fixed by adding a field to the OCSP response, or more easily by adding the duration of the response to the relevant OCSP stapling document. I think 24-48 hours ought to be the right range, but I don't have any strong feeling for why. People with more clue should weigh in. Sincerely, Watson Ladd > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Apr 28 07:42: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 E99D11A0792 for ; Mon, 28 Apr 2014 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, 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 sD7hyDOIzxcy for ; Mon, 28 Apr 2014 07:42:32 -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 1B9111A0564 for ; Mon, 28 Apr 2014 07:42:31 -0700 (PDT) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 01B991C104668; Mon, 28 Apr 2014 16:42:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Tuexen In-Reply-To: <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Apr 2014 16:42:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535C4EFD.7030608@pobox.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> <1398695169.2453.34.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-miVRMDv6bOsHigRPH0AUnS6XQk Cc: TLS Mailing List Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 14:42:35 -0000 On 28 Apr 2014, at 16:26, Nikos Mavrogiannopoulos = wrote: > On Mon, 2014-04-28 at 09:44 -0400, Salz, Rich wrote: >>> Not related to Heartbleed(tm), do we need to revisit the Heartbeat = spec. >>=20 >> The original use-case was for DTLS, wasn't it? We only have a single = registry for extensions, and that's reasonable since the vast majority = of them are applicable to both TLS (TTLS? :) and DTLS. >>=20 >> I think it makes sense to add another column to the extension = registry, called "applicability" or something like that with values from = the set (both, tls-only, dtls-only) and the default is both. >>=20 >> It's not just out of vengeance, honest! But I think TLS heartbeat = should be at least be deprecated in 1.3. >=20 > Isn't it sufficient to be disabled by default by implementations? = Given > its pretty sophisticated use cases for TLS I don't see why it should = be > enabled by default. While I had argued against the heartbeat in TLS at > the time it was proposed, we now have it and deprecating it would > actually punish any existing uses of it. I agree. There is no need in having it enabled by default. So if the application doesn't want it, it just doesn't enable it. Best regards Michael >=20 > regards, > Nikos >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Mon Apr 28 07: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 725251A0842 for ; Mon, 28 Apr 2014 07:52: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1NHAh2G8EUK for ; Mon, 28 Apr 2014 07:52:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id DB2781A04C5 for ; Mon, 28 Apr 2014 07:52:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1BC02AB0DD; Mon, 28 Apr 2014 14:52:50 +0000 (UTC) Date: Mon, 28 Apr 2014 14:52:50 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428145250.GU27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dVE1LrJAUYCMW_llwiP1bxXN_mE Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:52:54 -0000 On Mon, Apr 28, 2014 at 10:32:10AM -0400, Salz, Rich wrote: > > OCSP stapling gives no indication of when a verifier is to > > consider a particular status response to be stale. > > Not sure what you mean; thisUpdate, nextUpdate, producedAt aren't sufficient? Well, "nextUpdate" is optional per RFC 6960, and even when present it is not clear that the frequency of server updates of stapled OCSP responses is expected to provide responses whose nextUpdate is always in the future. Yes, RFC 5019 suggests that nextUpdate is not optional, and that OCSP clients retry before nextUpdate, as further modified by "cache-control:max-age", but * What happens if the server can't reach the OCSP responder at that time? * How often should it retry? * What multiple of the "[thisUpdate, nextUpdate]" window should a client use as a grace-period? * Do OCSP responders at CAs generally implement RFC 5019? * What is the operational experience with fail-closed OCSP? (AFAIK most implementations fail open when no OCSP response can be obtained). -- Viktor. From nobody Mon Apr 28 07:57: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 3B9791A0A22 for ; Mon, 28 Apr 2014 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBGSbdnw_TL8 for ; Mon, 28 Apr 2014 07:57:53 -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 417001A04C5 for ; Mon, 28 Apr 2014 07:57:53 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4014E1655AA for ; Mon, 28 Apr 2014 14:57:52 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 353391655A5 for ; Mon, 28 Apr 2014 14:57:52 +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 19DFE47BD5 for ; Mon, 28 Apr 2014 14:57:52 +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; Mon, 28 Apr 2014 10:57:51 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Mon, 28 Apr 2014 10:57:50 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9i8Y1MzP5I4+G1QfGkQrts08lluQAAI0Uw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> In-Reply-To: <20140428145250.GU27883@mournblade.imrryr.org> 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/gbdB80XJ-7HGaG1PYWT_rs20v7g Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 14:57:54 -0000 Those are all really good questions, but seem to me that they're a matter o= f local trust policy and not policy that should be nailed down in an RFC. = Do you disagree? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 08:05: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 1A41C1A09EE for ; Mon, 28 Apr 2014 08:05: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 CzSUB_4UumUN for ; Mon, 28 Apr 2014 08:04:58 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id 279561A0971 for ; Mon, 28 Apr 2014 08:04:58 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 142so5856621ykq.28 for ; Mon, 28 Apr 2014 08:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7TAshIHEedf8J6PsSxbqyTvfcP0lsr3jW6xNU+WDVCY=; b=ZUI4EVEEcsoJwGiMjTWpz5kEow+qoi35Oe6T89IsZVQxEFaPXXgtyY6cynrQ5c32vU EpvpRzLFuN7tBhQn85CYdCbP164G4cxDYPWNOEU/bMrTNqC0FwkuVMKv9+mc8b9pVbZ6 jtZOkiIE31EGFywWTVljLW7h4XIN8Vp5TwSv4AG4b5BTLTBGqogl9U55DHEDXFgLerWf H/TIPf35M9aylDodt+wPeduVyNTUvX1+NEEvq+3rveLjrrBpnFkd0uVk8K6EQJtRL4/k nIXRerzRT/46thUucGQVofFsWAIAT0A59sbM6BdoJJNUCYPCOQcFJNyfxqXWCjPhHT1Z 4z6g== MIME-Version: 1.0 X-Received: by 10.236.66.135 with SMTP id h7mr38298869yhd.60.1398697497133; Mon, 28 Apr 2014 08:04:57 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Mon, 28 Apr 2014 08:04:57 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Apr 2014 08:04:57 -0700 Message-ID: From: Watson Ladd To: Yoav Nir , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KxyHNHUygRMrAg5EgqDw7zEdRDo Subject: Re: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 15:05:01 -0000 On Apr 28, 2014 2:01 AM, "Yoav Nir" wrote: > > > On Apr 28, 2014, at 10:23 AM, Nikos Mavrogiannopoulos w= rote: > > > On Fri, 2014-04-25 at 09:27 -0400, Salz, Rich wrote: > >> What=E2=80=99s the current state of the Cha-Cha/Poly document? Do thi= ngs need > >> changing, identifiers assigned, or what? > > > > We have submitted our proposal [0] based on the new chacha construction= . > > It is up to the chairs to ask for WG adoption. > > > > [0]. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 > > The chacha in TLS draft depends on draft-nir-cfrg-chacha20-poly1305. > > That still has to go through three =E2=80=9Cstages=E2=80=9D: > > 1. I need to add a bunch of test vectors and an explanation of decryptio= n. Shouldn=E2=80=99t be too difficult with a counter/streamish cipher such = as ChaCha > > 2. We need to get a review of it. The changes to ChaCha are minor and do= not affect security (IMO), but that=E2=80=99s just me. If we can get DJB t= o review it and say it=E2=80=99s OK - so much the better So the changes were relabeling some words as counter and others as nonce, in a different way from ChaCha? I think if you can tell that from a PRF, you can tell the original ChaCha from a PRF, because we have an injection into the original input state. Sincerely, Watson Ladd From nobody Mon Apr 28 08:11: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 A5CD51A0A38 for ; Mon, 28 Apr 2014 08:10:59 -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 JeH4NA2YvU1b for ; Mon, 28 Apr 2014 08:10:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9E1A6F0F for ; Mon, 28 Apr 2014 08:10:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3B8662AB0DD; Mon, 28 Apr 2014 15:10:53 +0000 (UTC) Date: Mon, 28 Apr 2014 15:10:53 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428151053.GV27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-CrJc1VvGPVEP6hxqrHwkVroMZc Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:10:59 -0000 On Mon, Apr 28, 2014 at 10:57:50AM -0400, Salz, Rich wrote: > Those are all really good questions, but seem to me that they're > a matter of local trust policy and not policy that should be nailed > down in an RFC. Do you disagree? If the protocol is to fail closed (as is I think suggested by the extension) then it must be possible to implement it interoperably, in which case these questions should have answers. As it stands, I don't see how one would implement an interoperable fail-closed client and server for OCSP stapling. Current client implementations probably just set a fixed generous upper bound, but there is no reason to expect that all CAs produce new CRLs or new OCSP responses within the arbitrarily locally selected maximum time. Nor is it clear that servers obtain new OCSP responses in a timely manner, and how much extra time to give them to allow for adverse conditions. For example a DDoS of a CAs OCSP responder may last longer than the "[thisUpdate, nextUpdate]" interval, how long is long enough to allow a CA to recover and for servers to obtain new stapled responses? How often should servers retry (don't want the servers trying to get overdue updates perpetuating the DDoS)? The protocol looks under-specified to me. -- Viktor. From nobody Mon Apr 28 08:34: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 4A9801A6F10 for ; Mon, 28 Apr 2014 08:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Y_iNTTzMlH for ; Mon, 28 Apr 2014 08:34:05 -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 3E2B31A6F0A for ; Mon, 28 Apr 2014 08:34:05 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4DF4928514 for ; Mon, 28 Apr 2014 15:34:04 +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 3362228537 for ; Mon, 28 Apr 2014 15:34:04 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 26718FE055 for ; Mon, 28 Apr 2014 15:34:04 +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; Mon, 28 Apr 2014 11:34:03 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Mon, 28 Apr 2014 11:34:02 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9i9CQBpsMmALxjRUm55aQKJHFigQAAleDA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> <20140428151053.GV27883@mournblade.imrryr.org> In-Reply-To: <20140428151053.GV27883@mournblade.imrryr.org> 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/MVBWW61hqNpLECg_4TyKqw5FwJ0 Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 15:34:06 -0000 > The protocol looks under-specified to me. I don't read it as fail-closed; there is no definition of "satisfactory" at= the end of section eight, and the server is free to not send an OCSP respo= nse. If you consider it to be not fail-closed, are your concerns lessened? /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 08: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 D17C81A04C5 for ; Mon, 28 Apr 2014 08:47:45 -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 almPV5Zacuwj for ; Mon, 28 Apr 2014 08:47:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 417211A0352 for ; Mon, 28 Apr 2014 08:47:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 98EE52AB0DD; Mon, 28 Apr 2014 15:47:42 +0000 (UTC) Date: Mon, 28 Apr 2014 15:47:42 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428154742.GW27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> <20140428151053.GV27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C0pQG4Hnpj2M5CkIu4ldzWk9dKc Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:47:46 -0000 On Mon, Apr 28, 2014 at 11:34:02AM -0400, Salz, Rich wrote: > > The protocol looks under-specified to me. > > I don't read it as fail-closed; there is no definition of "satisfactory" at the end of section eight, and the server is free to not send an OCSP response. > > If you consider it to be not fail-closed, are your concerns lessened? What's the point if it does not fail-closed? The client insists that the server provide an OCSP response, but then does not validate it (some notion of freshness is surely part of validation, but no freshness algorithm is indicated). Does the server have to provide OCSP responses for every intermediate CA in the chain? Or just for the leaf certificate? Or only for the leaf certificate and those intermediate CAs whose certificates happen to include the proposed TLS feature extension? -- Viktor. From nobody Mon Apr 28 09:04:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AD81A6F11 for ; Mon, 28 Apr 2014 09:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCVd39pOQEI4 for ; Mon, 28 Apr 2014 09:04:21 -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 764A41A6F07 for ; Mon, 28 Apr 2014 09:04:21 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D7A5474D0 for ; Mon, 28 Apr 2014 16:04:20 +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 915CA474B8 for ; Mon, 28 Apr 2014 16:04:20 +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 8CF2C2026 for ; Mon, 28 Apr 2014 16:04:20 +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; Mon, 28 Apr 2014 12:04:20 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Mon, 28 Apr 2014 12:04:19 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9i+TbsVyE+DindR+6uBpIWtf1M6AAACdgg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> <20140428151053.GV27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> <20140428154742.GW27883@mournblade.imrryr.org> In-Reply-To: <20140428154742.GW27883@mournblade.imrryr.org> 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/vNFciXyEnODFTNREfzk0vqufgc8 Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 16:04:22 -0000 > What's the point if it does not fail-closed? The client insists that the= server provide an OCSP response, but then does not validate it (some notio= n of freshness is surely part of validation, but no freshness algorithm is = indicated). A client can always ask for an OCSP response, but it is up to that client t= o decide whether or not the response is satisfactory. If there's a hurrican= e bearing down on me, I might be willing to accept a stale status response = from my local Red Cross chapter, for example.=20 > Does the server have to provide OCSP responses for every intermediate CA = in the chain? Or just for the leaf certificate? Or only for the leaf cert= ificate and those intermediate CAs whose certificates happen to include the= proposed TLS feature extension? Well RFC 6066 says "only one OCSP response may be sent" and while RFC 2560 = allows multiple answers, it says that they are a "response for each of the = certificates in the request." Since the server's SSL cert is implied by 60= 66, and since there is no other way to specify additional certs, then the a= nswer to your questions would be "just the leaf." /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Apr 28 09:25: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 09F391A6F50 for ; Mon, 28 Apr 2014 09:25:03 -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 Ju7p-rMHaR8s for ; Mon, 28 Apr 2014 09:25:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65C1A08C5 for ; Mon, 28 Apr 2014 09:25:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 680702AAD0C; Mon, 28 Apr 2014 16:24:59 +0000 (UTC) Date: Mon, 28 Apr 2014 16:24:59 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428162459.GZ27883@mournblade.imrryr.org> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> <20140428151053.GV27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F625@USMBX1.msg.corp.akamai.com> <20140428154742.GW27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XTB5UKMWtIoy_4usrKtRK2M8HpM Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 16:25:03 -0000 On Mon, Apr 28, 2014 at 12:04:19PM -0400, Salz, Rich wrote: > > What's the point if it does not fail-closed? The client insists > > that the server provide an OCSP response, but then does not validate > > it (some notion of freshness is surely part of validation, but no > > freshness algorithm is indicated). > > A client can always ask for an OCSP response, but it is up to > that client to decide whether or not the response is satisfactory. > If there's a hurricane bearing down on me, I might be willing to > accept a stale status response from my local Red Cross chapter, > for example. That's nice for an informed, security-literate user operating a browser, but completely impractical for, say, an SMTP server. A reasonably interoperable algorithm is required for deciding which responses are required and how fresh they need to be before failing closed. > > Does the server have to provide OCSP responses for every > > intermediate CA in the chain? Or just for the leaf certificate? > > Or only for the leaf certificate and those intermediate CAs whose > > certificates happen to include the proposed TLS feature extension? > > Well RFC 6066 says "only one OCSP response may be sent" and while > RFC 2560 allows multiple answers, it says that they are a "response > for each of the certificates in the request." Since the server's > SSL cert is implied by 6066, and since there is no other way to > specify additional certs, then the answer to your questions would > be "just the leaf." Which leaves the intermediate CAs out of scope... I plan to continue to treat CRLs, OCSP and OCSP stapling as variants of the emperor's new clothes. -- Viktor. From nobody Mon Apr 28 10:33: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 AB2311A6FE5 for ; Mon, 28 Apr 2014 10:33:47 -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 9zQ2EZcIrpd1 for ; Mon, 28 Apr 2014 10:33:47 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EE5F11A6F39 for ; Mon, 28 Apr 2014 10:33:46 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 99943678063 for ; Mon, 28 Apr 2014 10:33: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=sDw2G1RMldZg8TMewK/n LMaRSP8=; b=IYX1UVPvcnWf4pd/AqoCkm0tWCt424pR6wA/PMvMafEATW6MZA2A noPadBDXd06dCZd2F4diDEWVtDYEerYUh8vC3t/l2v8xxz8Ee0v80yw4oqUTLPH+ MoskQqMFJqzPa2W8h7JEvz9WDlIKbbqNgV0kJIhlXeac1L2r3pPv8b4= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 4E75B678062 for ; Mon, 28 Apr 2014 10:33:45 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so6122299wib.5 for ; Mon, 28 Apr 2014 10:33:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr16435662wid.39.1398706423691; Mon, 28 Apr 2014 10:33:43 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 10:33:43 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F5D0@USMBX1.msg.corp.akamai.com> Date: Mon, 28 Apr 2014 12:33:43 -0500 Message-ID: From: Nico Williams To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9fw_p-nm4Vbo0bXuJ-Ss2SDM0So Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 17:33:47 -0000 On Mon, Apr 28, 2014 at 9:57 AM, Salz, Rich wrote: > Those are all really good questions, but seem to me that they're a matter of local trust policy and not policy that should be nailed down in an RFC. Do you disagree? IMO: - freshness requirements are indeed ultimately a local policy issue - but a server-side freshness commitment is something that can be pinned to, therefore adding value when local freshness policy is loose. The freshness commitment might come from the OCSP responder, but it's optional. And the text of the RFC makes it seem very likely that nextUpdate is all about OCSP responders that poll CRLs, and that OCSP responders that have direct access to the revocation Truth might well never include nextUpdate. The freshness commitment might come from the TLS server -- where? This might be an item for TACK. Nico -- From nobody Mon Apr 28 10:34: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 9AEF41A6FF3 for ; Mon, 28 Apr 2014 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JZOETdu_olO for ; Mon, 28 Apr 2014 10:34:42 -0700 (PDT) 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 19DB51A6FEA for ; Mon, 28 Apr 2014 10:34:36 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id oy12so8350703veb.18 for ; Mon, 28 Apr 2014 10:34:36 -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=GmQezipgW9KMvGBgdUkJvqI37nIq0IFqnWLGOosSXHA=; b=aLoUPcRbQeH2peNiLCDSSEFG4p0XXvCcnbl7xPnXyn7LdWK1UJ/OSokTrbDk/apKVv kPSsdJ9EoP2V9kTDeqpHveRwdL5Tim6A4ZUdC9MQFZP3Snunv74Z+y/iJ4bWE9NcHzcE chuMC+GTXfTmQutvdpH+jbUY6I4/nNJKDbGPaPjOIU/dQLjd8Q2w66sufSWM+sLMqD18 8t5DzZtXr9pb5bJo/hKzwNbpylNlMXx7TvQp7g2ELx1MsD3gLQYYJxEClfGt/4DjcaQV SrodJWeATJoVtDpNIxoyfvRvbDI8n2ss0QC+KArsx7rXxnQswDSnZykb+HXySd4p9wsx Q0gA== 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=GmQezipgW9KMvGBgdUkJvqI37nIq0IFqnWLGOosSXHA=; b=fUfFea2Kn3+DxWhUJ9ZDxHdzlnjgyowKSO3j4IPMlpcMlpysIaR6NhZhizNNpOk8pb JBid1Fb2JVutjH1IMi0NZuGslBHufNgsVXMDnZR4gl8Yi8BYXqGT4Zp+L+g+Rp+FvqWu H2l4d9Bsz6Qqm1Z8mNGp2JqQKNj+PfXbcd+NrGI54Xg7WVltmrWf1F/PK4+YVpi469Yf +jmFHLi3e2m+dREmwWcpSba+v2rwUMgTTUfhqfpVPTHh4U3yqwTsut37BladJEFusWfx mUC/QI1XFk0aZoZdHvwuf9jzyvbR1rGhNIHomZK1DcBO0sK3L9hQEhYLS48z5lKTM2FV yWEg== X-Gm-Message-State: ALoCoQnTNrprb5BVRsSvfvhJM90UxlLBC/Afe8AvtL99uYXAg+SZcTP/v/WerCAq28qp2NVpuyb2m47ZkquJUIxV2eTy9+HkY51SosbdaEEEDtxQoMwYfeW4+g7cLx1Ld1dliEgod5A1gii2A513IqwQc1S3FTomaq19m1M7QomTd6Hxu/HWgSXu0JFVxpsd+ykynWbofe5L X-Received: by 10.52.253.75 with SMTP id zy11mr21462546vdc.10.1398706476158; Mon, 28 Apr 2014 10:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Mon, 28 Apr 2014 10:34:16 -0700 (PDT) In-Reply-To: <48E70918-765E-4EAE-8FE0-DCC038C61314@vigilsec.com> References: <535E353A.9030008@comodo.com> <48E70918-765E-4EAE-8FE0-DCC038C61314@vigilsec.com> From: Adam Langley Date: Mon, 28 Apr 2014 10:34:16 -0700 Message-ID: To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/spDBtq0nPT4_nVYGgTKIu-5peXw Cc: Klemens Baum , "tls@ietf.org" , Phillip Hallam-Baker Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 17:34:43 -0000 On Mon, Apr 28, 2014 at 7:13 AM, Russ Housley wrote: > The IESG has assigned me as the expert for this IANA registry. If the document is ready for approval, we can work the review in parallel. For what it's worth: I support adding a certificate extension to indicate OCSP Must Staple and https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ appears to achieve that. It's going to take a while for various parts of the ecosystem to get into shape (including browsers), but it would be good not to block on OID assignment. Cheers AGL From nobody Mon Apr 28 10: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 9987C1A6F17 for ; Mon, 28 Apr 2014 10:42:04 -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 wl9ynZhoeYc4 for ; Mon, 28 Apr 2014 10:42:03 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 348871A6F93 for ; Mon, 28 Apr 2014 10:42:03 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id c6so5392883lan.30 for ; Mon, 28 Apr 2014 10:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vwEOWkVtqP4YLOrU29UQ5VYgUW/TGE++sg+Cni2lxaE=; b=xivdVXqJ5aUpbknqXxqD70C0YvdGASPidrTn1P/kxkl6Xehh1uFBJgjC4mXAsQhzTS CuJF378F+66CnxrmTtds5zCN4ES5xT48aJPS0xTSec/dPGDnnsSXEhiar/re/SWHp4Tz x0U38ie/p5HaSBXxxxqBoB686qXhveGFZwmcQ+o0e19yIBs52JqaBt4mVX8/ZUiUYH5Q MuP2yY7WdxWuhDidbkZjmf3PLZQY6DFcnmsobFaPQ4FI/1r01PIh5GtbsOWYDXK6sx2r qvyYa6Mii+Ss+0D6OuhC0ViffnCQh/gEuGKfadvUJm5CIyO2NbIxgVTCaa5alEqKHXra iz2A== MIME-Version: 1.0 X-Received: by 10.152.18.170 with SMTP id x10mr1607441lad.55.1398706921683; Mon, 28 Apr 2014 10:42:01 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.35.131 with HTTP; Mon, 28 Apr 2014 10:42:01 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Apr 2014 10:42:01 -0700 X-Google-Sender-Auth: W4WZBGZJiBz3bUwSUvF9ARqAsFk Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kLhAxQbqeXk9KqiWj36n-hfFbRE Cc: "tls@ietf.org" Subject: Re: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 17:42:04 -0000 On Mon, Apr 28, 2014 at 8:04 AM, Watson Ladd wrote: > So the changes were relabeling some words as counter and others as > nonce, in a different way from ChaCha? I think if you can tell that > from a PRF, you can tell the original ChaCha from a PRF, because we > have an injection into the original input state. The whole AEAD construction is a "change" from the way that DJB does it in NaCl and so probably need review. I spoke to DJB about it at CRYPTO 2013, but that's hardly an endorsement. Having said that, I think this does need to be pushed forward. Perhaps the best path is as an individual submission. I'll try and add the test vectors and then see whether that's possible. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Apr 28 10:42: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 7FBC71A6F9B for ; Mon, 28 Apr 2014 10:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSR08KuB796P for ; Mon, 28 Apr 2014 10:42:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C11A6F54 for ; Mon, 28 Apr 2014 10:42:43 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3SHge1l020259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Apr 2014 19:42:41 +0200 (MEST) In-Reply-To: <20140428162459.GZ27883@mournblade.imrryr.org> To: tls@ietf.org Date: Mon, 28 Apr 2014 19:42:40 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PunuYoWXlGm6dbxGrGYEF6Ja7lM Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? 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, 28 Apr 2014 17:42:45 -0000 Viktor Dukhovni wrote: > >Salz, Rich wrote: >> >> Well RFC 6066 says "only one OCSP response may be sent" and while >> RFC 2560 allows multiple answers, it says that they are a "response >> for each of the certificates in the request." Since the server's >> SSL cert is implied by 6066, and since there is no other way to >> specify additional certs, then the answer to your questions would >> be "just the leaf." > > Which leaves the intermediate CAs out of scope... I plan to continue > to treat CRLs, OCSP and OCSP stapling as variants of the emperor's > new clothes. There exist 2 different TLS extension for OCSP responses. Old Single OCSP response: rfc6066 (originally defined in rfc3546) New Multiple OCSP responses: rfc6961 https://tools.ietf.org/html/rfc6961 >>Viktor Dukhovni wrote: >>> >>> What's the point if it does not fail-closed? The client insists >>> that the server provide an OCSP response, but then does not validate >>> it (some notion of freshness is surely part of validation, but no >>> freshness algorithm is indicated). With fail-closed you probably mean "fail-hard"? EV certs seem to be able to provide a benefit without "fail-hard". It is difficult to define a global/universal guaranteed service quality for the OCSP responder service of the CA, and it is difficult to define a minimum service quality for the server, in which time an admin will notice and fix a problem with the OCSP response refreshing of his server. It is really a client-side local policy issue. The client could also perform OCSP request itself for the server's cert (chain), whenever it does not consider the server's response "fresh enough". There are two possible "attack" scenarios: (1) the attacker steals (or breaks) the server's real key&cert, so that the Certificate extension will indicate whatever the original admin requested when he purchased the certificate (2) the attacker manages to subvert the RA process of a public CA and gets a different cert without the certificate extension issued. A fail-hard on the certificate extension can not protect you from (2). -Martin From nobody Mon Apr 28 11:02: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 6C0A61A6FCE for ; Mon, 28 Apr 2014 11:02:23 -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 hVdZqXwtvH-m for ; Mon, 28 Apr 2014 11:02:22 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC841A6FBA for ; Mon, 28 Apr 2014 11:02:21 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3SI2I0A024126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Apr 2014 20:02:18 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Mon, 28 Apr 2014 20:02:18 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zwy7M9l5SDx0ZufQ4HdVrIMXdJo Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature Extension? 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, 28 Apr 2014 18:02:23 -0000 Salz, Rich wrote: > > Well RFC 6066 says "only one OCSP response may be sent" and while > RFC 2560 allows multiple answers, it says that they are a > "response for each of the certificates in the request." > Since the server's SSL cert is implied by 6066, and since there > is no other way to specify additional certs, then the answer to your > questions would be "just the leaf." AFAIK, rfc2560 allows the OCSP response to contain the status of more than one certificate, but it can only be signed by a single OCSP responder. I assume that each certificate in the server's certificate refers to different OCSP responder. Processing multiple OCSP responses from the TLS multiple certificate status extension will also be interesting for TLS client that essentially throw away everything but the Server certificate from the Server's TLS Certificate handshake message and perform a new path discovery, because the resulting path may be different from the one that was sent by the server. This may happen more often with the certificate paths that are used for backward compatibility, where the current 2048-bit RSA rootCA cert is included as a cross-CA certificate to an old 1024-bit RSA trust anchor. Google seems to be using two cross-certs in their forward path that you may not be aware of if you look at the path of the server cert as verified by a recent browser. -Martin From nobody Mon Apr 28 11:17: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 276B11A7023 for ; Mon, 28 Apr 2014 11:17: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 LusOmUbGrh4n for ; Mon, 28 Apr 2014 11:17:47 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2890F1A6FF2 for ; Mon, 28 Apr 2014 11:17:46 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id s7so393805qap.27 for ; Mon, 28 Apr 2014 11:17:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=2IfVoDEDdXTvO/MRL/mn7TvSD3bNz8c4x41fA7VBLiI=; b=KaOxmBbp/RqwhW3JVqbGYd+khvlM9ukuwXg1H4qQ9RIEW5xcwoNUF7F7qCPHIiqF7S l0KCSrnX/9jVMD52uzj3CKqHGTTjvUlqD3v/r99AoeFYWKuRxmcTJgpp6LL0W5Kc2Fg2 dxjUhGmyL7Tge4OWQ7ag68nCR6uL7sb4jFGS4GATCfeSCaTTy0AG1kUWEbUQKHlGVTvr kltzpneUP9seBZXw3ehC9l4y/pg/CXkrmeJvc1Ak6nuxqaHcvxnYwiEwTcIIkqp/83ZV mbOW0fxJ/uHsjutwjEoawC6qvyJPdjEnPfCfI/+7d9DfIIj22s+WNgbdNSFiJZFJq1wR JmXQ== X-Gm-Message-State: ALoCoQnEZh5W7UBHSoMJjS5B0CoK6JGuF68jSNDAiuALOzRpnxPkNRz6dhtnOexTw59yF1hhzysG X-Received: by 10.229.198.2 with SMTP id em2mr6669064qcb.21.1398709065958; Mon, 28 Apr 2014 11:17:45 -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 q62sm23020761qgd.0.2014.04.28.11.17.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Apr 2014 11:17:45 -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 18DEBAC287F; Mon, 28 Apr 2014 14:17:44 -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: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> Date: Mon, 28 Apr 2014 14:17:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2FA44B4E-6932-42B3-A0AB-7EEDA251DE6A@pahtak.org> References: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/clGHkgj25j_L5uhZ5aWfiBuQfZo Cc: tls@ietf.org Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 18:17:49 -0000 On Apr 28, 2014, at 1:42 PM, Martin Rex wrote: > EV certs seem to be able to provide a benefit without "fail-hard". That's the first time I've ever heard that claim. What benefit do they = provide users? --=20 Stephen Checkoway From nobody Mon Apr 28 12:26: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 A2E861A6FED for ; Mon, 28 Apr 2014 12:26:42 -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 RL1scpyxFstg for ; Mon, 28 Apr 2014 12:26:39 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1561D1A6FEC for ; Mon, 28 Apr 2014 12:26:39 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 71B9D33CF8A; Mon, 28 Apr 2014 19:26:38 +0000 (UTC) Sender: geoffk@localhost.localdomain To: tls@ietf.org References: <535E353A.9030008@comodo.com> <20140428142029.GT27883@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F59F@USMBX1.msg.corp.akamai.com> <20140428145250.GU27883@mournblade.imrryr.org> From: Geoffrey Keating Date: 28 Apr 2014 12:26:38 -0700 In-Reply-To: <20140428145250.GU27883@mournblade.imrryr.org> Message-ID: Lines: 28 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/FMoGkn5H_RveQX3xwQRoLZBeoOk Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:26:42 -0000 Viktor Dukhovni writes: > On Mon, Apr 28, 2014 at 10:32:10AM -0400, Salz, Rich wrote: > > > > OCSP stapling gives no indication of when a verifier is to > > > consider a particular status response to be stale. > > > > Not sure what you mean; thisUpdate, nextUpdate, producedAt aren't sufficient? > > Well, "nextUpdate" is optional per RFC 6960, and even when present > it is not clear that the frequency of server updates of stapled > OCSP responses is expected to provide responses whose nextUpdate > is always in the future. My understanding is that 'nextUpdate' is essentially the expiry date for the OCSP response, and that if it's not present, it's considered to expire immediately (so should never appear in a stapled response? or have some indeterminate client-determined expiry time that the server doesn't know about? or have the nonce matching the one that the client probably didn't bother to send in the request_extensions field? If only there was a RFC that documented how this should work...). It is perhaps an unfortunately named field; the naming is based on the history of OCSP, which was apparently designed to be (basically) CRL lookup service, so an OCSP responder would just consult its local copy of the CRL; nextUpdate was when the responder would next fetch a new copy of the CRL and thisUpdate was the last time it did so. From nobody Mon Apr 28 12:27: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 60CFF1A04F1 for ; Mon, 28 Apr 2014 12:27:02 -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 ZByWA9d4U9BA for ; Mon, 28 Apr 2014 12:26:55 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id A6C101A6FAC for ; Mon, 28 Apr 2014 12:26:55 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so1681618wgg.20 for ; Mon, 28 Apr 2014 12:26:54 -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=MOt+3dqgCjHGrCFNI7Rc4iPidi4zQxGumQVcGrLxH1o=; b=WpD5xrXe1Y2+c6GQVEdYRSLBJ0npUJ0yo1b2F4VGA6mlxZ1gHxUep6/0hEghYFWwZN U/oUtfIJutPstkBuSuULEvP3LHYeMLGOmDrZteAxUxGxUaYBpT9HPL5G9TQ/zKqoTivw MkW5VMvunkodo4UKWfH7rO2Bx/sS50mJNSD6OY3SLGQb1xUwkhddYsRQSUvJyTr1tUH2 ITwok+2DztBuLLiNiaQCdRRQa6D7KSBH43h08r4GlosI0+rC0xBzDyh3TfR1t7ocnJP9 bEQ+5WE0Gr7tseCeL7Qp/U0USdBC5iVhYi0BWUkElNRpD4FHIHlrs4UU5sLSARmZPRSS oOEw== X-Received: by 10.180.91.40 with SMTP id cb8mr16901877wib.34.1398713214441; Mon, 28 Apr 2014 12:26:54 -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 h1sm27411126wjy.7.2014.04.28.12.26.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 12:26:53 -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, 28 Apr 2014 22:26:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF3F46B-0DD7-4262-8004-D1C8E5444FD5@gmail.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E915@USMBX1.msg.corp.akamai.com> <1398669797.2453.6.camel@dhcp-2-127.brq.redhat.com> To: Adam Langley X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kp-nqqtsSURWaGoGIg4Lh5Y1xt8 Cc: "tls@ietf.org" Subject: Re: [TLS] chacha/poly state? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 19:27:04 -0000 On Apr 28, 2014, at 8:42 PM, Adam Langley = wrote: > On Mon, Apr 28, 2014 at 8:04 AM, Watson Ladd = wrote: >> So the changes were relabeling some words as counter and others as >> nonce, in a different way from ChaCha? I think if you can tell that >> from a PRF, you can tell the original ChaCha from a PRF, because we >> have an injection into the original input state. >=20 > The whole AEAD construction is a "change" from the way that DJB does > it in NaCl and so probably need review. I spoke to DJB about it at > CRYPTO 2013, but that's hardly an endorsement. >=20 > Having said that, I think this does need to be pushed forward. Perhaps > the best path is as an individual submission. I'll try and add the > test vectors and then see whether that's possible. >=20 Yeah, so I don=92t know DJB at all. Once we get the next revision = published with decryption and some test vectors, we can talk to Dave and = Kathleen, and see where this can progress better, and also ask DJB for a = review. We didn=92t get much at CFRG. Yoav= From nobody Mon Apr 28 12: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 EB6191A701F for ; Mon, 28 Apr 2014 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV7dPexzquMn for ; Mon, 28 Apr 2014 12:32:44 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 28F301A7031 for ; Mon, 28 Apr 2014 12:32:44 -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=1398713564; x=1430249564; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=emcB6ouIPHSe6n0L2dOdmdw5weRLuwdCETDP+CJC6Kg=; b=LYIF+n0F4cncWGMUgR/wzy9uCuIEIF4dxDU/ET/Q53bZWOHXzR1OK60I CoyQAr4SRqiERpjzFVkssJJ0lpd56So4YnlEfEfcs1/hBqA+hf2I2dLna gvuitGvmXol/O5UyMI3kU6kHgnse7hc+Ql1PBbDUXs5iinW2tWzf+ZSyi I=; X-IronPort-AV: E=Sophos;i="4.97,945,1389697200"; d="scan'208";a="249143007" 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 Apr 2014 07:32:14 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0174.001; Tue, 29 Apr 2014 07:32:14 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9jGI59iq5roraQSHelTEnkHoMLaw== Date: Mon, 28 Apr 2014 19:32:13 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC09A2C@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/FsQsmCIbA2dAD1qpOOWokhrVgcU Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:32:48 -0000 Stephen Checkoway writes:=0A= >On Apr 28, 2014, at 1:42 PM, Martin Rex wrote:=0A= >=0A= >> EV certs seem to be able to provide a benefit without "fail-hard".=0A= >=0A= >That's the first time I've ever heard that claim. What benefit do they=0A= >provide users?=0A= =0A= Well now that's a completely different question. The original statement wa= s=0A= that they provide a benefit, no-one said the benefit was to users.=0A= =0A= Peter.= From nobody Mon Apr 28 12: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 5CAA71A6FA1 for ; Mon, 28 Apr 2014 12:35:31 -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 iaCX5WN0WKij for ; Mon, 28 Apr 2014 12:35:29 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6AED21A6F0A for ; Mon, 28 Apr 2014 12:35:29 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so7414142qcx.18 for ; Mon, 28 Apr 2014 12:35: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:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=lIUniBsi5hKSRplGy3pjhiRWRaMqGCrWECNL5NdXVmA=; b=VCjWcqYJgpg1d+0FqiJ7gYQpRa8u5/UyCqqnpheLrxTMvGhcF8NYjBSOi+ZY7QUrfL HUB0ZU0Hx8eb4hsTX1wJ49gdTPW64AVtxjNlMUKjq5pLQSWMfmrV3Lm1/4cLGE9f6Idi IYPCVc+MwTsOTc0ENYFfKlcbRF7tHAAtM/u88Jk27a5ljoYsQ5WalyIWmZCxTfVT8VVR kvkDo8T3VdFMKGqUZEULA76SLKF6EmzRmGzByKyDYvqje51ZEyXWzfEzYrUoYvCSHlzM 2yoq1s5SbddnNGXZ74G4omPTvj67iXyZGE6lX43M5rU+nOo6CPlUcbV6izn7U7p6e+GM tTAQ== X-Gm-Message-State: ALoCoQkzwWCoDXB62l61ol9E0ZIsB04bGpjdjesVaMMUJM+MyFauT7m4vU2m97AG26ysi3+IImgs X-Received: by 10.140.21.231 with SMTP id 94mr34550227qgl.31.1398713728288; Mon, 28 Apr 2014 12:35:28 -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 c16sm34890813qaw.4.2014.04.28.12.35.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Apr 2014 12:35:27 -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 D1205AC287F for ; Mon, 28 Apr 2014 15:35:26 -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: <9A043F3CF02CD34C8E74AC1594475C738AC09A2C@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Mon, 28 Apr 2014 15:35:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4ACA9D88-4A16-415D-AFC9-2CC5F8D874D1@pahtak.org> References: <9A043F3CF02CD34C8E74AC1594475C738AC09A2C@uxcn10-tdc06.UoA.auckland.ac.nz> To: "" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c81gH-c26IzOcUaib5nBjuicy-s Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:35:31 -0000 On Apr 28, 2014, at 3:32 PM, Peter Gutmann = wrote: > Stephen Checkoway writes: >> On Apr 28, 2014, at 1:42 PM, Martin Rex wrote: >>=20 >>> EV certs seem to be able to provide a benefit without "fail-hard". >>=20 >> That's the first time I've ever heard that claim. What benefit do = they >> provide users? >=20 > Well now that's a completely different question. The original = statement was > that they provide a benefit, no-one said the benefit was to users. Indeed. Your book has a very nice discussion of them. --=20 Stephen Checkoway From nobody Mon Apr 28 12:36: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 6854F1A6FAA for ; Mon, 28 Apr 2014 12:35:59 -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 xbjDSWiWj4IE for ; Mon, 28 Apr 2014 12:35:58 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07C1A6FA9 for ; Mon, 28 Apr 2014 12:35:58 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 04B721DE060 for ; Mon, 28 Apr 2014 12:35: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=bqPm26VZXErSBsA2gYRX EWmGLk8=; b=DXzlLfKEb2HY0MvhZj0uz6+hSM2IqIV+x4pnEOmkBhgXd+O/oF9m A9+nhnlAHhIjxGuSNdrKqiUE357duoQyoRBty3A4jh13YGVkdsRZ6u/vecq4oMsu k9xb3IVwt/jS1ywY7wByYUVWsT5F9tyvz+mNr8W2B0epqCM162V19cc= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 9FA421DE05D for ; Mon, 28 Apr 2014 12:35:57 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id x12so1351817wgg.23 for ; Mon, 28 Apr 2014 12:35:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr16932724wib.42.1398713756601; Mon, 28 Apr 2014 12:35:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:35:56 -0700 (PDT) In-Reply-To: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> References: <20140428162459.GZ27883@mournblade.imrryr.org> <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> Date: Mon, 28 Apr 2014 14:35:56 -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/aOZH2hBKMFDcUFDmPPioKoHVcg4 Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:35:59 -0000 On Mon, Apr 28, 2014 at 12:42 PM, Martin Rex wrote: > It is difficult to define a global/universal guaranteed service > quality for the OCSP responder service of the CA, and it is > difficult to define a minimum service quality for the server, > in which time an admin will notice and fix a problem with the > OCSP response refreshing of his server. > > It is really a client-side local policy issue. The client could > also perform OCSP request itself for the server's cert (chain), > whenever it does not consider the server's response "fresh enough". Right, however, servers cannot know what policies clients have, so how can they work to provide fresh-enough responses? A notification from the client, that it is rejecting the server's credentials due to inadequate freshness, would not necessarily be all that helpful. A commitment to a given freshness definitely helps here: the client can impose the min (or would that be max? :) freshness of local policy and server commitment. Nico -- From nobody Mon Apr 28 12:40: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 D5DD41A6F9E for ; Mon, 28 Apr 2014 12:40:27 -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 J5uxRqVd9ajw for ; Mon, 28 Apr 2014 12:40:27 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 57E991A6F42 for ; Mon, 28 Apr 2014 12:40:27 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id B1136202038 for ; Mon, 28 Apr 2014 12:40:26 -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=AO44zSNYQxogNocPOEzk g0CwebE=; b=ZbXsgczrVpQFU0tnc2OiGBlGePdJcTGXI8znSaOWWepBonor14Jk V3/4Ghizs9Fv//jxvK/tugxig2hfSzcvLVsucjaaWSxeXN/HE2aOAlxcbjp6qiK+ XC4nB6jFYEOe01vzhjcUGAmVeqeKPThxo5/aJbkX8h9S4eESefWgApA= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 5434D202022 for ; Mon, 28 Apr 2014 12:40:26 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so128168wib.7 for ; Mon, 28 Apr 2014 12:40:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.109.227 with SMTP id hv3mr21128840wjb.10.1398714024920; Mon, 28 Apr 2014 12:40:24 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 12:40:24 -0700 (PDT) In-Reply-To: <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> References: <20140428162459.GZ27883@mournblade.imrryr.org> <20140428174240.E04D21ACE1@ld9781.wdf.sap.corp> Date: Mon, 28 Apr 2014 14:40:24 -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/sEaxmnrTOsJ5NKDg9XC_WSmtZ5U Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:40:28 -0000 On Mon, Apr 28, 2014 at 12:42 PM, Martin Rex wrote: > It is difficult to define a global/universal guaranteed service > quality for the OCSP responder service of the CA, and it is > difficult to define a minimum service quality for the server, > in which time an admin will notice and fix a problem with the > OCSP response refreshing of his server. The server basically needs a "cron" job to fetch fresh OCSP responses regularly. A sufficiently long failure to get fresh responses should trigger alerts to get admin attention. Let's say the server's admins commit to 24 hour freshness (no response will be older than 24hrs), with a cron job / daemon fetching new responses every 8 hours. A first failure to get a response might not elicit any alerts, but a second should. (A first failure might lead to retrying sooner than the otherwise next-scheduled attempt in 8 hours.) Nico -- From nobody Mon Apr 28 12:44: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 520A81A6F0A for ; Mon, 28 Apr 2014 12:44:28 -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 UJf4THeqEgyN for ; Mon, 28 Apr 2014 12:44:24 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id ADC711A064C for ; Mon, 28 Apr 2014 12:44:24 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1EDAD33CF8A; Mon, 28 Apr 2014 19:44:24 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> From: Geoffrey Keating Date: 28 Apr 2014 12:44:24 -0700 In-Reply-To: <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> Message-ID: Lines: 14 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/ZeVb29IL91R--TMZjMSD9kq-fq4 Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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, 28 Apr 2014 19:44:28 -0000 mrex@sap.com (Martin Rex) writes: > Processing multiple OCSP responses from the TLS multiple certificate status > extension will also be interesting for TLS client that essentially throw > away everything but the Server certificate from the Server's TLS Certificate > handshake message and perform a new path discovery, because the resulting > path may be different from the one that was sent by the server. This is only a problem if the new path discovery might use certificates which weren't sent from the server (built-in intermediates or ones fetched from the web), for which of course the server won't have sent OCSP responses. Another way to put this is that the server needs to send all necessary intermediates for OCSP stapling to work properly. From nobody Mon Apr 28 12:51: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 75BEC1A6FD2 for ; Mon, 28 Apr 2014 12:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.131 X-Spam-Level: X-Spam-Status: No, score=-0.131 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnuZtArKI28I for ; Mon, 28 Apr 2014 12:51:09 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 15BA11A6FEE for ; Mon, 28 Apr 2014 12:51:03 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so8466112veb.21 for ; Mon, 28 Apr 2014 12:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xKW++ZG32jZWueMQ+2Gc0ueI6yuwgQAkIL1VeMCIEyA=; b=BrtPBJN04PUTasGcW0ecwZE3aLeQCKeg2XFRqwS46c1ZnBwE4EazAScRQ8lyaAxjDz pTMuPerIQyi9nBFaX8kjJN55pvu+BzQMfSM2RiqbUAd4Ovq5ZR/s7NPsFSQHdKnq+lYt 1xPs4r6NNo7AtzxVP5eL+k2/l+jzvFsqzAI1yy9ZuA/IKOL9hRc+TFkYo2XFrYOO+76v AiIVWppRVFUPmEmEVj0gEP2UDnRqJ6WGS/39ACVPsyPqnRVwsZRiIPv639Xzw7NEU3ga szjomLm+o1qiQPl2lpPwNYv6+Y0oHrdmGgTfI1cQFR7dotkBglhqnuxVZ7y16IKZ9N59 x6zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=xKW++ZG32jZWueMQ+2Gc0ueI6yuwgQAkIL1VeMCIEyA=; b=mjcZVwGUEE6Iqsfa9yzhBMyLLsdkkPbT6EmMQgXEd0roXlNanKaz/Yook271JnXwDq 1Z5hDs31hyoZFWUGq0KsKA8sGv+7ixrbPUan7pCUt2VJDlRV/cm2+AkOjSlhpTCUTqc0 oiEkSpZOye/oWCMtpsQxBFXAQAAEio0qA0l66tqL9K3xs2Ht7g83EaugKCRmLdtigg04 m4IalEYOWLA2jkT4bTnA7BQG1oxQxBst7hZvN/nL8Af47ayQyATggxE2K0L8wv81Vm9U WtFCqvF9AlfCaAl8wAfHJld4N0tFCuIxrPVMGL+CLKlqXrkQrT+ZYLSMo05wcf3lorqf GaEQ== X-Gm-Message-State: ALoCoQlbu6IE83edyomdovcpJTTmyfywOSuAm3/uGQuFGYui16if+KNYQcRX8wWadD3K7zd/3q8gcVFh1QGQBjEgOjnPEfvUdrFfgsXmf+ve80Q2L1Tm9djpAfi7h2Ud9OrMrl2bc69TMW7TwUZNn1ekpy7ZgSuH5Ut9HSNGgJuStgWdBTazb5arHa1irWxvtX9C5zo5LoEj MIME-Version: 1.0 X-Received: by 10.220.113.207 with SMTP id b15mr78412vcq.55.1398714661965; Mon, 28 Apr 2014 12:51:01 -0700 (PDT) Received: by 10.52.135.4 with HTTP; Mon, 28 Apr 2014 12:51:01 -0700 (PDT) Date: Mon, 28 Apr 2014 12:51:01 -0700 Message-ID: From: Wan-Teh Chang To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yAKkPuCi83BtAj4KR011t-PkiqA Subject: [TLS] Need a contact person for IBM WebSphere Application Server X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 19:51:15 -0000 Hi, I am a computer programmer working on SSL/TLS in the Google Chrome browser. If you work on IBM WebSphere Application Server or can put me in touch with someone who does, please reply to me. I need to report a TLS handshake timeout failure between Google Chrome and WebSphere Application Server/7.0. http://code.google.com/p/chromium/issues/detail?id=363583 Thanks, Wan-Teh Chang From nobody Mon Apr 28 16:10: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 0A5FC1A6FB8 for ; Mon, 28 Apr 2014 16:10:27 -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_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5iD1Eb7sbUX for ; Mon, 28 Apr 2014 16:10:19 -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 AB6491A6F17 for ; Mon, 28 Apr 2014 16:10:18 -0700 (PDT) Received: from [174.226.66.239] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Weugh-0000cF-KG; Mon, 28 Apr 2014 19:10:15 -0400 Date: Mon, 28 Apr 2014 16:10:09 -0700 From: Bill Frantz To: "Salz, Rich" X-Priority: 3 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79a5da91eb21d8fb029e22345cf65f315a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.226.66.239 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GEgwlLcKhcnCaQVEio9HifVeE7U Cc: TLS Mailing List Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 23:10:27 -0000 On 4/28/14 at 6:44 AM, rsalz@akamai.com (Salz, Rich) wrote: >It's not just out of vengeance, honest! But I think TLS=20 >heartbeat should be at least be deprecated in 1.3. I implemented a heartbeat function in the E language=20 communication protocol (which ran on top of TCP). Even the=20 abstraction level I implemented it at, it was too far away from=20 the application level to allow reasonable values for the=20 associated frequency and time out. IMNSHO, the details of the heartbeat function should be=20 specified very close to the application user. Only at that level=20 can rational decisions be made about how often to heartbeat and=20 with what timeout. My vote goes to eliminating it from TLS. I'l like to hear arguments on why it should continue to be in DTLS. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Privacy is dead, get over | Periwinkle (408)356-8506 | it. | 16345=20 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos,=20 CA 95032 From nobody Mon Apr 28 16:29: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 048581A0A0C for ; Mon, 28 Apr 2014 16:29:05 -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 BoWnloIFNbxS for ; Mon, 28 Apr 2014 16:29:03 -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 6EE491A6FB8 for ; Mon, 28 Apr 2014 16:29:03 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k14so4358061wgh.13 for ; Mon, 28 Apr 2014 16:29: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=2oz1GgtkoPDiLua2gz3mjumibRUVdun1JqPl9ReqhQU=; b=Yz0r6xo6oITkED+Aljvl8a8nQ49FUGVXa9aIpRV6EEVju5atS9YSZ4Db9jJ0SySsFO Q5cDwajEnZ1oEy0Fnf9ijNn7y1gB9S1mQwNX2QxGfPOe7UuKaXC4dUYVkHpd/W35FwBw 5fGkJwxbpQ6IYiWZzr6HfTBYfZPvc+W2/NOnSvolsw/R1OyUWLKzIQFd5kwcJogOIuQv eeL78qjAazQs5/mGQECQzj/KtuIoxObqq+3+QkDP1wudrvrDfZIMkL6tiKMieiMitU5B T/X7XWkD1V3G41W+Q8RwWxCrfMdGKep0hAdM4AoirJvdy/lFpaHI9x35lTUWRxfBQW0I kE/g== MIME-Version: 1.0 X-Received: by 10.194.57.77 with SMTP id g13mr11954066wjq.42.1398727742062; Mon, 28 Apr 2014 16:29:02 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Mon, 28 Apr 2014 16:29:01 -0700 (PDT) Received: by 10.194.243.101 with HTTP; Mon, 28 Apr 2014 16:29:01 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> Date: Tue, 29 Apr 2014 01:29:01 +0200 Message-ID: From: Richard Hartmann To: Bill Frantz Content-Type: multipart/alternative; boundary=047d7bacc0fa34046604f822ae5e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zjyPfRP3fGwoHCXtg0-TR2ai20c Cc: tls@ietf.org Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2014 23:29:05 -0000 --047d7bacc0fa34046604f822ae5e Content-Type: text/plain; charset=UTF-8 On Apr 29, 2014 1:10 AM, "Bill Frantz" wrote: > IMNSHO, the details of the heartbeat function should be specified very close to the application user. Only at that level can rational decisions be made about how often to heartbeat and with what timeout. Agreed. It feels very compressy and should be done higher up. > My vote goes to eliminating it from TLS. +1 Richard --047d7bacc0fa34046604f822ae5e Content-Type: text/html; charset=UTF-8

On Apr 29, 2014 1:10 AM, "Bill Frantz" <frantz@pwpconsult.com> wrote:

> IMNSHO, the details of the heartbeat function should be specified very close to the application user. Only at that level can rational decisions be made about how often to heartbeat and with what timeout.

Agreed. It feels very compressy and should be done higher up.

> My vote goes to eliminating it from TLS.

+1

Richard

--047d7bacc0fa34046604f822ae5e-- From nobody Mon Apr 28 16:57: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 D2B7B1A6F17 for ; Mon, 28 Apr 2014 16:57: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 ocR544tfaUqK for ; Mon, 28 Apr 2014 16:57:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F01A883C for ; Mon, 28 Apr 2014 16:57:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E6672AB09B; Mon, 28 Apr 2014 23:57:01 +0000 (UTC) Date: Mon, 28 Apr 2014 23:57:01 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140428235701.GL27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2qH0l7dULQMH1uAatRo1fThKkBQ Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 23:57:05 -0000 On Mon, Apr 28, 2014 at 04:10:09PM -0700, Bill Frantz wrote: > IMNSHO, the details of the heartbeat function should be specified very close > to the application user. Only at that level can rational decisions be made > about how often to heartbeat and with what timeout. > > My vote goes to eliminating it from TLS. Some applications don't have NOP messages. If one wants to detect remote disconnect without sending an application level message, or to keep connection state alive across a stateful firewall, a heartbeat can be useful, even over TCP. However, a heartbeat over TCP does not require any payload or response. It can be a record-layer message with a zero-length payload that elicits no response at all. This gets no cryptographic protection, but that just makes it cheaper and safer. Of course such a NULL heartbeat would be very different from the DTLS case and would have to be specified separately for TLS. -- Viktor. From nobody Mon Apr 28 18:37: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 D44E71A6FA9 for ; Mon, 28 Apr 2014 18:37:10 -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 0QSClcmo-VtV for ; Mon, 28 Apr 2014 18:37:09 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D4AF91A6FED for ; Mon, 28 Apr 2014 18:37:09 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 25B75584056 for ; Mon, 28 Apr 2014 18:37: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=gRH+C4d3p5nGTBP4maO/ o/Bw++o=; b=M3dBzlWxoZABH6bElwq89W7aVVsspX2QfPjWvq5X3XiqlVZ3Oamp 0N2BQ9foZiubKZUTMqvzytq1/sl4K/Tqxdi5lf7NMLRcsHMNaQoOXmtiFXfZjmbI ilqEiroYAwblPLcCSpbY8JIp0ACK0FLpt+jg0z8KZui1iSwtZiq+lcc= 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-a32.g.dreamhost.com (Postfix) with ESMTPSA id CEEF4584055 for ; Mon, 28 Apr 2014 18:37:08 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u57so3937487wes.13 for ; Mon, 28 Apr 2014 18:37:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr17806585wib.39.1398735427493; Mon, 28 Apr 2014 18:37:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 18:37:07 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> Date: Mon, 28 Apr 2014 20:37:07 -0500 Message-ID: From: Nico Williams To: Richard Hartmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AuRaNkcxwy0CeMwu8y4IFmJlhBw Cc: "tls@ietf.org" Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2014 01:37:11 -0000 On Mon, Apr 28, 2014 at 6:29 PM, Richard Hartmann wrote: > On Apr 29, 2014 1:10 AM, "Bill Frantz" wrote: > >> IMNSHO, the details of the heartbeat function should be specified very >> close to the application user. Only at that level can rational decisions be >> made about how often to heartbeat and with what timeout. > > Agreed. It feels very compressy and should be done higher up. That's definitely something to consider before rejecting the proposal to remove. My take is that "keepalive" may well belong at the application, but PMTUD doesn't. Or at the very least that PMTUD needs to be done in a reusable way or it won't get done at all if you punt it to the app layer. Removing PMTUD could damage the network. E.g., apps might resort to sending the smallest payload they can reliably get to work, which would increase overhead significantly. For high performance computing it would mean having to specify PMTU in configuration. Now, what information can leak from keepalives? What about PMTUD? Clearly one thing that leaks is that an otherwise-idle device is still online. Anything else? Nico -- From nobody Mon Apr 28 18:43: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 7D7DE1A8869 for ; Mon, 28 Apr 2014 18:43:01 -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 VJnUAcwSSdyI for ; Mon, 28 Apr 2014 18:43:00 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE21A8855 for ; Mon, 28 Apr 2014 18:43:00 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 7E1D794065 for ; Mon, 28 Apr 2014 18:42: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:content-type; s=cryptonector.com; bh=O7bu5c9ZYzqy5C0SdKa7dku YayQ=; b=HWme9BhM+hRGDRJCTOVcet6lpSlU8zqFSLRcW+I8qTNLIQlputO6knN b04SsvHCM90uYrZZ1A48F++hv/bE0mS8Zg3Sw/2Re69rlPtYewKWp+csorhiGXbo IZ2ATMwzBePtjM//tM8I7R5yaafS00akVb+e1kXVnEK37z2z/v90= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 2F18C9405E for ; Mon, 28 Apr 2014 18:42:59 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so2023007wgg.32 for ; Mon, 28 Apr 2014 18:42:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.5.6 with SMTP id ci6mr17851068wid.39.1398735778167; Mon, 28 Apr 2014 18:42:58 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Mon, 28 Apr 2014 18:42:58 -0700 (PDT) In-Reply-To: <20140428235701.GL27883@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F53E@USMBX1.msg.corp.akamai.com> <20140428235701.GL27883@mournblade.imrryr.org> Date: Mon, 28 Apr 2014 20:42: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/WzGDd_G4D-4ODP9nMu9Zb4IORYI Subject: Re: [TLS] Heartbeat and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2014 01:43:01 -0000 On Mon, Apr 28, 2014 at 6:57 PM, Viktor Dukhovni wrote: > On Mon, Apr 28, 2014 at 04:10:09PM -0700, Bill Frantz wrote: > However, a heartbeat over TCP does not require any payload or > response. It can be a record-layer message with a zero-length > payload that elicits no response at all. This gets no cryptographic > protection, but that just makes it cheaper and safer. Arguably even a TCP application with keepalives might want to keep PMTUD going on idle connections (sending large keepalives from time to time to keep the PMTUD info fresh) so that when they get busy they go fast, but that might be significantly wasteful unless also coupled with an exponential idle backoff. But, sure, as to TCP I think we can remove the variable-length payload heartbeat. I'm somewhat concerned by having too many special case differences between DTLS and TLS though. We've already seen a mistake that meant that DTLS Hellos cannot carry extensions. Nico -- From nobody Tue Apr 29 01:45:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B511A08B2 for ; Tue, 29 Apr 2014 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q5oWAn6BhE9 for ; Tue, 29 Apr 2014 01:45:11 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE371A0775 for ; Tue, 29 Apr 2014 01:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1398761108; bh=YrvZbEPiUrJL27N0RB1eSw6IgbA8DB++AJqvKzo2kSU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JXAXiCadQ5KthK3MzHuT9gSMt+YOKhs+h4I0mXMTyrTdwefs2xdY/G7I6HmFD7xGT 3XY3qCIT/SG6oywKJRLKq/Z7abdEoRq4BJviHamiJqk79eWjniUUT0pzThKFjBU37o Ha2RWQVMhHWRhQxY8tOPoocWjer1s4+gS16G10m8= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (h2072314.stratoserver.net [81.169.151.138]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 6F18E67 for ; Tue, 29 Apr 2014 10:44:58 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 6F18E67 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: <535F6684.1040701@azet.sk> Date: Tue, 29 Apr 2014 10:44:52 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> In-Reply-To: <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.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/GpNVbugO-ZAI0MS_RcP36Lvcqow Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 08:45:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. What is the mandatory cipher in TLS 1.3 ? Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for ECDHE ? Fedor On 26.04.2014 17:24, Joseph Salowey (jsalowey) wrote: > The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github. > > Joe > [For the chairs] > On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: > >> TLS has supported a number of different cipher types for protecting the record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher. The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier. AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms. The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. >> >> Thanks, >> >> Joe >> [Speaking for the TLS chairs] >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTX2aEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtV7oP+wbNgDRmqa7UJ5D+8dM72sYX bQqK4slhy26evi23EmzWrfWI5pNPcceB4c7tUegZJQ3ZvGXIVRW7Sov79djar6uD MPABZWBry/qCN6PvdoUhSNFvokJzUSK/bm+oLCnyEts5WM0CGOTnITJ99i3QSvjW nzYfQkZCBD/vou4QGNNQfG9JzRU1A7o2stvFk0g+VK3a7ppjRyuHVTMo+vjsr8tl RSex8O0QYcpt+gvmOIU5fcgSB+3Es5VYJhU70EL+kArejCldDcvy3wkd6Er11wy7 wphKORvK2hvrqT2rVIWDwwouQqdxvgydzuQSSQr+VO1kM7Cs0CY9YWZUmuWcsH5I FVXQrnDZa3nN26dzcaYKX2M6Qfst0MVS4gEyka4jON0VfPeiabAVSXEMaMHJIEXd nhYc4iRcJGLlrFLPc3TkHlBj34nAYeRzr8kvoLw2MeXEws32qwH/BAgCv9kyQ3SL zfxuv5kKu6GRakHcZejK2dDwH0y+OBDLUghegRdfyrjs/Tx8wJ2bPpRRwWWIgHeA pvUSDZv+0E2iRO1Vd+Gpgw0mYF7J22nlRtm3ehGATsXWzqK+3LzWzHs9h/E+80sN p0kNWsnSUdfanR6X9OysPQLDnNZ905o/d2XbkAYlYZu+fJ4lUGy4Oa2ivh08yF+i X1KBUXBRSpfC6U6sw0Xf =2As+ -----END PGP SIGNATURE----- From nobody Tue Apr 29 07:58: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 D1FA41A0923 for ; Tue, 29 Apr 2014 07:58:18 -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 9CeJfQzUMrvx for ; Tue, 29 Apr 2014 07:58:16 -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 EB6021A0922 for ; Tue, 29 Apr 2014 07:58:15 -0700 (PDT) Received: (qmail 13065 invoked by uid 1000); 29 Apr 2014 14:58:09 -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; Tue, 29 Apr 2014 15:58:09 +0100 Message-ID: <535FBE01.80501@comodo.com> Date: Tue, 29 Apr 2014 15:58:09 +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: Russ Housley , Phillip Hallam-Baker References: <535E353A.9030008@comodo.com> <48E70918-765E-4EAE-8FE0-DCC038C61314@vigilsec.com> In-Reply-To: <48E70918-765E-4EAE-8FE0-DCC038C61314@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xxEP5n9CIos5Zke0ej6qbbBjWRc Cc: Klemens Baum , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 14:58:19 -0000 On 28/04/14 15:13, Russ Housley wrote: > Rob: > >> An OID allocation request was submitted well over a year ago. The reason for the delay is that following the shutdown of the PKIX WG, control of the PKIX OID registry is being transferred to IANA. IINM, the transfer is still not yet complete. > > The IESG has assigned me as the expert for this IANA registry. If the document is ready for approval, we can work the review in parallel. Thanks Russ. BTW, Phill posted this a few weeks ago: http://article.gmane.org/gmane.comp.mozilla.devel.security.policy/491 Phill, can we progress this now? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Apr 29 08:56: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 2D0F81A090A for ; Tue, 29 Apr 2014 08:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIpeOn7QWDGF for ; Tue, 29 Apr 2014 08:55:57 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id EC8411A08DB for ; Tue, 29 Apr 2014 08:55:56 -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=1398786956; x=1430322956; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bBy7gJR9C0RciUhEeUY5eI/BNde0i8GAzlzJ0UOAkmE=; b=OLO2ufuiVTHy/3tZ50L4n09HABGJHX6WtTWkspIA0GslmT5b8dDx4y4J 8WgeoMIu4fbhTxsJ6mOBfVIgxs4N3WCXC5fBPVoVguQ3rendPE+FmixFp 93ofrlngnRqhl+WDGVp928g6nzsIaAfkoTKYd8Ll3OwzQTne0843j0Y+5 g=; X-IronPort-AV: E=Sophos;i="4.97,951,1389697200"; d="scan'208";a="249373904" 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; 30 Apr 2014 03:55:55 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.225]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 03:55:54 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Confirming Consensus on supporting only AEAD ciphers Thread-Index: Ac9jw4B82N4QNQZ+TAK0cXf/4WEl0g== Date: Tue, 29 Apr 2014 15:55:54 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@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/YZIAqCQy4rSHNtqkt3g9Q4QoQdY Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:56:03 -0000 Fedor Brunner writes:=0A= =0A= >The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. W= hat=0A= >is the mandatory cipher in TLS 1.3 ? Maybe=0A= >TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for ECDHE ?= =0A= =0A= Ugh, no. That takes the ciphers from +=0A= + to +++. Make the defaults something that can be= =0A= implemented with a standard crypto library, and leave the oddball stuff as= =0A= optional fashion statements.=0A= =0A= (No disrespect intended for the algorithms I've designated as "oddball", bu= t I=0A= want something where the default is built from standard, accepted, widely-= =0A= recognised algorithms so I don't have to explain to every customer what=0A= ChaCha20 is and why it's being used to protect their banking transactions).= =0A= =0A= Peter.= From nobody Tue Apr 29 09:26: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 5772C1A08DB for ; Tue, 29 Apr 2014 09:26: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 NkI81kUkJ6kX for ; Tue, 29 Apr 2014 09:26:24 -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 1D9711A090A for ; Tue, 29 Apr 2014 09:26:24 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 131so391303ykp.32 for ; Tue, 29 Apr 2014 09:26: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=c17zWrox/gwpC2fo55S6MCiUpMTQURsnMVkokvp28KU=; b=WeYSSfJVLD4/49nlO2qWQPh3qLdUYk7fUNAwVcdvp0Sk+BYjrMU43VOnITrpLutGrA ndhwrl45I+BCspar9iNo5OPw2O6jD1yhpma5Opz48KIg9MiYWW3NDJBB3Her7cQMI7Pw vhNFD7cYAEuXkOP1YoXosk1z7+3kZ031hu07R+1OB0P++B6uDrERoFx2TVxJ5CjzPCE6 njcsCsFID21rHn93BlvwyxKe+SV5XI69BB5g+3ITVW9l56Z903CkdqZ7wR6jwRr5hLB6 KYwwPNiUSYGFDoWtphIEdtVF935MAvLiyTE1vUj22DMI+WKe5ayAC2piT09bfZfoTGkE 4aJw== MIME-Version: 1.0 X-Received: by 10.236.137.8 with SMTP id x8mr47251813yhi.4.1398788782854; Tue, 29 Apr 2014 09:26:22 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 29 Apr 2014 09:26:22 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Tue, 29 Apr 2014 09:26:22 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ErHczsAR96F0AoExv2jum18CLC4 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: Tue, 29 Apr 2014 16:26:26 -0000 On Tue, Apr 29, 2014 at 8:55 AM, Peter Gutmann wrote: > Fedor Brunner writes: > >>The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. What >>is the mandatory cipher in TLS 1.3 ? Maybe >>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for ECDHE ? > > Ugh, no. That takes the ciphers from + > + to ++ nonstandard>+. Make the defaults something that can be > implemented with a standard crypto library, and leave the oddball stuff as > optional fashion statements. > > (No disrespect intended for the algorithms I've designated as "oddball", but I > want something where the default is built from standard, accepted, widely- > recognised algorithms so I don't have to explain to every customer what > ChaCha20 is and why it's being used to protect their banking transactions). Well, Vanguard uses RC4. That said I think TLS_ECDHE_RSA_AES_GCM_SHA256 with P256 as ECDHE is implemented widely, and pretty secure. Yes, there is a performance gain from Curve25519, but that's not necessary. Sincerely, Watson Ladd > > Peter. > _______________________________________________ > 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 Apr 29 09:27: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 BD01C1A08FB for ; Tue, 29 Apr 2014 09:27: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 uD5myUAISpRT for ; Tue, 29 Apr 2014 09:27:12 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 87B171A08F0 for ; Tue, 29 Apr 2014 09:27:12 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id fa1so494850pad.20 for ; Tue, 29 Apr 2014 09:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JBpshLJ3OOX/WSFqwmrfAT6YA/IRLXmTqr1aa7O2iNw=; b=ql7xS/XBvA/wlEvZZUWyVwEbV7f/V2HSfozff/ftBTTd/pKcuIo9YJAOa8ymhk3A5x rRunXzjpZRfip3OKf8b8KV6azIo6x4IezyX7xNB8Z7Cea5edephdnzwhevCVFleJWnFj 1FakE2IoanuGU43PjQTp2fEVT4/l57w5MisIbNrntPcy2VsRqrDMMavxWrUZDCTQK9Li p66vu0g1B4Rnb6d4tKn4ntj+AKK8auCXNTPKyffYNs+oh/0MmdsVASteK82Vod6ToHSH DKNHb3KXXovdJUJ+k0mrjUqAcrorYQoAgDdVz+M+lsgByRWv0xBopnZavqXqittvFR9s n6OQ== MIME-Version: 1.0 X-Received: by 10.66.254.198 with SMTP id ak6mr511427pad.156.1398788828819; Tue, 29 Apr 2014 09:27:08 -0700 (PDT) Received: by 10.70.131.16 with HTTP; Tue, 29 Apr 2014 09:27:08 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Tue, 29 Apr 2014 09:27:08 -0700 Message-ID: From: Peter Bowen To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mAeVH6Mol0337rd6gWXNx96oQPg 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: Tue, 29 Apr 2014 16:27:13 -0000 On Tue, Apr 29, 2014 at 8:55 AM, Peter Gutmann wrote: > Fedor Brunner writes: > >>The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. What >>is the mandatory cipher in TLS 1.3 ? Maybe >>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for ECDHE ? > > Ugh, no. That takes the ciphers from + > + to ++ nonstandard>+. Make the defaults something that can be > implemented with a standard crypto library, and leave the oddball stuff as > optional fashion statements. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the secp256r1 curve is probably the best option from the existing registries. If there is a desire to avoid EC (and therefore avoid bringing in more extensions, then TLS_RSA_WITH_AES_128_GCM_SHA256 is the next best choice from the existing registries. Thanks, Peter From nobody Tue Apr 29 09:52: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 63E141A0776 for ; Tue, 29 Apr 2014 09:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3opNo3W6v2g6 for ; Tue, 29 Apr 2014 09:52:03 -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 428A31A07A0 for ; Tue, 29 Apr 2014 09:52:03 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7679CFF75 for ; Tue, 29 Apr 2014 12:52:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=NhFn2UKimMIQ ykH4Ksmp+3RhEnw=; b=crYUbn/FEjS2qxSrCi1lLNRJCLVwxym6Uh+tKdYPOwH9 mGTjdafpzsUuqJ/WHby4gf7P7EMQTJurOTB69uV1uuIrAGVBX6bvMUIOWuHIXwH9 VgM/O7N3lshvDvV9+hz0pYa1euAnuOzmYoWRAcGLbB/jWsGZoEuZMmYpTJPNGWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=d8tqmP t7vYRuEogeNwwoA0fe2B7OMpFWv+d+S5s/x43rzyE+lfdCf48/QBmeS2Pr5jyvXX WgtFNDGnqb5+yQ6/QLCl/oeDhJAgDhiEBNuMsX5U3hGLjRB4S4rlUWa1qnnvcbZu XXsIVVV33fDANbF4SpWq00EDEO52RVR/xwN2o= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6A1E9FF74 for ; Tue, 29 Apr 2014 12:52:01 -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 30E4CFF73 for ; Tue, 29 Apr 2014 12:51:59 -0400 (EDT) Message-ID: <535FD8AE.6050007@pobox.com> Date: Tue, 29 Apr 2014 09:51:58 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9477DD8E-CFBE-11E3-934B-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xzQ4umw0cwA39cDR3jgO9TmH6Rc Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:52:05 -0000 >>> What is the mandatory cipher in TLS 1.3 ? I suggest none. There are too many to choose from and nobody will listen anyway. Or maybe a better answer would be to provide a suggestion for each of the major key-exchange methods: C02B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 C02F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 00A2 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 009C TLS_RSA_WITH_AES_128_GCM_SHA256 Mike From nobody Tue Apr 29 10:01: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 B2AD41A04B6 for ; Tue, 29 Apr 2014 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHSbLlPof0Je for ; Tue, 29 Apr 2014 10:01:39 -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 58E881A091D for ; Tue, 29 Apr 2014 10:01:37 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi5so837261wib.0 for ; Tue, 29 Apr 2014 10:01:35 -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=ESGeu1mb2zqFnik1zze7qLZ/n79MARiP62HeTAa+eDw=; b=pyPzQjixs0NTS4pjYSC/7UrHiUkRxBUlXRx8pi5hxGvHdUE7ekTH98e2T8p80S/xlt 2ammKy4nWtiu+NRp63H/LD1woyZ2U+sVkjlQ+lZEylGzNbFFpzWuzGS3LRLyqLqYgIH2 T/RfUeuwUl/CbqB+j9IghYQoq4/g4oyUIMt5FKXAr7c5l9whTbN5BHB/Xf/p311OQrG5 cA0CPywCCtznS+yXAm5CP0SNJNGtZTAufG2iRfSYltoVhmv2nDHP25+inVDUWXmRl9H/ JEzGLj36CViWLY73Xqs6VhFuZVgOOfV3WqXZjaPsbnyetjLUu7WVbie+A/Ouk29DEV3a b9kw== MIME-Version: 1.0 X-Received: by 10.180.189.65 with SMTP id gg1mr21484153wic.56.1398790894743; Tue, 29 Apr 2014 10:01:34 -0700 (PDT) Received: by 10.227.77.138 with HTTP; Tue, 29 Apr 2014 10:01:34 -0700 (PDT) In-Reply-To: <535FD8AE.6050007@pobox.com> References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> <535FD8AE.6050007@pobox.com> Date: Tue, 29 Apr 2014 10:01:34 -0700 Message-ID: From: Martin Thomson To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BJp57zbN8EaQ1W0AjZt0Iz__BCw Cc: TLS Mailing List Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:01:41 -0000 On 29 April 2014 09:51, Michael D'Errico wrote: > I suggest none. There are too many to choose from and nobody will > listen anyway. That's a recipe for interoperability failure. > 009C TLS_RSA_WITH_AES_128_GCM_SHA256 I think that we have consensus not to do this particular one. From nobody Tue Apr 29 10:25: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 A2F751A07A6 for ; Tue, 29 Apr 2014 10:25:33 -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 kYbaVJMSbXWC for ; Tue, 29 Apr 2014 10:25:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A07D91A085A for ; Tue, 29 Apr 2014 10:25:31 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3THPRUC002060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Apr 2014 19:25:27 +0200 (MEST) In-Reply-To: <277ABA2E-FA8C-4927-9522-06E8907C28EB@cisco.com> To: "Joseph Salowey (jsalowey)" Date: Tue, 29 Apr 2014 19:25:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140429172526.EC5211ACE8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0jcUj3lnhc5aEL4e7C_s2PxqXHI 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 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, 29 Apr 2014 17:25:33 -0000 Joseph Salowey (jsalowey) wrote: > > The discussion on this list and others supports the consensus in IETF 89 > to remove RSA key transport cipher suites from TLS 1.3. You probably meant TLS cipher suites with the (static) RSA key exchange method. > > More discussion is needed on both DH and ECDH are used going forward > and on if standard DHE parameters will be specified. (static) DH/ECDH key exchange needs to be addressed seperately from (ephemeral) DHE/ECDHE key exchange. Is there any deployment of Server certificates with static DH/ECDH at all? Is it at all possible to build a regular PKCS#10 certification request (i.e. one with a proof-of-posession signature) for static DH/ECDH keys in server certificates? Personally, I don't think it is reasonable to completely remove from TLSv1.3 *ALL* of the stuff that will be necessary for interop with the installed base. There also exist small devices with weak random number generators that could be used with an offline generated RSA server keypair. I don't see any value in _not_ supporting static RSA for these. With a preloaded strong (EC)DHE keypair, they're worse off that with a static RSA key (slower and no forward secrecy), and they have difficulties generating strong ephemeral keys on their own. The additional code footprint of ECC and the overall brittleness of ECC crypto is another concern. Currently, ECC is a mere option, and a very dangerous one due to the overall brittleness of ECC, even for implementations of TLSv1.2 -Martin From nobody Tue Apr 29 10: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 949D71A085A for ; Tue, 29 Apr 2014 10:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMz3ZQdX7Uea for ; Tue, 29 Apr 2014 10:32:04 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 80AC91A04AF for ; Tue, 29 Apr 2014 10:32:04 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 2DEC080A11; Tue, 29 Apr 2014 19:32:02 +0200 (CEST) Received: from [192.168.178.23] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 264D080A06 for ; Tue, 29 Apr 2014 19:32:01 +0200 (CEST) Message-ID: <535FE210.40909@net.in.tum.de> Date: Tue, 29 Apr 2014 19:32:00 +0200 From: Ralph Holz 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: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535F6684.1040701@azet.sk> In-Reply-To: <535F6684.1040701@azet.sk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BnUZWD--149btwu3TsMNJjCiahY Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:32:08 -0000 Hi, On 04/29/2014 10:44 AM, Fedor Brunner wrote: > The Mandatory Cipher Suite for TLS 1.2 was > TLS_RSA_WITH_AES_128_CBC_SHA. What is the mandatory cipher in TLS > 1.3 ? > > Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 > for ECDHE ? For current TLS 1.2, the UTA BCP [1] suggests TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. It also asks for TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to be supported by implementations. It might be nice to keep the BCP in line with TLS 1.3 suggestions. As for the symmetric ciphers... I acknowledge there is resistance against GCM due to sidechannel issues, but really, with the current combination of encryption and MACs, I see no alternative there bar the new stream ciphers. Maybe it's time Peter's draft is finally moved forward - although I still object to the use of extensions to indicate encrypt-then-mac. (Part of my reasoning is that using extensions complicates the protocol, which leads to more complexity in implementations) Ralph [1] http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/?include_text=1 [2] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05 > > Fedor > > On 26.04.2014 17:24, Joseph Salowey (jsalowey) wrote: >> The consensus from the IETF-89 meeting holds, TLS 1.3 will only >> use record layer protection of type > AEAD. The Editor is requested to make the appropriate changes to > the draft on github. > >> Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey >> (jsalowey) > wrote: > >>> TLS has supported a number of different cipher types for >>> protecting > the record layer. In TLS 1.3 these include Stream Cipher, CBC > Block Cipher and AEAD Cipher. The construction of the CBC mode > within TLS has been shown to be flawed and stream ciphers are not > generally applicable to DTLS. Using a single mechanism for > cryptographic transforms would make security analysis easier. > AEAD ciphers can be constructed from stream ciphers and block > ciphers and are defined as protocol independent transforms. The > consensus in the room at IETF-89 was to only support AEAD ciphers > in TLS 1.3. If you have concerns about this decision please respond > on the TLS list by April 11, 2014. >>> >>> Thanks, >>> >>> Joe [Speaking for the TLS chairs] >>> _______________________________________________ TLS mailing >>> list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Tue Apr 29 10:33: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 064341A0905 for ; Tue, 29 Apr 2014 10:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsSuTNOvdqQK for ; Tue, 29 Apr 2014 10:33:46 -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 8F0531A08DB for ; Tue, 29 Apr 2014 10:33:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E7FAB10254 for ; Tue, 29 Apr 2014 13:33:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=nZMnXAUZUmGQ FNxm5ldlP4x/Z/0=; b=Fv2mltAyGUalQYxWyiLg7yqty5DTMRkWKAkz0/Xz2bxN icsLuVrajbQWFJUgZJ/mhpWYauShTTqDNAc6aSD+Oqbu5x1RQUCHpvw+OG+smXiU e2sici3Yt7C+21awyL5LafUKHCz8YL++fskJGs6GxGh7V3iSpVrmHAtcqZ/lQeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=WpqMXX 2a7aQFbGESsU108WOEfgYBwgEFIrsP71uYMrUF+Q+t6SIqh7LLX7pGyDx8K4e/Rp sLdxSqLaBZcnCf5bG5dYBAdICqo8VUYfaAxmyxdYDlpND4tiEmDOfftGJb3v+psT 717BSa6xIDVb1wcuSXxg1sPJNHCZuPr1iS/L4= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DF4B210253 for ; Tue, 29 Apr 2014 13:33:44 -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 D801A10252 for ; Tue, 29 Apr 2014 13:33:42 -0400 (EDT) Message-ID: <535FE275.6090701@pobox.com> Date: Tue, 29 Apr 2014 10:33:41 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> <535FD8AE.6050007@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 68C948F2-CFC4-11E3-8475-6F330E5B5709-38729857!a-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Dl8HicOFr00_nO9MPPUJwCSOhXA Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:33:49 -0000 Martin Thomson wrote: >> I suggest [not naming a mandatory-to-implement cipher suite in the >> TLS 1.3 spec.]. There are too many [cipher suites] to choose from >> and nobody will listen anyway. > > That's a recipe for interoperability failure. I'm suggesting that the TLS 1.3 spec. is not the place for this piece of information since it is a moving target: TLS 1.0 required TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. TLS 1.1 required TLS_RSA_WITH_3DES_EDE_CBC_SHA. TLS 1.2 required TLS_RSA_WITH_AES_128_CBC_SHA Current consensus says none of those previously-mandatory ciphers will even be compatible with TLS 1.3. A Best Current Practice document like draft-sheffer-tls-bcp-02 that tracks best practices is more useful than having the TLS spec. become obsolete soon after it's published. BTW that draft suggests these cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Mike From nobody Tue Apr 29 10:37: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 476B91A0920 for ; Tue, 29 Apr 2014 10:37:45 -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 Z2ZPf4EoU-_0 for ; Tue, 29 Apr 2014 10:37:43 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id DD0E31A08DB for ; Tue, 29 Apr 2014 10:37:42 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q58so560340wes.12 for ; Tue, 29 Apr 2014 10:37: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=PFoR38qipQgZApBXpHagUEcdqbHRnItiwHBJGLAHNjQ=; b=ZloXQsjtxRyeqZkrVIRq/ofJfdxLy1GgW0z4ryIzhhVtEwCyTYhTPYoJSlH99WUlww TEEKrQy0ygNp4+3D9m3uZtfZvc4Lw7gCFntXJfMfr/uI0DB33t9UlJeSxhMLlmBmI8D9 2qQbxLELzQkhUiH7ArxE1hnsS5Dywy1gDoRukZZ7EPjtgQfkjhzVb//SQ0vP/0T+zuta gSvpTmmAT27OWOSsmVLzj3xmls9yKajlD1p3feocxYeb+N8IDb9I+G6e4bAlnykB/0nF fjvypWjYQjf7mNPYkm48SO2MBWTJCLODZ2CjgjpZWhVJxi3pAuVwZShshJsZqvyO89+F XiBw== X-Gm-Message-State: ALoCoQkSNcnetqcYEl1XSC+Q7zlGEvRl8TUGVKTiS/Hc2fJXhaHc0OPk8bnMAwHGnxHmkUYzNZEx X-Received: by 10.180.13.209 with SMTP id j17mr1614816wic.18.1398793061238; Tue, 29 Apr 2014 10:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.218.198 with HTTP; Tue, 29 Apr 2014 10:37:00 -0700 (PDT) X-Originating-IP: [63.245.219.54] In-Reply-To: <535FE210.40909@net.in.tum.de> References: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> <535F6684.1040701@azet.sk> <535FE210.40909@net.in.tum.de> From: Eric Rescorla Date: Tue, 29 Apr 2014 10:37:00 -0700 Message-ID: To: Ralph Holz Content-Type: multipart/alternative; boundary=001a11c2412e87a5d604f831e31a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tUDFI0mLY0mWeiPOEwqrLbIeNt0 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:37:45 -0000 --001a11c2412e87a5d604f831e31a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2014 at 10:32 AM, Ralph Holz wrote: > Hi, > > On 04/29/2014 10:44 AM, Fedor Brunner wrote: > > > The Mandatory Cipher Suite for TLS 1.2 was > > TLS_RSA_WITH_AES_128_CBC_SHA. What is the mandatory cipher in TLS > > 1.3 ? > > > > Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 > > for ECDHE ? > > For current TLS 1.2, the UTA BCP [1] suggests > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. It also asks for > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to be supported by implementations. > > It might be nice to keep the BCP in line with TLS 1.3 suggestions. > > As for the symmetric ciphers... I acknowledge there is resistance > against GCM due to sidechannel issues, but really, with the current > combination of encryption and MACs, I see no alternative there bar the > new stream ciphers. > Another alternative would be AES-CTR + HMAC.... > Maybe it's time Peter's draft is finally moved forward - although I > still object to the use of extensions to indicate encrypt-then-mac. > The WGLC for this ended Monday. I would expect Peter to produce a new draft relatively soon and then we should be able to send it to the IESG. -Ekr > (Part of my reasoning is that using extensions complicates the > protocol, which leads to more complexity in implementations) > > Ralph > > [1] http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/?include_text= =3D1 > > [2] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05 > > > > > Fedor > > > > On 26.04.2014 17:24, Joseph Salowey (jsalowey) wrote: > >> The consensus from the IETF-89 meeting holds, TLS 1.3 will only > >> use record layer protection of type > > AEAD. The Editor is requested to make the appropriate changes to > > the draft on github. > > > >> Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey > >> (jsalowey) > > wrote: > > > >>> TLS has supported a number of different cipher types for > >>> protecting > > the record layer. In TLS 1.3 these include Stream Cipher, CBC > > Block Cipher and AEAD Cipher. The construction of the CBC mode > > within TLS has been shown to be flawed and stream ciphers are not > > generally applicable to DTLS. Using a single mechanism for > > cryptographic transforms would make security analysis easier. > > AEAD ciphers can be constructed from stream ciphers and block > > ciphers and are defined as protocol independent transforms. The > > consensus in the room at IETF-89 was to only support AEAD ciphers > > in TLS 1.3. If you have concerns about this decision please respond > > on the TLS list by April 11, 2014. > >>> > >>> Thanks, > >>> > >>> Joe [Speaking for the TLS chairs] > >>> _______________________________________________ TLS mailing > >>> list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > >> _______________________________________________ TLS mailing list > >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > > > > > _______________________________________________ TLS mailing list > > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > -- > Ralph Holz > I8 - Network Architectures and Services > Technische Universit=C3=A4t M=C3=BCnchen > http://www.net.in.tum.de/de/mitarbeiter/holz/ > Phone +49.89.289.18043 > PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c2412e87a5d604f831e31a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 29, 2014 at 10:32 AM, Ralph Holz <= holz@net.in.tum.de<= /a>> wrote:
Hi,

On 04/29/2014 10:44 AM, Fedor Brunner wrote:

> The Mandatory Cipher Suite for TLS 1.2 was
> TLS_RSA_WITH_AES_128_CBC_SHA. What is the mandatory cipher in TL= S
> 1.3 ?
>
> Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 usin= g Curve25519
> for ECDHE ?

For current TLS 1.2, the UTA BCP [1] suggests
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. It also asks for
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to be supported by implementations.
It might be nice to keep the BCP in line with TLS 1.3 suggestions.

As for the symmetric ciphers... I acknowledge there is resistance
against GCM due to sidechannel issues, but really, with the current
combination of encryption and MACs, I see no alternative there bar the
new stream ciphers.

Another alternative= would be AES-CTR + HMAC....

=C2=A0
Maybe it's time Peter's draft is finally moved forward - although I=
still object to the use of extensions to indicate encrypt-then-mac.

The WGLC for this ended Monday. I would expect= Peter to produce a new
draft relatively soon and then we should = be able to send it to the IESG.

-Ekr
=C2=A0
(Part of my reasoning is that using extensions complicates the
protocol, which leads to more complexity in implementations)

Ralph

[1] http://datatracker.ietf.org/doc/draft-ietf-= uta-tls-bcp/?include_text=3D1

[2] http://tools.ietf.org/html/draft-gutmann-tls-encryp= t-then-mac-05

>
> Fedor
>
> On 26.04.2014 1= 7:24, Joseph Salowey (jsalowey) wrote:
>> The consensus from the IETF-89 meeting holds, TLS 1.3 will only >> use record layer protection of type
> AEAD. The Editor is requested to make the appropriate changes to
> the draft on github.
>
>> Joe [For the chairs] On Mar 26, 2014, at 11:43 AM, Joseph Salowey<= br> >> (jsalowey)
> <jsalowey@cisco.com> w= rote:
>
>>> TLS has supported a number of different cipher types for
>>> protecting
> the record layer. =C2=A0 In TLS 1.3 these include Stream Cipher, CBC > Block Cipher and AEAD Cipher. =C2=A0The 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. =C2=A0The<= br> > consensus in the room at IETF-89 was to only support AEAD ciphers
> in TLS 1.3. If you have concerns about this decision please respond > on the TLS list by April 11, 2014.
>>>
>>> Thanks,
>>>
>>> Joe [Speaking for the TLS chairs]
>>> _______________________________________________ TLS mailing >>> list TLS@ietf.org https://ww= w.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/mai= lman/listinfo/tls
>

--
Ralph Holz
I8 - Network Architectures and Services
Technische Universit=C3=A4t M=C3=BCnchen
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289= .18043
PGP: A805 D19C E23E 6BBB E0C4 =C2=A086DC 520E 0C83 69B0 03EF

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

--001a11c2412e87a5d604f831e31a-- From nobody Tue Apr 29 10: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 84CE21A0933 for ; Tue, 29 Apr 2014 10:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q04a5XtZrf8j for ; Tue, 29 Apr 2014 10:46:02 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 413C01A0927 for ; Tue, 29 Apr 2014 10:46:02 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so616318qge.4 for ; Tue, 29 Apr 2014 10:46: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=5pVD/sSAN2FXrVtrojZVlThVqI6Df+EPHatnj+m3fnQ=; b=QdYZdvMyJAiKNQ5dTULUereL0wcneXBWMz9rpqwpvA2WpOdOsSiq4S8fKp4+obXQIv t0mDrez5ltxxjNkjFz9HlVePBFDP48nMC+UlTnLw1zxsqbcY6GZ6qLeazX1X6TKSwpX0 kCosC20k9vz/E83uU/xETJi+qPte8Aw932Ka86vnBvJVLAhoerZqCDF9EO+rolt6yJ2c Fvq9mPf+lpjf2NM2UPRFFc3uUqmiGH2jakZpsPnIKzO27m9E0VI7gnZyfEXGaPk2kBB5 qcgY55VBDiHvORFiOpj/A53uBkTyzL2a0GenKBh5Vbg40Jj8WeP8sXJCXMehCvcyVsS+ EEbw== X-Gm-Message-State: ALoCoQkHxmuF/OIoFWeruX0z8PdGQTdymcHfzDdE977OhoUUFY/kMgu8w5zmgx89KGuQiM30AEKk X-Received: by 10.229.214.74 with SMTP id gz10mr1114193qcb.19.1398793560718; Tue, 29 Apr 2014 10:46:00 -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 o16sm4735496qax.23.2014.04.29.10.45.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 10:45:59 -0700 (PDT) Message-ID: <535FE558.2090306@nthpermutation.com> Date: Tue, 29 Apr 2014 13:46:00 -0400 From: Michael StJohns 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: <86E69268-DC0A-43E7-8CF5-0DAE39FD4FD5@cisco.com> <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> In-Reply-To: <84C4848E-7843-4372-93AA-C1F017C3E088@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iVJtHdVYOeBpQFI_R4DRdtG8IF0 Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:46:07 -0000 On 4/26/2014 11:24 AM, Joseph Salowey (jsalowey) wrote: > The consensus from the IETF-89 meeting holds, TLS 1.3 will only use record layer protection of type AEAD. The Editor is requested to make the appropriate changes to the draft on github. Sorry - I'm coming late here. Does this also imply the complete elimination of the integrity only cipher suites? With respect to the AEAD approach and with respect to composited AEAD cipher suites (e.g. AES_CBC_CMAC reformed as an AEAD cipher per Guttman for example), does this also imply that the key expansion phase will never be used to generate MAC keys, and that the cipher suite has to provide whatever mechanisms that are required to split the AEAD key into underlying encryption/integrity keys if required? Next (reading from the commited editors copy), this refers to 5116 which uses a one-size fits all approach that doesn't really fit all sizes, especially for composited AEAD. E.g. the draft describes this generally as an incrementing value. For AEAD suites that comply with 5116, that should be part of the suite specification - not TLS. For TLS, this just needs to be an normatively opaque, per-message field. Instead, place an Informative section which recommends how to do this with AEAD suites that currently exist. And finally, as I've noted many times before, deriving IV/nonce material from the master_secret at the same time as deriving keys is not securely supportable in hardware. > > Joe > [For the chairs] > On Mar 26, 2014, at 11:43 AM, Joseph Salowey (jsalowey) wrote: > >> TLS has supported a number of different cipher types for protecting the record layer. In TLS 1.3 these include Stream Cipher, CBC Block Cipher and AEAD Cipher. The construction of the CBC mode within TLS has been shown to be flawed and stream ciphers are not generally applicable to DTLS. Using a single mechanism for cryptographic transforms would make security analysis easier. AEAD ciphers can be constructed from stream ciphers and block ciphers and are defined as protocol independent transforms. The consensus in the room at IETF-89 was to only support AEAD ciphers in TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014. >> >> Thanks, >> >> Joe >> [Speaking for the TLS chairs] >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 29 11:18: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 C1A351A0949 for ; Tue, 29 Apr 2014 11:18:29 -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 JQgPYPLVrem8 for ; Tue, 29 Apr 2014 11:18:28 -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 80C0D1A06D7 for ; Tue, 29 Apr 2014 11:18:28 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id w7so691022qcr.11 for ; Tue, 29 Apr 2014 11:18:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nd7ffwxixktIJpVyW51ZZDztRnkb/MTR1fgtxmdjHng=; b=GW71UNB9Kw1GguvkWkbCcf8cPIwAU19ymHMA4nD+QgkQpk/r1BOPodpxM9Mu7X4oQ6 vCH+CsXpObyLK7a1R67biRTx2wjTketyOoZ6dh+vwNfAB8NxiWhYmdC4wLzVBZ4AI3xS Jw8BhN+DRn15Tlvkm2DGl6YWsc+ZutdMjZKgJIXY/hZXOt7qUQ6T6Y0r9mgBVPSZdpgC 5f2nn9Umk0kFrit2UEt1o0Z9PFT+gnoFp2HNfmOzMnUGeokqgySwnACm6CYzngoBLhjg anxENcdReAdpPo4Jr05DIqlHM9yFcPydlYgCT1WSllfG5m5JIavHKegl20rJNM/KlwsW nSCw== X-Gm-Message-State: ALoCoQlY2urpH3sY3fbXzBGJ4iOhwTtidiRP0JLHCvdXdWXvzabjYvJACOUK7dhnq79HCU5w9BC9 X-Received: by 10.224.97.69 with SMTP id k5mr44817705qan.8.1398795506813; Tue, 29 Apr 2014 11:18:26 -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 d110sm8392261qge.17.2014.04.29.11.18.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 11:18:26 -0700 (PDT) Message-ID: <535FECF0.8070905@nthpermutation.com> Date: Tue, 29 Apr 2014 14:18:24 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Watson Ladd References: <5350BF46.7000608@pobox.com> <53513A6B.8080606@nthpermutation.com> <53517880.7080801@pobox.com> <53518A8D.4080107@pobox.com> <535425E8.4050808@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/R21WZGSQE0kcGQc_TqfF6VggmMs Cc: "tls@ietf.org" Subject: Re: [TLS] Constant Finished (was Re: Kill Finished) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2014 18:18:29 -0000 Meant to finish up on this. On 4/20/2014 4:21 PM, Watson Ladd wrote: > On Sun, Apr 20, 2014 at 12:54 PM, Michael StJohns > wrote: >> In some ways, the right answer might be to do a finished signature not over >> the messages, but over the content of SecurityParameters - with assumption >> that the SecurityParameters pseudo-structure is extended to provide enough >> information about offers and acceptances. > Why bother when we have the transcript which gives us exactly that? Because, you have to start the transcript before you know which summary function you're going to negotiate - e.g. which PRF for the cryptosuite. That gives you some issues with respect to negotiation of the PRF (and as we've been talking about an issue doing this for block cipher based PRFs) A signature over the transcript of all messages is really about signing the final snapshot state the results from those messages. In an ideal world, SecurityParameters would hold all of that state. AFAIK, SecurityParameters currently appears to hold all of the state except that generated from extension negotiation. Adding that in would allow a single HMAC signature over the SecurityParameters pseudo structure to replace the current HASH the messages then HMAC approach used to provide the Finished message tag. As I suggested elsewhere - it really should be possible to build a lightweight TLS1.3 system based on PSK and using only the AES block encrypt function. (Or other block encrypt function for other domains). To enable this, we either need to get the summary function (HASH(handshake_messages)) out of the middle, OR come up with a pretty standard block-cipher based hashing mechanism. The problem with the latter approach is that I'm unable to find a "standard" (e.g. issued by IEEE, NIST, X9 etc) block cipher hash construct. There are plenty of academic papers, but nothing that meets the "BCP" (Best Commercial Practice) smell test. > What you propose can work, but if we mess it up it won't be pretty. > Furthermore, if an extension isn't actually authenticated that's a > rather big semantic gap. Suppose ALPN wasn't authenticated, and the > same string could have two different meanings under two different > protocols. The right answer is never to remove properties TLS provides > today. The right answer is to understand what properties you actually get and make sure they're providing what you want and need (c.f. heartbeat for a counter example). Even crypto specifications say that it's ok to do things in different ways as long as you get the same answers. > > From nobody Tue Apr 29 11:27: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 005101A093E for ; Tue, 29 Apr 2014 11:27:55 -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 yDsIAiJnUQMw for ; Tue, 29 Apr 2014 11:27:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4721A1A091D for ; Tue, 29 Apr 2014 11:27:53 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3TIRit9002232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Apr 2014 20:27:45 +0200 (MEST) In-Reply-To: <535F6684.1040701@azet.sk> To: Fedor Brunner Date: Tue, 29 Apr 2014 20:27:44 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140429182744.DDA501ACE8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RQKkKL3YvUTyqzvOr7qIvbKsy5I Cc: tls@ietf.org Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 Apr 2014 18:27:55 -0000 Fedor Brunner wrote: > > The Mandatory Cipher Suite for TLS 1.2 was TLS_RSA_WITH_AES_128_CBC_SHA. > What is the mandatory cipher in TLS 1.3 ? > > Maybe TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 using Curve25519 for > ECDHE ? Support for ECC is/was a mere option in TLSv1.2. The specification of Curve25519 for use with rfc4492 is not yet standardized, same for ChaCha and Poly1035. What you're asking for is something that has very little in common with any prior version of TLS, and in particular ZERO interop with the currently installed base. TLSv1.2 (rfc5246) had the intention to be backwards-interoperable with the installed base (otherwise they would have not added the silly definition of an (md5,rsa) digital signature to TLSv1.2 (you may want to remove that bogosity from the v1.3 draft), but the amount of interoperability problems with the installed base was significantly enough to deter adoption of the protocol for >4 years. Looking at the amount of changes that are being considered and discussed here for TLSv1.3, I would not be surprised if the resulting adoption rate for TLSv1.3 would make the IPv6 adoption rate appear blazing fast... -Martin From nobody Tue Apr 29 13:20: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 E9B021A0986 for ; Tue, 29 Apr 2014 13:20:06 -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 fwXZwzVyBF8u for ; Tue, 29 Apr 2014 13:20:04 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DF2671A0958 for ; Tue, 29 Apr 2014 13:20:03 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr17so558307lab.17 for ; Tue, 29 Apr 2014 13:20: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=d38VxHR8UpKIZGb+jQsKjmrM0XUK8qh5phJA8n2bde0=; b=u2Y38dc5eV2mCOqLew9eyjouG8VbaQKbnnd6Zj2pn6yPR9m4AkP2ZPDJtCnUCjIt0n F6LO1T/pi7lYUwf1NyquTiTUx0kHi26jlmZFPc7/OuCABVuKyhNuXjuDHaAfXIGDcXFA cM/kEwmR6FqJHQY+H/LJw610VEmfhXbtZzL14nRGSMscpXP8w/86l4C3m6i22y+owJtf KJOZspsZngE9XZ8lCSvb9mcfkCyIGuuof3Oq72lJw6lz/34ibAhgTVLyUmakGK+UcE5U 1t8/bg/B6efv/EjIDTVAFZGszsoTA1A6TmN56OvA5HLQ6MpuPoF1V5qtnXG7kmTY+2ZC 04dw== MIME-Version: 1.0 X-Received: by 10.152.10.72 with SMTP id g8mr17358lab.50.1398802801863; Tue, 29 Apr 2014 13:20:01 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 29 Apr 2014 13:20:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Apr 2014 16:20:01 -0400 Message-ID: From: Phillip Hallam-Baker To: Klemens Baum Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Sfka4eD-rEPgetCgTaFLoO9uBc Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 20:20:07 -0000 I just submitted an update to keep it current. http://www.ietf.org/id/draft-hallambaker-tlsfeature-03.txt The issue is not the OID, it is support in the browsers. If there is support from one browser provider we can get backing to publish the draft. Without implementation in at least one of the browsers it does not help. On Thu, Apr 24, 2014 at 3:55 PM, Klemens Baum wrote: > After the whole Heartbleed incident, it has become obvious that the > current mechanisms for Certificate Revocation are inadequately > enforced by clients. > > To combat the issue, it would seem desirable for a security-conscious > server operator to be able to require the use of OCSP stapling on a > per-certificate basis. There was already an Internet-Draft (now > expired) for an X.509v3 extension which would provide this feature: > https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ > > Clients supporting the extension could display an enhanced security > indicator (e.g. "Certificate Status: Not revoked") for certificates > carrying the extension which pass validation, which would also > motivate more widespread adoption of OCSP stapling in favor of CRLs > and client-initiated OCSP requests. > > Since the draft looked very promising, I suggest that it should be > unexpired. If anyone with the authority to do so agrees, please submit > a request for resurrection per the guidelines at > http://www.ietf.org/ietf-ftp/1id-guidelines.txt. > > A few minor clarifications may still be needed so that it can be > quickly implemented by major browsers and the CAs: > > - The tls-feature OID is currently specified with a value of { id-pe 1 > }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself > already an X.509v3 extension). Surely a new OID in the > pkix.privateExtension arc will need to be allocated by IANA and if > this is the case, it should be noted in the section "IANA > Considerations". > > Please share your opinions! -- Website: http://hallambaker.com/ From nobody Tue Apr 29 13:33:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D291A09A8 for ; Tue, 29 Apr 2014 13:33:14 -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 qZK4ZYknqLZx for ; Tue, 29 Apr 2014 13:33:12 -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 6E3D31A08D8 for ; Tue, 29 Apr 2014 13:33:10 -0700 (PDT) Received: (qmail 4403 invoked by uid 1000); 29 Apr 2014 20:33:05 -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; Tue, 29 Apr 2014 21:33:05 +0100 Message-ID: <53600C81.5040007@comodo.com> Date: Tue, 29 Apr 2014 21:33:05 +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: Phillip Hallam-Baker 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/pLJvjNRQL72ckWCiwbdB_awAbus Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 20:33:14 -0000 AGL wrote: "For what it's worth: I support adding a certificate extension to indicate OCSP Must Staple and https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ appears to achieve that." Brian Smith wrote: "I think we'll be able to finish the Must-Staple implementation soon. Check with David (Keeler)". So ISTM that this I-D has the backing of at least two browsers. On 29/04/14 21:20, Phillip Hallam-Baker wrote: > I just submitted an update to keep it current. > > http://www.ietf.org/id/draft-hallambaker-tlsfeature-03.txt > > > The issue is not the OID, it is support in the browsers. If there is > support from one browser provider we can get backing to publish the > draft. Without implementation in at least one of the browsers it does > not help. > > > > > On Thu, Apr 24, 2014 at 3:55 PM, Klemens Baum wrote: >> After the whole Heartbleed incident, it has become obvious that the >> current mechanisms for Certificate Revocation are inadequately >> enforced by clients. >> >> To combat the issue, it would seem desirable for a security-conscious >> server operator to be able to require the use of OCSP stapling on a >> per-certificate basis. There was already an Internet-Draft (now >> expired) for an X.509v3 extension which would provide this feature: >> https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ >> >> Clients supporting the extension could display an enhanced security >> indicator (e.g. "Certificate Status: Not revoked") for certificates >> carrying the extension which pass validation, which would also >> motivate more widespread adoption of OCSP stapling in favor of CRLs >> and client-initiated OCSP requests. >> >> Since the draft looked very promising, I suggest that it should be >> unexpired. If anyone with the authority to do so agrees, please submit >> a request for resurrection per the guidelines at >> http://www.ietf.org/ietf-ftp/1id-guidelines.txt. >> >> A few minor clarifications may still be needed so that it can be >> quickly implemented by major browsers and the CAs: >> >> - The tls-feature OID is currently specified with a value of { id-pe 1 >> }, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself >> already an X.509v3 extension). Surely a new OID in the >> pkix.privateExtension arc will need to be allocated by IANA and if >> this is the case, it should be noted in the section "IANA >> Considerations". >> >> Please share your opinions! > > > -- 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 Tue Apr 29 13:56: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 F05781A03FC for ; Tue, 29 Apr 2014 13:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_5Qe9VRgjjX for ; Tue, 29 Apr 2014 13:56:25 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 56CF81A09BE for ; Tue, 29 Apr 2014 13:56:25 -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 s3TKu9rh024640; Tue, 29 Apr 2014 13:56:22 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1khmr8exvk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Apr 2014 13:56:21 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Tue, 29 Apr 2014 13:56:21 -0700 From: Paul Lambert To: Geoffrey Keating , "mrex@sap.com" Date: Tue, 29 Apr 2014 13:57:25 -0700 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9j7XjeLi8uLImPT2u/e4yfm9LuuQ== Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-29_05:2014-04-29,2014-04-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404290283 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2BZSxjr02zVjPfrv013CEqp4vgg Cc: "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 20:56:34 -0000 On 4/28/14, 12:44 PM, "Geoffrey Keating" wrote: >mrex@sap.com (Martin Rex) writes: > >> Processing multiple OCSP responses from the TLS multiple certificate >>status >> extension will also be interesting for TLS client that essentially throw >> away everything but the Server certificate from the Server's TLS >>Certificate >> handshake message and perform a new path discovery, because the >>resulting >> path may be different from the one that was sent by the server. > >This is only a problem if the new path discovery might use >certificates which weren't sent from the server (built-in >intermediates or ones fetched from the web), for which of course the >server won't have sent OCSP responses. Another way to put this is >that the server needs to send all necessary intermediates for OCSP >stapling to work properly. Yes. This is critical. Implementations currently do not support OCSP stapling for intermediaries. Just fielded a system and we Ended up not being able to support business models with more than one level of usable hierarchy. Stapling is not useable now for multi-level hierarchies. Paul > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 29 14:06: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 7A21A1A096E for ; Tue, 29 Apr 2014 14:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrFt_IQM7hX for ; Tue, 29 Apr 2014 14:06:12 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E542F1A02AC for ; Tue, 29 Apr 2014 14:06:11 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so1065608vcb.1 for ; Tue, 29 Apr 2014 14:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=+y3E0ttBmDSjdNf5oLxVrwAeQW+jGjtRxxgf3aQChYw=; b=K8myxHtmrbOMpj00AnW8wo0DjeNWUHmBHXJQcaLj4pdEY1AUklkrIWcG5NaG3fO8OQ 3kMpF0vZPqpKk82bLqi3jly+4JC4ctjc++uYaOb6TDXioi+GgbIzXGi7jCU3iUlzEOkM JPtESOEFUjZ0YCGs8cLHIlvg+4E67DtGrZoDSpvyvw9cJmCPgll4TgM0jjx5qViun9qf pHRc3j+oOsi7MtgoFVSjNDdwjTsxOQqN6BajVqYD+so5YSAu9/H7L8RSE+3ycTnlcmrU d7opCU+4PH4BlzGhO4lLca6ZzLtWSCHH/z6miXudFRl3V8kJ/FH3+eFgb0dSJHO98zGG aMsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=+y3E0ttBmDSjdNf5oLxVrwAeQW+jGjtRxxgf3aQChYw=; b=CV9cGbvVpc1Sc7RCZpiG7l6Ik+UFhvZ9ATugHrzm8XlYfXSLpGDn9IMHxIJQRG8hMZ Nv8EH2RCHQib+vgANRKrxnFKfVU9GDAl9LLt+V6XqWOUOSzAqlVl+5U+IuB9FxeDv5bH ppFxUKw7JprDCj2GoJvANSH5kUDXzJJl+CCVh5O1RJn+41sAmYJNKdjEiM0o+J+qWhu5 tyEnglTOUoGApRCGaauBgueS69ElUn21tY/d6y1lUzl4X8meceXohjo3//U5BZFyHgUB x3WnX0VfXuJqnppCJ1mZLdzqTCEb4G6kGGEO+xTcuw7jmGxNXSqJDEeAW2+jYzFruq39 BVhQ== X-Gm-Message-State: ALoCoQmO17qFKTCrfw4U2y00cbup2feQp9fz+T4PunAbK6EsdKvEb4QSmmQWNMJNNGnnOCiDPGEi09mc6QAo8Z9LOCuPqxzDGpf1DlR5/jrXnVz0eSdueJ0wyx1otkdZgmlcraQ0uhpbRYwnriat8SvQhMWaZyZ9INPz+ftnSqTQ+/gCC08ZAWoUpnQ2yWEwuDiWkcPrII9+ X-Received: by 10.220.197.2 with SMTP id ei2mr46754vcb.63.1398805570390; Tue, 29 Apr 2014 14:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Tue, 29 Apr 2014 14:05:50 -0700 (PDT) From: Adam Langley Date: Tue, 29 Apr 2014 14:05:50 -0700 Message-ID: To: Eric Rescorla , "Joseph Salowey (jsalowey)" , "tls@ietf.org" , Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BALJpSfAK0-nIW7JfFItgvSAv0I Subject: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:06:14 -0000 Without a fix for the Triple Handshake issues[1], TLS Channel Bindings (at least tls-unique) have a significant problem, not to mention client-auth. Microsoft and ourselves are looking to implement the proposed fix[2] soon. I'd like to request that the WG adopt the draft and that the process for early codepoint assignment for the TLS extension start. I think the change to the master secret calculation is relatively uncontroversial (and is probably what the master secret should always have been). People might have differing opinions on the SCSV, but that doesn't affect whether a TLS extension number will ultimately be allocated for it. [1] https://secure-resumption.com [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt Cheers AGL From nobody Tue Apr 29 14:10: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 075511A0984 for ; Tue, 29 Apr 2014 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMOXo3LTpY8k for ; Tue, 29 Apr 2014 14:09:58 -0700 (PDT) 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 1AC241A096E for ; Tue, 29 Apr 2014 14:09:58 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so60471veb.18 for ; Tue, 29 Apr 2014 14:09:56 -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=O0IROCNgJ4YlE2HQ13zieGNCdfrpl2ifA9mEOIEzIAM=; b=ptCt5jO3ZsoEjDdAxCv6m0FahwHk0T0tbOg49ThXOgihWiJr3bpI+xtG12Jr3PHhtU ZobmvCfUDXGHqL4z/i7igGSFI9dKa7+Sa0bQo6e3oqq5i/dtZ/2J/24sXC/J9izM4IJI Y+QBQShjnSsl0C/6c0AtESOtxoJXR63ZeDlR8Zh65TLufJsF4mzsf3pgM4qVgsKyXLAK EjGMWUdpw8sp79cm8ckffe8oWsw6Vb1SsfwISo/byf98PCnGRu8gsmwOlj4ur3QcjjOT hpq+niiD9Mad7AfIXBGYneQAWauM/xyoF/toG1BlHvz0f6x74o2+eVzmsOAF6f38fTG7 HpPw== 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=O0IROCNgJ4YlE2HQ13zieGNCdfrpl2ifA9mEOIEzIAM=; b=E9ThP4zN/XrkkMltU1yf2E0xI5PVLOeeyUZdx/ownJfO51OlfNP5lYpVeeycn8+WtJ /ZgYpBShUYmsl6MVPiqBZh4zbEqoIwJ2VCWSNdZmU6xIPUfZrj61VLGOxFTm6w6Ng04U 8GOPLvLdML5pGfk6+jyetvgWZWvgFMR6hwKql9EYMmzVZGGwffUSqxYqo0sNhNAP8be4 cZL7l8Ls39qkfkicV9S+egw5iDTL3XskNf6cPWna/QcTyuzSIUGzVte1D66ib7mq1TyY U5iWLRvZbsRaLZ8wx3USWdXNpR54ipgPDJ7rGFei8FmMtRCSWVD6m5X0Itwh/AB8IvX7 7G/A== X-Gm-Message-State: ALoCoQnwVsXkE4VAHeEIrNeoVQGdhhPkQLPjEEe7w66OznQd17SEB8bOuC9fTWJVS81LHeXuHF6iHtKf6am9DSDNvfLi+dj2Hn/glVXNHjmXmpE8jTDclnKVmFWWDtxui4ZfCFic+WtvrrVi8pKuesKBiEa/BBbJ2obo5kDyWqsh4quqnBYux6rUZ4V3VXoDM2D/SFcUC5/7 X-Received: by 10.58.23.6 with SMTP id i6mr225269vef.12.1398805796733; Tue, 29 Apr 2014 14:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Tue, 29 Apr 2014 14:09:36 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> From: Adam Langley Date: Tue, 29 Apr 2014 14:09:36 -0700 Message-ID: To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3bJM10BXQLVoIQnYMuqX8JM5RPk Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 21:10:04 -0000 On Tue, Apr 29, 2014 at 1:57 PM, Paul Lambert wrote: > Yes. This is critical. Implementations currently do not support > OCSP stapling for intermediaries. Just fielded a system and we > Ended up not being able to support business models with more > than one level of usable hierarchy. Stapling is not useable > now for multi-level hierarchies. It might well be that Must Staple is best done for just the leaf and that pushed CRLs are used for intermediate revocations. That's the deployment model that I think is mostly likely. As for Chrome's support: it's tough because we use different libraries on different platforms (CAPI on Windows, OS X's library there and NSS in other places). We also have a lot happening with our switch to OpenSSL. So, while we would like to support Must Staple, that is currently delaying it. Hopefully Firefox can beat us to it. Cheers AGL From nobody Tue Apr 29 14:22: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 6DB241A0955 for ; Tue, 29 Apr 2014 14:22:43 -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 toQWhnmxFPJw for ; Tue, 29 Apr 2014 14:22:42 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE30A1A0949 for ; Tue, 29 Apr 2014 14:22:42 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id B3BD42007870D for ; Tue, 29 Apr 2014 14:22:41 -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=Scs1NMrVP4H1xi3ai5Sf EUVA9ME=; b=LUlffHg0+wfheQHc8NG7bLJwWMx/khpejhqqj57F/U7TNRa/oBZD aTEFkTbb6gWHRCndcYclHMU8rWwfZXnNyl8SHCII5Y2+4sy0+OVXXJydl88nssTR JAoI1LKtkvon6I6rNmNPrC18cABDDVDGHrkWo93lknPiBeeihps83qU= 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-a108.g.dreamhost.com (Postfix) with ESMTPSA id 691512005D82E for ; Tue, 29 Apr 2014 14:22:41 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x13so835508wgg.20 for ; Tue, 29 Apr 2014 14:22:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.205.161 with SMTP id lh1mr282680wjc.40.1398806560134; Tue, 29 Apr 2014 14:22:40 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 14:22:40 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> Date: Tue, 29 Apr 2014 16:22:40 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BO8a4PW1NzOX7euNLQd-Lb7GceQ Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 21:22:43 -0000 On Tue, Apr 29, 2014 at 4:09 PM, Adam Langley wrote: > On Tue, Apr 29, 2014 at 1:57 PM, Paul Lambert wrote: >> Yes. This is critical. Implementations currently do not support >> OCSP stapling for intermediaries. Just fielded a system and we >> Ended up not being able to support business models with more >> than one level of usable hierarchy. Stapling is not useable >> now for multi-level hierarchies. > > It might well be that Must Staple is best done for just the leaf and > that pushed CRLs are used for intermediate revocations. That's the > deployment model that I think is mostly likely. > > As for Chrome's support: it's tough because we use different libraries > on different platforms (CAPI on Windows, OS X's library there and NSS > in other places). We also have a lot happening with our switch to > OpenSSL. So, while we would like to support Must Staple, that is > currently delaying it. Hopefully Firefox can beat us to it. The deployment model I imagine is: - servers run a daemon to get fresh OCSP Responses periodically - this daemon raises alerts if responses get too old - servers staple the responses fetched by this daemon - clients validate all stapled responses Why couldn't that work? There'd be a need to cache OCSP Responses for intermediates, sure. What else? Nico -- From nobody Tue Apr 29 14:26: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 4605A1A08E5 for ; Tue, 29 Apr 2014 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otlhhl05NPbD for ; Tue, 29 Apr 2014 14:26:02 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D95AE1A0792 for ; Tue, 29 Apr 2014 14:26:01 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id oz11so1043297veb.33 for ; Tue, 29 Apr 2014 14:26:00 -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=5nS7cv1nobkewxcbjDnTPiGVGxpPXe86TgDUsvhmF0A=; b=ms9AgIOGeMSbKGLq2drr1XN+uJO+25wNEbr8Xr+w5KidN4IJXJYOSwLc1dUKf9hbr1 /t5+CtWGcFxcBolB88h4AnRxwRSat7kwW7DpAirDqNpEM2SnqgVyX5ugUmQz2LCM6iEU F6Qbz41ex0iHvWr7dQZn6ttL5sIQlgEK1y1ZUWiQrhACWATH8NbwfZScBHK69g+g5Gy4 CC9lLcfkpf1xrDsQnJIB58v/mXzq3UAEAsW/dIiJCkWRc/fuGsAoJhOpC2ON/xvwpHg8 zxHgQgsJR/wn9XzYlo/2c8KG9hHcUPCR6Z+CJsH9IgDfPiCeva8gagUGvlRb8vpKyoKp Y2kA== 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=5nS7cv1nobkewxcbjDnTPiGVGxpPXe86TgDUsvhmF0A=; b=LEDLYKlYeTWSVmBywRsobj9w89arwhTj+ml/i7BGAKJ/xyUDxTB3gYyAPMhQyF4iji DYkPlIqu1ZeEtcV6MUXP3Va//we11iUApouF6HRL0o7oKN0YnefIIuOHAvK7q0D7q5J9 cx6E3PYEb2JCuPjjOlT/aCjQK7jcyIqSLmhv0EnEYD3V9IXpui3ImkyADF7jRATrXKoJ qB1tEp3t6R/qBWLJG/S4ACHaJWJVBIBvBQAC51WwvGMhaRt+Cl1xvoiFBhVIuaeAGevY z9VNFWZp1vq16MCyvM85B9g2lQVIypW7VOtWGmxkroIAA8Ug+JlTMIppR1oCO5dsFN03 fi8g== X-Gm-Message-State: ALoCoQlF7XOJBbukMfH3EOPSkW4tZM6nmyQ57WC3ZFLInIBDyMVKNn23aIU7AOEti8hEogY1BdSV0xusMUdL8ldgg3p3NA0YsJWtfsz3YNw3An5bKkUtyT8HAisOhYc3wmXncAfTU+uvzeo29FKqnYW9tq67Gv4KJQtnXJAh1NA40rdzafUnhSQ5qvc/Gc16UXxNEKe94rJw X-Received: by 10.52.229.97 with SMTP id sp1mr107955vdc.23.1398806760473; Tue, 29 Apr 2014 14:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with HTTP; Tue, 29 Apr 2014 14:25:40 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> From: Adam Langley Date: Tue, 29 Apr 2014 14:25:40 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SrHTZOb0l_RLlwpyA-TT9Uo4dAQ Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 21:26:03 -0000 On Tue, Apr 29, 2014 at 2:22 PM, Nico Williams wrote: > - servers run a daemon to get fresh OCSP Responses periodically > - this daemon raises alerts if responses get too old > - servers staple the responses fetched by this daemon > > - clients validate all stapled responses > > Why couldn't that work? There'd be a need to cache OCSP Responses for > intermediates, sure. What else? That's totally viable, I'm just suggesting that revocations of intermediates are very rare and generally involve browser pushes in any case. So the effort of getting a server that does multi-stapling over just stapling, and of shipping the extra OCSP responses in every handshake, might well win out. I think it would be quiet reasonable for a site to have Must Staple just for the leaf certificate. Cheers AGL From nobody Tue Apr 29 14:28: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 B71EE1A093C for ; Tue, 29 Apr 2014 14:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5aLEdC0MCph for ; Tue, 29 Apr 2014 14:28:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id C8BF61A096B for ; Tue, 29 Apr 2014 14:28:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 771A52858C; Tue, 29 Apr 2014 21:28:10 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 63173284F4; Tue, 29 Apr 2014 21:28:10 +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 5E52B8003C; Tue, 29 Apr 2014 21:28:10 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.146]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 29 Apr 2014 17:28:10 -0400 From: "Salz, Rich" To: Adam Langley , Paul Lambert Date: Tue, 29 Apr 2014 17:28:09 -0400 Thread-Topic: [TLS] Status of X.509v3 TLS Feature Extension? Thread-Index: Ac9j72eua3hDJ2JUSoCPOFzH+ZKYhQAAmwaw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7130742B777@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> 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/5gEYxvTgr_FG9g74AIy2eSwyIyE Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 21:28:14 -0000 > It might well be that Must Staple is best done for just the leaf and that= pushed CRLs are used for intermediate revocations. > That's the deployment model that I think is mostly likely. +1 -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Tue Apr 29 14:31: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 3988F1A08F0 for ; Tue, 29 Apr 2014 14:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5ETvFYmlsozy for ; Tue, 29 Apr 2014 14:31:35 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D5D521A02AC for ; Tue, 29 Apr 2014 14:31:34 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id i4so255282oah.5 for ; Tue, 29 Apr 2014 14:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FjkzW/AapWIanwI5G4J9qfKjLJlKRWZPGDn7JN8at0k=; b=ZLLoov2IVzgxKERKTcUDHWByA1jDOCnTriIyXFyPsxEYzC5koGWt8pNNR+DmtFkpls up9hiCwIa6Td3NRtGhV1g6maf7LgSq5bObmItz92oqVjJNACZ2MP6dH+P9nOz7hSDDVR 4e0VRSh3sARXCmY7fpp4EOCr9Fxm7k4CR3790= 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=FjkzW/AapWIanwI5G4J9qfKjLJlKRWZPGDn7JN8at0k=; b=HUX9Uy9lqWHJ+v7nJI2IHoXMJEXDHgi5R+k7tpmmplJefDGqi2ZZsDctCHle1+7v+j a1/CMKJ23xp107SUuRn2D3kSHFrptTplyRA+gsMIXaSeIkCnhkDPHNxsvQdvkSedZBnk Dnzb0Q6jpvXeFpV1lgKg5Z89lDs59pE47tIsZ99HYPikfE0pln5hhkQTvSFGbxR5FBto WhN9ZcTOcJOSD8xTaAqRcW4JvWNcRJku16CfTzEdv1X+QzyciULVZp0CbiRQbOLAmhqI lpEvELmrKTaphs3ZaDR/esXaf71kxkGkBGsKsk/9hJaekOziRsrak7WrcnqcTvdcIl7n fCVQ== X-Gm-Message-State: ALoCoQlagCDgZe0MqQblkGA0jmuUV6PAu32ZFM2RFLpk1cuLW+zncT22+Igf+yMifz34GxP2z9ac MIME-Version: 1.0 X-Received: by 10.60.103.210 with SMTP id fy18mr1536227oeb.75.1398807092981; Tue, 29 Apr 2014 14:31:32 -0700 (PDT) Received: by 10.76.24.168 with HTTP; Tue, 29 Apr 2014 14:31:32 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: References: Date: Tue, 29 Apr 2014 23:31:32 +0200 Message-ID: From: Alfredo Pironti To: Adam Langley Content-Type: multipart/alternative; boundary=089e0115ee7ce3045404f8352712 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YmT4RE1yAaHhVVl84yEiqmf9bEg Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:31:36 -0000 --089e0115ee7ce3045404f8352712 Content-Type: text/plain; charset=UTF-8 I've uploaded the draft to the IETF repository [1]. A tentative implementation of the fix for OpenSSL is available at [2]. (This patch currently also includes a "secure resumption" extension, which would become unnecessary if the master secret derivation is fixed; I'm willing to cleanup the patch if there's interest in it). Cheers, Alfredo [1] http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt [2] https://secure-resumption.com/patches/OpenSSL1_0_1e-session_hash-extended_ms-secure_resumption.patch On Tue, Apr 29, 2014 at 11:05 PM, Adam Langley wrote: > Without a fix for the Triple Handshake issues[1], TLS Channel Bindings > (at least tls-unique) have a significant problem, not to mention > client-auth. > > Microsoft and ourselves are looking to implement the proposed fix[2] > soon. I'd like to request that the WG adopt the draft and that the > process for early codepoint assignment for the TLS extension start. > > I think the change to the master secret calculation is relatively > uncontroversial (and is probably what the master secret should always > have been). People might have differing opinions on the SCSV, but that > doesn't affect whether a TLS extension number will ultimately be > allocated for it. > > > [1] https://secure-resumption.com > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt > > > Cheers > > AGL > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0115ee7ce3045404f8352712 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've uploaded the draft to the IETF reposito= ry [1].

A tentative implementation of the fix for OpenSSL is a= vailable at [2]. (This patch currently also includes a "secure resumpt= ion" extension, which would become unnecessary if the master secret de= rivation is fixed; I'm willing to cleanup the patch if there's inte= rest in it).

Cheers,
Alfredo
[2] https://secure-resumption.com/pat= ches/OpenSSL1_0_1e-session_hash-extended_ms-secure_resumption.patch

On Tue, Apr 29, 2014 at 11:05 PM, Adam Langl= ey <agl@google.com> wrote:
Without a fix for the Triple Handshake issues[1], TLS Channel Bindings
(at least tls-unique) have a significant problem, not to mention
client-auth.

Microsoft and ourselves are looking to implement the proposed fix[2]
soon. I'd like to request that the WG adopt the draft and that the
process for early codepoint assignment for the TLS extension start.

I think the change to the master secret calculation is relatively
uncontroversial (and is probably what the master secret should always
have been). People might have differing opinions on the SCSV, but that
doesn't affect whether a TLS extension number will ultimately be
allocated for it.


[1] https://sec= ure-resumption.com
[2] https://secure-resumption.com/draft-bhargavan-= tls-session-hash-00.txt


Cheers

AGL

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

--089e0115ee7ce3045404f8352712-- From nobody Tue Apr 29 14:32: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 319921A02AC for ; Tue, 29 Apr 2014 14:32:20 -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 8FCPu1bTM-AZ for ; Tue, 29 Apr 2014 14:32:15 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id CF6561A08F0 for ; Tue, 29 Apr 2014 14:32:14 -0700 (PDT) Received: from 85.168.202.84.customer.cdi.no ([84.202.168.85]:56406 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WfFdM-0006Xy-U7; Tue, 29 Apr 2014 23:32:12 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Eric Rescorla" , "Joseph Salowey (jsalowey)" , "tls@ietf.org" , "Nico Williams" , "Adam Langley" , "Karthikeyan Bhargavan" References: Date: Tue, 29 Apr 2014 23:31:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PVxhStu7aphPaIzyvQsMjU9kKFo Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:32:20 -0000 Hi, On Tue, 29 Apr 2014 23:05:50 +0200, Adam Langley wrote: > I think the change to the master secret calculation is relatively > uncontroversial (and is probably what the master secret should always > have been). People might have differing opinions on the SCSV, but that > doesn't affect whether a TLS extension number will ultimately be > allocated for it. > > > [1] https://secure-resumption.com > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt A comment about the draft: Section 5.3 states: In its ClientHello message, a client MUST either send the "extended_master_secret" extension, or the "TLS_EXTENDED_MASTER_SECRET" SCSV. Clients SHOULD NOT include both. In my opinion, the "SHOULD NOT" ought to be a "MUST NOT", *unless* the document also states something like "Servers MUST accept ClientHello messages that contain both the "extended_master_secret" extension and the "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been received" When I originally implemented the Renego Information extension in Opera, I decided to send both, since deciding when to send either complicates the code, at least a little. However, I had to eventually change the code to send only one of them (SCSV in extension less handshakes, extension otherwise), as 4.7% of Renego patched servers does not tolerate the combination, some of them major sites like Linkedin and Paypal. A SHOULD NOT means that the server may encounter handshakes with both, and since server vendors apparently are apt to think that "either" and "SHOULD NOT include both" in combination means "MUST NOT include both", then the document should either specify how the server should handle reception of both indicators, or say that both are forbidden. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Tue Apr 29 14:57:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B681A09D8 for ; Tue, 29 Apr 2014 14:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ893u8FOsFF for ; Tue, 29 Apr 2014 14:57:55 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A94141A09A9 for ; Tue, 29 Apr 2014 14:57:55 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 9402B26C05E for ; Tue, 29 Apr 2014 14:57:54 -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=ztvdjSWf9eVAMTTLqGHO T8fHKGM=; b=sykK73yb4Vm50zDq4KLEOwomyZ0IAjvAIsfwt2LsvtlWAbkEbEKF d62Me9g97rvhnYJ46a7vjgGbxmTXzJHYyXYNcXprUxcwd9XOAaqApW93jFYBARru FsppiwdBL4f0/Ek/tRzeSGb46j7aAeg7UsUl8C3gAQzZ/9IIr5jDyXo= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 446CB26C05B for ; Tue, 29 Apr 2014 14:57:54 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so856296wes.17 for ; Tue, 29 Apr 2014 14:57:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.38 with SMTP id f6mr257584wjq.59.1398808672746; Tue, 29 Apr 2014 14:57:52 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 14:57:52 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> Date: Tue, 29 Apr 2014 16:57:52 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5rSbKvI6w75erjtAX2zWCMxqe_w Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 21:57:56 -0000 On Tue, Apr 29, 2014 at 4:25 PM, Adam Langley wrote: > On Tue, Apr 29, 2014 at 2:22 PM, Nico Williams wrote: >> Why couldn't that work? There'd be a need to cache OCSP Responses for >> intermediates, sure. What else? > > That's totally viable, I'm just suggesting that revocations of > intermediates are very rare and generally involve browser pushes in > any case. So the effort of getting a server that does multi-stapling > over just stapling, and of shipping the extra OCSP responses in every > handshake, might well win out. I think it would be quiet reasonable > for a site to have Must Staple just for the leaf certificate. I suspect that for intermediates closer to the server it'll be best to staple responses. For intermediates closer to the root issuer it'll be best to deal with pushing. We have to consider environments where long cert paths are involved, and where network connectivity isn't universal. Of course, in bridged PKIs the RPs have to handle revocation checking for part of the cert path anyways. I think the right thing to do may well be to implement full stapling but configure partial stapling as appropriate: a) stapled OCSP checking on the client side b) CRL checking / push on the client side c) full _and_ partial OCSP stapling on server sides d) server admins need to configure stapling (and refreshing) of whatever length of the server cert chains is appropriate, from the leaf towards the root. Nico -- From nobody Tue Apr 29 15:02: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 4ABEC1A094B for ; Tue, 29 Apr 2014 15:02: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 h8iUPzHYZ4HC for ; Tue, 29 Apr 2014 15:02:51 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7C1A09E6 for ; Tue, 29 Apr 2014 15:02:51 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 9121A58406F for ; Tue, 29 Apr 2014 15:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Ik/Gf4bkY/KU08Cx0RCY 0PTp2H8=; b=DFj12f/fZNU2Ui0B0Z4Z1WAqUk647XKT8R6QWPAoDC3H4f8i2GLf uB2KUd61jkMkMBxItr4dMJ7XsNUXcg2vZxmu22Kf1BRlBMqDq2C0LOCFdWP1UOC0 Gp4MgFiLJH1Zci3t0Haz+W26PWV/IR4LzzdOmIYRh2kdSw4QjNUF5PI= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 447BE584055 for ; Tue, 29 Apr 2014 15:02:50 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id f8so1226670wiw.14 for ; Tue, 29 Apr 2014 15:02:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr327717wic.5.1398808969105; Tue, 29 Apr 2014 15:02:49 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 15:02:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Apr 2014 17:02:49 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lpkVxhRahYRP9Z_0xSaoggDDDoE Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:02:52 -0000 On Tue, Apr 29, 2014 at 4:05 PM, Adam Langley wrote: > Without a fix for the Triple Handshake issues[1], TLS Channel Bindings > (at least tls-unique) have a significant problem, not to mention > client-auth. tls-unique is fine provided resumption isn't broken. Resumption is broken. There is a proposed fix[2] that IMO is correct and works. Of course, apps need to know when tls-unique is safe, but since it's only not safe when using TLS implementations where resumption isn't safe... there's not much that can be done other than to disable tls-unique at build time or find a way to detect safety at run time. > Microsoft and ourselves are looking to implement the proposed fix[2] > soon. I'd like to request that the WG adopt the draft and that the > process for early codepoint assignment for the TLS extension start. +inf > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt Yes. Nico -- From nobody Tue Apr 29 15:06: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 BCA361A09CA for ; Tue, 29 Apr 2014 15:06:22 -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 5VsowCKAO03f for ; Tue, 29 Apr 2014 15:06:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94E1A09A9 for ; Tue, 29 Apr 2014 15:06:20 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3TM6B6e021033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2014 00:06:11 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen" Date: Wed, 30 Apr 2014 00:06:10 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140429220611.041D31ACE8@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M28S_wyCFWRRrCkXMlRB-TWP6d8 Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. 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, 29 Apr 2014 22:06:22 -0000 Yngve N. Pettersen wrote: > > On Tue, 29 Apr 2014 23:05:50 +0200, Adam Langley wrote: > > > > [1] https://secure-resumption.com > > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt > > A comment about the draft: > > Section 5.3 states: > > In its ClientHello message, a client MUST either send the > "extended_master_secret" extension, or the > "TLS_EXTENDED_MASTER_SECRET" SCSV. Clients SHOULD NOT include both. > > In my opinion, the "SHOULD NOT" ought to be a "MUST NOT", *unless* the > document also states something like "Servers MUST accept ClientHello > messages that contain both the "extended_master_secret" extension and the > "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been > received" The only problem is having two seperate indicators with the exact same meaning in the first place. Kill the ClientHelloExtension, have everyone use the SCSV in ClientHello all the time. > > When I originally implemented the Renego Information extension in Opera, I > decided to send both, since deciding when to send either complicates the > code, at least a little. However, I had to eventually change the code to > send only one of them (SCSV in extension less handshakes, extension > otherwise), as 4.7% of Renego patched servers does not tolerate the > combination, some of them major sites like Linkedin and Paypal. The by far simplest approach is to send SCSV on all initial handshakes plus on old-style renegotiation handshakes, and the TLS extension on all renegotiation handshakes. KISS -- smaller and simpler code. So far I have not received any reports about interop problems with my implementation. > > A SHOULD NOT means that the server may encounter handshakes with both, and > since server vendors apparently are apt to think that "either" and "SHOULD > NOT include both" in combination means "MUST NOT include both", then the > document should either specify how the server should handle reception of > both indicators, or say that both are forbidden. Imperatives should only be used when they're absolutely necessary, so here we have the situation where we need a MAY if we can not get rid of the ClientHelloExtension. Unfortunately, the poor choice of defining both for rfc5746 made it likely that a few superficial implementors get the combination wrong. Remember Mike's description? https://www.ietf.org/mail-archive/web/tls/current/msg05456.html -Martin From nobody Tue Apr 29 15:17: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 8A5591A09F2 for ; Tue, 29 Apr 2014 15:17:06 -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 bAA3v7R5TDKP for ; Tue, 29 Apr 2014 15:17:05 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 102901A0953 for ; Tue, 29 Apr 2014 15:17:04 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mc6so642579lab.15 for ; Tue, 29 Apr 2014 15:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k4nootKIVAlkOJueztT+XPhoP79COfw8xAInDSCXjPs=; b=UjZ9Pjkocb2gXG5txOZ8fLHPk69VZX1hiqo1PMbhE4LBxPVvesIZcDckc6mApvNHil E5ZBMKY9CGrlbFe0MhLswtFXZXaeMNhwbCWYlzoQpSQ+Gafyc9bqs9/NoSfeemikKvx/ ayRPCKKV0InXVzj+7wzDCVA83TLKVg1Pe9xypEPIDUi02kWXSujyYKlpD7TgkSNgBJ8t 03vgLq4xa6LoKG4HCrmDN1Z1/KUwLe5Tsp+VsfgH2GijatD7zGL1a9YBP/+qpACKNe12 eOYuerpupRX4oV5t9xrIDbLJRmj1ssQetgCHavthVq4IdROQDLbfUwjpX+jt5vkYDcew kFbQ== MIME-Version: 1.0 X-Received: by 10.152.199.39 with SMTP id jh7mr252509lac.18.1398809823221; Tue, 29 Apr 2014 15:17:03 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 29 Apr 2014 15:17:03 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130742B777@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7120C61F669@USMBX1.msg.corp.akamai.com> <20140428180218.C805D1ACE1@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C7130742B777@USMBX1.msg.corp.akamai.com> Date: Tue, 29 Apr 2014 18:17:03 -0400 Message-ID: From: Phillip Hallam-Baker To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vVCpIPZSNqEMxT8XhxTxbFtY038 Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] Status of X.509v3 TLS Feature 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: Tue, 29 Apr 2014 22:17:06 -0000 On Tue, Apr 29, 2014 at 5:28 PM, Salz, Rich wrote: >> It might well be that Must Staple is best done for just the leaf and that pushed CRLs are used for intermediate revocations. >> That's the deployment model that I think is mostly likely. > > +1 If we revoke an intermediate that doesn't have a name constraint in then I can't see how we would not be doing some pretty aggressive pushing out of the CRL. Name constraints might change that calculus at some point in the future, but not for quite a long time. -- Website: http://hallambaker.com/ From nobody Tue Apr 29 16:11: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 234161A09E1 for ; Tue, 29 Apr 2014 16:11: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 DAv9qqkhOTM4 for ; Tue, 29 Apr 2014 16:11:41 -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 751AD1A09E6 for ; Tue, 29 Apr 2014 16:11:41 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so920104wgh.27 for ; Tue, 29 Apr 2014 16:11:39 -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=Cxk5fG8tCzBgtat3ErG7W/cuJSaZG49QSN8c9+4/LrM=; b=z2uliAN7eA0TehpF3YVv6PfYyxgg7dpd9OAXsUqifNydRKNpLJJLmWR1omQuMTi4TJ +NhEmphguhTWWo3CdcnTLc9oWYpfvwWgKnOt3G2Hbv931a8/Pa4yEkq+S+9d04Gq7WUr uQ8jCADAypzCnKQ/uI2OCVM437+TQbWVcY7N0KQcoyzZyfH4k8b09mD3pXbUqTEb4FWr ntqeP1Iaz45KSvSMBAztUk3787ypxGaBnjyusV1zccnP01/gqWUdqRGiw57RyGff8qyF xNfaYFeK/b+zbi4wq+k3u4F7XA1rEKc+MDe2D0WoLz/9FCmrrmL9038xAwcj+ospO4w+ toCQ== MIME-Version: 1.0 X-Received: by 10.180.189.65 with SMTP id gg1mr578621wic.56.1398813099816; Tue, 29 Apr 2014 16:11:39 -0700 (PDT) Received: by 10.227.77.138 with HTTP; Tue, 29 Apr 2014 16:11:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Apr 2014 16:11:39 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/irxUYNIeYOK_aH3CUr3JPGlOa6o Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:11:43 -0000 On 29 April 2014 15:02, Nico Williams wrote: > tls-unique is fine provided resumption isn't broken. Resumption is > broken. There is a proposed fix[2] that IMO is correct and works. So the proposed fix doesn't do anything about resumption, it changes the derivation of the master secret. I think that the proposed fix is the right one - one we should be fixing for TLS <=1.2. There are probably better options for fixing 1.3. From nobody Tue Apr 29 16:16: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 69CE21A09F5 for ; Tue, 29 Apr 2014 16:16:35 -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 baOvCH_qEuh8 for ; Tue, 29 Apr 2014 16:16:31 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 19B8B1A09F3 for ; Tue, 29 Apr 2014 16:16:31 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id BF85633CF8A; Tue, 29 Apr 2014 22:49:21 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Adam Langley References: From: Geoffrey Keating Date: 29 Apr 2014 15:49:21 -0700 In-Reply-To: Message-ID: Lines: 33 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/pYB9iJqZ0W9CvaciY_Q1WUBVZvA Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:16:35 -0000 Adam Langley writes: > [2] https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt I read this and couldn't work out how it interacted with renegotiation. I'm surprised there's no discussion of renegotiation at all in section 3. Does 'handshake_messages' include: a) Only the first handshake; or b) Only the last handshake; or c) All messages from all handshakes, up to the Client Key Exchange message in each handshake; or d) All messages from all handshakes, up to the Client Key Exchange message in the last handshake, up to the Finished message in previous handshakes, including any HelloRequest messages; or e) Like d but without HelloRequest messages; or f) Other? I'm fairly sure a and b lead to security vulnerabilities. I'm not sure whether c does so or not. d and e present some challenges for implementations with TLS 1.2, because you could renegotiate to a different hash algorithm, so you need to keep the contents of the handshake(s), or all possible partial hashes, for the duration of the connection. I also note that the draft leaves out the (last?) 'certificate verify' message, is that intentional? Are there any security consequences? From nobody Tue Apr 29 16:43: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 2E8C71A09A2 for ; Tue, 29 Apr 2014 16:43:01 -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 6uzlRKQishDc for ; Tue, 29 Apr 2014 16:43:00 -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 9270B1A0948 for ; Tue, 29 Apr 2014 16:43:00 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 593EE2007DA14 for ; Tue, 29 Apr 2014 16:42: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=DQEVZLCKL9Vy0iRqKGJS FJ6j/iM=; b=t9abDzvn5FsipyfNtnIN/My9S0xHFkLLHiOPI7FjD1wzU9+L7Lxn 0kAt3J0TWGT6SOpOJuvfYRTyf9n5W/HrgqSIM0Ro5I3ASdmQZtHiX/RxzkHE38pi co6A60n7t0NrCIErrUiNNTPEAFR6N+K79vxRaTLYfM5gfRClV/rN43I= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 0EB592007DA13 for ; Tue, 29 Apr 2014 16:42:58 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so919870wev.19 for ; Tue, 29 Apr 2014 16:42:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr704691wib.42.1398814977850; Tue, 29 Apr 2014 16:42:57 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Tue, 29 Apr 2014 16:42:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Apr 2014 18:42:57 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3AGSU7g_zzuSpvNj_DQqJ8gwrZ0 Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 23:43:01 -0000 On Tue, Apr 29, 2014 at 6:11 PM, Martin Thomson wrote: > On 29 April 2014 15:02, Nico Williams wrote: >> tls-unique is fine provided resumption isn't broken. Resumption is >> broken. There is a proposed fix[2] that IMO is correct and works. > > So the proposed fix doesn't do anything about resumption, it changes That's quibbling. Something is broken in TLS leading to tls-unique CB being vulnerable among other things. There is a fix that effectively channel binds the new connection to the one being resumed, and this naturally solves the problem. > the derivation of the master secret. Right. > I think that the proposed fix is the right one - one we should be > fixing for TLS <=1.2. There are probably better options for fixing > 1.3. I agree as to fixing TLS <= 1.2. I don't think there is a better option for 1.3 (short of removing resumption, as some have proposed), therefore it's also the correct fix for 1.3 (assuming no major changes like dropping Finished messages as Watson Ladd proposed, which would require updating tls-unique concurrently). Nico -- From nobody Tue Apr 29 17: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 9818E1A09A0 for ; Tue, 29 Apr 2014 17:50: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 z-jM1xo0v-P4 for ; Tue, 29 Apr 2014 17:50:55 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E21A099E for ; Tue, 29 Apr 2014 17:50:54 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id z6so1013434yhz.17 for ; Tue, 29 Apr 2014 17:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nt/16GFiSZ259fAWpxZu1Ogdnf06DIrkEprXKxpK/f8=; b=QgkW9O7reFAZeqskK2AEPIKPHHqTNaSgsvePEOig5VYCgmK+fwfpS14lczREn2dVnX 0gOZZhzNSzLU1al4axMdxHpOM5dKAlJaN+F9e8i8IKJzr1b3xRfcKJfAqUHJ+yjL2G1Y Qegn78ro4ytEnXrNCgtMFiLC2Bya9aGCr8NsxmMa/WouWU2JpbeOQa8u8aWMMwVNDqxo d0sT0z0wV0FbudjH+CqIS/GJIsuiWMydndVtPz/vhWNTh28dpZHXgnDa8yaX0FyRkN0p Q3PI2OLw/iLCtJIIOjyOzksKAi0j4zNcU8vZbMibA3S5dB+iwss3DuhOTmSVp6gVOM+A ieWQ== MIME-Version: 1.0 X-Received: by 10.236.66.135 with SMTP id h7mr1553798yhd.60.1398819053614; Tue, 29 Apr 2014 17:50:53 -0700 (PDT) Received: by 10.170.63.197 with HTTP; Tue, 29 Apr 2014 17:50:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Apr 2014 17:50:53 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Ka_TdRZAzetIUjPbE-ZhaQKEiI Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 00:51:00 -0000 On Tue, Apr 29, 2014 at 4:42 PM, Nico Williams wrote: > On Tue, Apr 29, 2014 at 6:11 PM, Martin Thomson > wrote: >> On 29 April 2014 15:02, Nico Williams wrote: >>> tls-unique is fine provided resumption isn't broken. Resumption is >>> broken. There is a proposed fix[2] that IMO is correct and works. >> >> So the proposed fix doesn't do anything about resumption, it changes > > That's quibbling. Something is broken in TLS leading to tls-unique CB > being vulnerable among other things. There is a fix that effectively > channel binds the new connection to the one being resumed, and this > naturally solves the problem. > >> the derivation of the master secret. > > Right. > >> I think that the proposed fix is the right one - one we should be >> fixing for TLS <=1.2. There are probably better options for fixing >> 1.3. > > I agree as to fixing TLS <= 1.2. I don't think there is a better > option for 1.3 (short of removing resumption, as some have proposed), > therefore it's also the correct fix for 1.3 (assuming no major changes > like dropping Finished messages as Watson Ladd proposed, which would > require updating tls-unique concurrently). There were two parts to my suggestion: the first was analogous to the proposed fix. The second was, now that the master secret depends on the handshake, dispensing with the Finished message. I wasn't proposing to do the second only: that would lead to security issues, as nothing would protect the extensions offered. I'd like to see substantial revampment of Finished. I think we do need it to prevent some trivial replays (I open a connection but don't send anything) which might be annoying in some circumstances. But I think the previous design had unnecessarily been an obstacle to academic analysis, for an annoying technical reason, and I don't see how this fix interacts with changing the Finished message in TLS 1.3. 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 SRS0=1u8P=Z6=acm.org=bmoeller@srs.kundenserver.de Wed Apr 30 05:30:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61781A08BF for ; Wed, 30 Apr 2014 05:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_9rN6ZZTJhr for ; Wed, 30 Apr 2014 05:30:14 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1EB1A0829 for ; Wed, 30 Apr 2014 05:30:14 -0700 (PDT) Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MJTPH-1WiUrA0ect-0038e2; Wed, 30 Apr 2014 14:30:11 +0200 Received: by mail-yk0-f175.google.com with SMTP id q200so1380921ykb.20 for ; Wed, 30 Apr 2014 05:30:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.86.226 with SMTP id w62mr5470541yhe.94.1398861010117; Wed, 30 Apr 2014 05:30:10 -0700 (PDT) Received: by 10.170.78.5 with HTTP; Wed, 30 Apr 2014 05:30:10 -0700 (PDT) In-Reply-To: <20140429220611.041D31ACE8@ld9781.wdf.sap.corp> References: <20140429220611.041D31ACE8@ld9781.wdf.sap.corp> Date: Wed, 30 Apr 2014 14:30:10 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba475db9992d3c04f841b53e X-Provags-ID: V02:K0:NNwkPL4izDYgInMs87Jf+x4sxRtdLiAbHZyd8fM2b3G eTTaOOWQOdCZzbvWI/+FfWntUW838H920bPohX6vmPEXIpFB/Q QQMmYqVPtxGQZlhHPzNBVHDz4e6AGMbU3DFex08vZJmA6HkuQ+ mE3gZ0BxVaoDntXe8QB9p1Gh6z5ynsLHdrw+KOsy5MtG+DRs3C feSwrw330DaGJ+fKifdpi6LCdFFwNgUOc9F6opuLbHwV2XAgkH fGGqeBJKkpSXuTmMuaPGkMVDYN9p1E8CxU3YTrXHdrvPXv52g/ Ha2SDxvndbLPi9HP0MsTcM/cHKL671VhPHsEtUVhuk84lGiTSU 3QKfiJneCRzBGCCA97bBVDmI2qvifPwzHBG9VlUDaMgr44GGT0 dlXFtilLNyAFCkD2tmIRUZR3xmeFR3i6OT9TfkxTTzbRkPx4zs P1wGN Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5z6xkdc_o2xZXsD-9hFzBy623Wk Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 12:58:25 -0000 --90e6ba475db9992d3c04f841b53e Content-Type: text/plain; charset=UTF-8 Martin Rex : > Yngve N. Pettersen wrote: > > In its ClientHello message, a client MUST either send the > > "extended_master_secret" extension, or the > > "TLS_EXTENDED_MASTER_SECRET" SCSV. Clients SHOULD NOT include both. > > > > In my opinion, the "SHOULD NOT" ought to be a "MUST NOT", *unless* the > > document also states something like "Servers MUST accept ClientHello > > messages that contain both the "extended_master_secret" extension and the > > "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only one had been > > received" > > The only problem is having two seperate indicators with the exact same > meaning in the first place. Kill the ClientHelloExtension, > have everyone use the SCSV in ClientHello all the time. > Right. Formally, we need at least an imaginary ClientHello extension for this (because, in general, "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello"), but if we're going to require servers to honor the SCSV anyway, there's no technical reason to allow clients to send something else. (Unlike the RFC 5746 secure renegotiation extension, this one never contains data, so for clients the SCSV is always sufficient.) For aesthetical reasons, maybe the SCSV should only be used if the ClientHello omits the extensions field entirely, but even that unnecessarily complicates server implementations. Bodo --90e6ba475db9992d3c04f841b53e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:
Yngve N. Pettersen wrote:

> =C2=A0 =C2=A0 In its ClientHello message, a client MUST either send th= e
> =C2=A0 =C2=A0 "extended_master_secret" extension, or the
> =C2=A0 =C2=A0 "TLS_EXTENDED_MASTER_SECRET" SCSV. =C2=A0Clien= ts SHOULD NOT include both.
>
> In my opinion, the "SHOULD NOT" ought to be a "MUST NOT= ", *unless* the
> document also states something like "Servers MUST accept ClientHe= llo
> messages that contain both the "extended_master_secret" exte= nsion and the
> "TLS_EXTENDED_MASTER_SECRET" SCSV, and treat them as if only= one had been
> received"

The only problem is having two seperate indicators with the exact sam= e
meaning in the first place. =C2=A0Kill the ClientHelloExtension,
have everyone use the SCSV in ClientHello all the time.

Right. Formally, we need at least an imaginary ClientHello= extension for this (because, in general, "An extension type MUST NOT = appear in the ServerHello unless the same extension type appeared in the co= rresponding ClientHello"), but if we're going to require servers t= o honor the SCSV anyway, there's no technical reason to allow clients t= o send something else. =C2=A0(Unlike the RFC 5746 secure renegotiation exte= nsion, this one never contains data, so for clients the SCSV is always suff= icient.)

For aesthetical reasons, maybe the SCSV should only be = used if the ClientHello omits the extensions field entirely, but even that = unnecessarily complicates server implementations.

Bodo

--90e6ba475db9992d3c04f841b53e-- From SRS0=1u8P=Z6=acm.org=bmoeller@srs.kundenserver.de Wed Apr 30 05:50: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 BB9071A6F7F for ; Wed, 30 Apr 2014 05:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXwHZvAJdxSA for ; Wed, 30 Apr 2014 05:50:21 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8FA1A6F79 for ; Wed, 30 Apr 2014 05:50:11 -0700 (PDT) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0Lbv6m-1X6nxD0RLY-00jKCr; Wed, 30 Apr 2014 14:15:59 +0200 Received: by mail-yk0-f176.google.com with SMTP id q9so1367179ykb.21 for ; Wed, 30 Apr 2014 05:15:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.51.42 with SMTP id a30mr5220204yhc.19.1398860158136; Wed, 30 Apr 2014 05:15:58 -0700 (PDT) Received: by 10.170.78.5 with HTTP; Wed, 30 Apr 2014 05:15:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 14:15:58 +0200 Message-ID: From: Bodo Moeller To: Alfredo Pironti Content-Type: multipart/alternative; boundary=bcaec50dc41ed0f89204f8418226 X-Provags-ID: V02:K0:YbEFjN4ZbgqkhsAnykFwXsh0dys2SnyeKNl1/wqcldH 8ez4052vQqkwZallXsdxgoYim5sjDYBa90/1Da2jytSHL33NUI CYQD7WVI6mIYCN+WzSBrXblaycrr5At3bDClnWEw0THXJxscIw iAokjw/AOz+q1Xq4rhFZJkKX2REakTvITqcNITEzJ23oFiS/yT bBIwj+1To4N/8oGk2BhVjl0UAbTuBDEFVzR1P/4B1mBVcxkPkr ajYPFzoGgWAC1aHWxbvTRz0FOKr5e/0Q9qmezIWH26vSIvQnsL 2m3CYX3pah73rJ9yOJxsAZQyqN1NAjlfu6p/tc6dOuLNB15pLW +vqnHKGqpzfXmqVp5QONdF8+d92Pc9Eevl6kuPF03z7TcwjQvc q1mUClcLzERF96hBt7oy5rdrUb72wfwduGSFnMABQ5I/YiZ07+ 9Akdm Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c4Ml9NAX9knikCVmUtVvOPUTXQg Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:11:47 -0000 --bcaec50dc41ed0f89204f8418226 Content-Type: text/plain; charset=UTF-8 Alfredo Pironti : I've uploaded the draft to the IETF repository [1]. > > [1] http://www.ietf.org/id/draft-bhargavan-tls-session-hash-00.txt > Thanks, but haven't we seen that this alone doesn't actually fix the problem? I think we'll need a requirement for clients and servers implementing this spec to do one of the following, because an attacker can't be expected to opt in to extended master secrets in its handshakes: (1) If the current session does not use an extended master secret, don't allow renegotiation. (2) If a session does not use an extended master secret, don't allow it to be resumed. Approach 2 arguably is cleaner, but since it would entirely prevent session resumption between updated implementations and legacy implementations, it's probably not viable to roll out immediately. Maybe for servers you'd initially want to pick either approach 1 or approach 2 depending on the particular needs (whether renegotiation is needed at all), while clients initially could allow *both* renegotiation and resumption for new sessions, where whichever comes first for a given session would disallow the other. Eventually, once support for extended master secrets is reasonably widespread, everyone should switch to approach 2. Bodo I think this is still missing a requirement for clients and servers that implement the fixed --bcaec50dc41ed0f89204f8418226 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alfr= edo Pironti <alfredo@pironti.eu>:

I've uploaded= the draft to the IETF repository [1].
= =C2=A0

Thanks, but haven't we see= n that this alone doesn't actually fix the problem? =C2=A0I think we= 9;ll need a requirement for clients and servers implementing this spec to d= o one of the following, because an attacker can't be expected to opt in= to extended master secrets in its handshakes:

(1) If the current session does not use an extended mas= ter secret, don't allow renegotiation.

(2) If = a session does not use an extended master secret, don't allow it to be = resumed.

Approach 2 arguably is cleaner, but since it would enti= rely prevent session resumption between updated implementations and legacy = implementations, it's probably not viable to roll out immediately. =C2= =A0Maybe for servers you'd initially want to pick either approach 1 or = approach 2 depending on the particular needs (whether renegotiation is need= ed at all), while clients initially could allow *both* renegotiation and re= sumption for new sessions, where whichever comes first for a given session = would disallow the other. =C2=A0Eventually, once support for extended maste= r secrets is reasonably widespread, everyone should switch to approach 2.

Bodo



=



I think this is still mis= sing a requirement for clients and servers that implement the fixed=C2=A0
--bcaec50dc41ed0f89204f8418226-- From nobody Wed Apr 30 06:20: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 AC0551A08CB for ; Wed, 30 Apr 2014 06:20:26 -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 ZaP4f1XUZwAG for ; Wed, 30 Apr 2014 06:20:25 -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 0EF641A08BB for ; Wed, 30 Apr 2014 06:20:24 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k14so1658727wgh.33 for ; Wed, 30 Apr 2014 06:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kxYOYjU5KUxWImg6F5zoCWl/GF2/fpcyFfEiuvV4tCc=; b=hjQVP7CPGMT49gYyocw8/eYsbnPyxxGI0VKsKrGhiWbk4l2qqYlfljFzhiJnwkGaP8 gRC4ikPPlcZYeUJHVzZ/GHGfGETAWprRqY86AJ31GliK8O+fxRzoi3GXx6HeRk+5BkqJ pMi1zxvRd6IerMq2oNe0mmJ6lHkcwJvfYFULgYB+xVVqzbrHwmlxtWZwBwnJN6opndZn ANUsFfxezsn/qOvNwXUiJKse5gyXJuoPkg/3E8PuRa84+JhIEZ0OshMGZ9LkNn3vbiQC quJtLM7ars6kEAXbd9+Hkn6d+mWByeyDUpKQ8BTTolEYs5gtJ2XhBXmVezVMal+4RkLM l1Bg== X-Received: by 10.180.100.234 with SMTP id fb10mr3735547wib.26.1398864023120; Wed, 30 Apr 2014 06:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.24.168 with HTTP; Wed, 30 Apr 2014 06:20:03 -0700 (PDT) In-Reply-To: References: From: Karthik Bhargavan Date: Wed, 30 Apr 2014 15:20:03 +0200 Message-ID: To: Geoffrey Keating Content-Type: multipart/alternative; boundary=f46d043748f32ff38804f8426966 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YUdtX0wZ-9jVoqaMsJ-AB30cYp8 Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:20:26 -0000 --f46d043748f32ff38804f8426966 Content-Type: text/plain; charset=UTF-8 > I read this and couldn't work out how it interacted with > renegotiation. I'm surprised there's no discussion of renegotiation > at all in section 3. Does 'handshake_messages' include: > > a) Only the first handshake; or > for each session, handshake_messages includes messages in the full handshake that set up the session. each full renegotiation handshake sets up a new session and hence a new session hash. the session hash countermeasure is meant to link resumed connection with the original connections where the session was created. independently, we still need renegotiation indication (rfc4726) to link different handshakes on the same connection. in other words, the session hash complements rfc5746, it does not replace it. I also note that the draft leaves out the (last?) 'certificate verify' > message, is that intentional? Are there any security consequences? > CertificateVerify is not part of the handshake_messages on purpose, since the SSL 3.0 CertificateVerify message uses the master secret. So, to be backward compatible with SSL 3.0, we need to compute the master secret before this message. Is there a ciphersuite where the CertificateVerify message carries new contextual information that is not present in the previous messages? In the key exchanges we have looked at, excluding this message seems to be safe (e.g. the client certificate is in a previous Certificate message). -K > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043748f32ff38804f8426966 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
I read this and couldn't work out how it interacted with
renegotiation. =C2=A0I'm surprised there's no discussion of renegot= iation
at all in section 3. =C2=A0Does 'handshake_messages' include:

a) Only the first handshake; or

for eac= h session, handshake_messages includes messages in the full handshake that = set up the session.
each full renegotiation handshake sets up a new sess= ion and hence a new session hash.

the session hash countermeasure is meant to link resumed con= nection with the original connections where the session was created.
independently, we still need renegotiation indication (rfc4726) to = link different handshakes on the same connection.
in other words, the session hash complements rfc5746, it does no= t replace it.

I also note that the draft leaves out the (last?) 'certificate verify&#= 39;
message, is that intentional? =C2=A0Are there any security consequences?

CertificateVerify is not part of the hand= shake_messages on purpose, since the SSL 3.0 CertificateVerify message uses= the master secret.
So, to be backward compatible with SSL 3.0, we need to compute the master s= ecret before this message.

Is there a ciphersuite where t= he CertificateVerify message carries new contextual information that is not= present in the previous messages?
In the key exchanges we have looked at, excluding this message seems to be = safe (e.g. the client certificate is in a previous Certificate message).
-K
=C2=A0

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

--f46d043748f32ff38804f8426966-- From nobody Wed Apr 30 06: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 2AED71A08BB for ; Wed, 30 Apr 2014 06:25:34 -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 aH8DONKQ1dZR for ; Wed, 30 Apr 2014 06:25:32 -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 D49F11A08C3 for ; Wed, 30 Apr 2014 06:25:31 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so9127148wib.2 for ; Wed, 30 Apr 2014 06:25: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:from:date:message-id:subject:to :cc:content-type; bh=w4zsZXi5enavItWQ+NII+4IiC4HinS5Yl0/Es1tFR/g=; b=uPY74l7yW1C3SMme9WspLqmlgbOG/1gxoQIb7bMyU3cw/6pR8ySzAgo8TFn4X/z6wO /346TTPk09lE4IFIdygKhvJvFI0QbsETzFnHBLvoQQe8Kc5+J9lhwagL3j+fNwDIZXsi mi/6Ap/MyI2mdIIjONllWoPp1+zAoHSkNbiQGgBdaRh6T5cHVFhH3ZufYIHipYi/hCZB hq/OUAGPoBUC/h8NXf/K8vnHh7cg2ePfXGUdqe2GVtNwvc+bDrcThz3p1DiTCTk60ZeE 2jno6Dcsic7oCU3tqull9FaRY28+7fp6tsOhce2hchFRrYFnZm/+cCW2u8pybvZ+OELB uNsQ== X-Received: by 10.180.211.239 with SMTP id nf15mr3692774wic.9.1398864329875; Wed, 30 Apr 2014 06:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.24.168 with HTTP; Wed, 30 Apr 2014 06:25:09 -0700 (PDT) In-Reply-To: References: From: Karthik Bhargavan Date: Wed, 30 Apr 2014 15:25:09 +0200 Message-ID: To: Bodo Moeller Content-Type: multipart/alternative; boundary=001a11c264ec78a82904f8427bbe Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VgBgHWFEa3l-cOYa6hxswlYm0PI Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 13:25:34 -0000 --001a11c264ec78a82904f8427bbe Content-Type: text/plain; charset=UTF-8 On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller wrote > > >> > Thanks, but haven't we seen that this alone doesn't actually fix the > problem? I think we'll need a requirement for clients and servers > implementing this spec to do one of the following, because an attacker > can't be expected to opt in to extended master secrets in its handshakes: > > (1) If the current session does not use an extended master secret, don't > allow renegotiation. > > (2) If a session does not use an extended master secret, don't allow it to > be resumed. > I agree that the first approach is probably more palatable for legacy applications. We should require no-renegotiation, and strongly recommend that application not use channel bindings or exported TLS keys (or PRFs) in this case. > > Approach 2 arguably is cleaner, but since it would entirely prevent > session resumption between updated implementations and legacy > implementations, it's probably not viable to roll out immediately. Maybe > for servers you'd initially want to pick either approach 1 or approach 2 > depending on the particular needs (whether renegotiation is needed at all), > while clients initially could allow *both* renegotiation and resumption for > new sessions, where whichever comes first for a given session would > disallow the other. Eventually, once support for extended master secrets > is reasonably widespread, everyone should switch to approach 2. > > Bodo > > > > > > > I think this is still missing a requirement for clients and servers that > implement the fixed > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c264ec78a82904f8427bbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


=

Approach 2 arguably is cleaner, but since it would enti= rely prevent session resumption between updated implementations and legacy = implementations, it's probably not viable to roll out immediately. =C2= =A0Maybe for servers you'd initially want to pick either approach 1 or = approach 2 depending on the particular needs (whether renegotiation is need= ed at all), while clients initially could allow *both* renegotiation and re= sumption for new sessions, where whichever comes first for a given session = would disallow the other. =C2=A0Eventually, once support for extended maste= r secrets is reasonably widespread, everyone should switch to approach 2.

Bodo



=



I think this is still mis= sing a requirement for clients and servers that implement the fixed=C2=A0

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


--001a11c264ec78a82904f8427bbe-- From nobody Wed Apr 30 15:05: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 C16A81A09AC for ; Wed, 30 Apr 2014 15:05:01 -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 Fl4sA7ZZoniO for ; Wed, 30 Apr 2014 15:05:00 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id EC5951A094C for ; Wed, 30 Apr 2014 15:04:59 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5DF7633D04B; Wed, 30 Apr 2014 22:04:58 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Karthik Bhargavan References: From: Geoffrey Keating Date: 30 Apr 2014 15:04:58 -0700 In-Reply-To: Message-ID: Lines: 37 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/wvAolvozUL7n0sY6ZCNbN2HVOko Cc: "tls@ietf.org" Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 22:05:02 -0000 Karthik Bhargavan writes: > > I read this and couldn't work out how it interacted with > > renegotiation. I'm surprised there's no discussion of renegotiation > > at all in section 3. Does 'handshake_messages' include: > > > > a) Only the first handshake; or > > > > for each session, handshake_messages includes messages in the full > handshake that set up the session. > each full renegotiation handshake sets up a new session and hence a new > session hash. > > the session hash countermeasure is meant to link resumed connection with > the original connections where the session was created. > independently, we still need renegotiation indication (rfc4726) to link > different handshakes on the same connection. > in other words, the session hash complements rfc5746, it does not replace > it. So, I think the draft actually means b out of my original list of choices. I would not have guessed that. The draft definitely needs to explain this. The draft should also say something about requiring RFC5746. Would it be better if we tweaked this draft so that if you use it you don't need RFC5746? It would be easy to do so and would make the analysis simpler. You could just include the previous Finished messages in the hash, I think. There should also be something in the security considerations section about message sequence. Some implementations might accept, say, a second ServerCertificate message before the Finished, which would probably be bad. From nobody Wed Apr 30 15:10: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 D95601A09B8 for ; Wed, 30 Apr 2014 15:09: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 2hklQTdnuX8k for ; Wed, 30 Apr 2014 15:09:58 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 429FD1A094C for ; Wed, 30 Apr 2014 15:09:58 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 87DDA1E05D for ; Wed, 30 Apr 2014 15:09:56 -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=MCKC3cK2CeyqMOmg9BIE y8hukCY=; b=YK2xqz+TtgpM5EJvaIlnaS7WM+0MnhxKePED+2lE2WpXydXY9PEl 4YpziLEoApMuv1kI46Co9niaKzEmE6Yzhtq3ZLBa1/5JViz6+JIP97TivUj9sExw bAwVDhAKKVtEDBDLElTY2N4H92qTBaQ9fxuQnj1Bqkb8Q8tJlD8gVVE= 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-a95.g.dreamhost.com (Postfix) with ESMTPSA id 360BC1E059 for ; Wed, 30 Apr 2014 15:09:56 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id u57so2344080wes.13 for ; Wed, 30 Apr 2014 15:09:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr3942803wjr.67.1398895795071; Wed, 30 Apr 2014 15:09:55 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Wed, 30 Apr 2014 15:09:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Apr 2014 17:09:54 -0500 Message-ID: From: Nico Williams To: Karthik Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wmcVJcaknBPjhXKX6MsHGeloYgk Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] Triple Handshake Fix. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 22:09:59 -0000 On Wed, Apr 30, 2014 at 8:25 AM, Karthik Bhargavan wrote: > On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller wrote >> Thanks, but haven't we seen that this alone doesn't actually fix the >> problem? I think we'll need a requirement for clients and servers >> implementing this spec to do one of the following, because an attacker can't >> be expected to opt in to extended master secrets in its handshakes: >> >> (1) If the current session does not use an extended master secret, don't >> allow renegotiation. >> >> (2) If a session does not use an extended master secret, don't allow it to >> be resumed. Why not both? > I agree that the first approach is probably more palatable for legacy > applications. We should require no-renegotiation, and strongly recommend > that application not use channel bindings or exported TLS keys (or PRFs) in > this case. That's difficult. It requires first-class APIs for getting CB, which many libraries lack. Nico --