From nobody Sat Aug 1 01:48:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B51B2C05 for ; Sat, 1 Aug 2015 01:48: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 jzhyTwH000vr for ; Sat, 1 Aug 2015 01:48:53 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3F01B2B63 for ; Sat, 1 Aug 2015 01:48:52 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id D144D699EE; Sat, 1 Aug 2015 11:48:49 +0300 (EEST) Date: Sat, 1 Aug 2015 11:48:49 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20150801084849.GA7162@LK-Perkele-VII> References: <20150720141036.GA32204@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: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 08:48:55 -0000 > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > > > Are you intending that this mechanism be enabled by default for HTTP/2 or > > would the prohibition against renego still apply? Without any way for the > > client to tie the CertificateRequest to the HTTP request that triggered it, > > this mechanism would have many of the same problems as renego as far as > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > > suppose.) Even if there would be way to tie it to request that triggered the request, it would still IMO have some of the nastiest problems of renegotiation, especially in context of HTTP/2 in web (the privilege involved is almost impossible to handle in any sane way). What I think would be very useful: A way for client to signal it has a client certificate it expects to use, regardless of if valid configuration is known. The vast majority of times client certificate is used, the client knows about that before initiating a connection. IMO, the proper way to handle "this resource requires client certificate" is for server to signal that in application protocol and then client to establish a new connection with client certificate (or if application protocol supports it, do the authentication at application layer without ever involving TLS, except for channel binding). -Ilari From nobody Sat Aug 1 14:16:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889751A1EF6 for ; Sat, 1 Aug 2015 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N72lonhQ5wX9 for ; Sat, 1 Aug 2015 14:16:45 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96D41A1C06 for ; Sat, 1 Aug 2015 14:16:45 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) id 1ZLe94-000550-Ad; Sat, 01 Aug 2015 23:16:42 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84) (envelope-from ) id 1ZLe94-0006qk-5y; Sat, 01 Aug 2015 23:16:42 +0200 From: Florian Weimer To: Hubert Kario References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <20150728160154.GU4347@mournblade.imrryr.org> <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com> Date: Sat, 01 Aug 2015 23:16:42 +0200 In-Reply-To: <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com> (Hubert Kario's message of "Wed, 29 Jul 2015 11:59:41 +0200") Message-ID: <871tfm1zgl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] No cypher overlap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 21:16:47 -0000 * Hubert Kario: > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: >> In that case, it should be said that a client MUST NOT advertise >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers >> (or perhaps less restrictive at least one TLS 1.3 compatible cipher). > > MTI does not mean Mandatory To Enable Are you sure? That's extremely surprising. Of course, people are free to run the servers in odd configuration, but my understanding is that's not TLS anymore. From nobody Sat Aug 1 14:19:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D1F1A1EFE for ; Sat, 1 Aug 2015 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVFBT1B_9V2X for ; Sat, 1 Aug 2015 14:19:16 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3C11A1C06 for ; Sat, 1 Aug 2015 14:19:16 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) id 1ZLeBW-00055i-Il; Sat, 01 Aug 2015 23:19:14 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84) (envelope-from ) id 1ZLeBW-0006v9-FN; Sat, 01 Aug 2015 23:19:14 +0200 From: Florian Weimer To: Viktor Dukhovni References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <20150728160154.GU4347@mournblade.imrryr.org> Date: Sat, 01 Aug 2015 23:19:14 +0200 In-Reply-To: <20150728160154.GU4347@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 28 Jul 2015 16:01:55 +0000") Message-ID: <87wpxezoz1.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] No cypher overlap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 21:19:17 -0000 * Viktor Dukhovni: > In that case, it should be said that a client MUST NOT advertise > TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers > (or perhaps less restrictive at least one TLS 1.3 compatible cipher). Or the server should negotiate TLS 1.2 instead. Servers should already do something similar today: For an extension-less TLS 1.2 handshake, they should negotiate TLS 1.1 instead, to get a stronger PRF. From nobody Sun Aug 2 07:35:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477151A8761 for ; Sun, 2 Aug 2015 07:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPLYd4iuhgnH for ; Sun, 2 Aug 2015 07:35:46 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F391A1B77 for ; Sun, 2 Aug 2015 07:35:45 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 1F36D44796; Sun, 2 Aug 2015 16:35:43 +0200 (CEST) X-purgate-ID: 152705::1438526143-0000413A-71D365DC/0/0 X-purgate-size: 2481 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 10F8A40A23; Sun, 2 Aug 2015 16:35:43 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 05C621A21C; Sun, 2 Aug 2015 16:35:43 +0200 (CEST) In-Reply-To: <87wpxezoz1.fsf@mid.deneb.enyo.de> To: Florian Weimer Date: Sun, 2 Aug 2015 16:35:42 +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: <20150802143543.05C621A21C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] No cypher overlap 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: Sun, 02 Aug 2015 14:35:48 -0000 Florian Weimer wrote: > * Viktor Dukhovni: > >> In that case, it should be said that a client MUST NOT advertise >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers >> (or perhaps less restrictive at least one TLS 1.3 compatible cipher). > > Or the server should negotiate TLS 1.2 instead. > > Servers should already do something similar today: For an > extension-less TLS 1.2 handshake, they should negotiate TLS 1.1 > instead, to get a stronger PRF. The facts and reasoning in this short statement is flawed. The TLSv1.2 PRF uses SHA256 throughout, and the hash of the PRF in TLS is *NOT* negotiated through extensions, but through TLS cipher suites (which do not need extensions). TLSv1.2 has exactly one mandatory to implement ciphersuite: https://tools.ietf.org/html/rfc5246#section-9 TLS_RSA_WITH_AES_128_CBC_SHA and this cipher suite works perfectly fine without TLS extensions, and will be used with a SHA-1 PRF for TLSv1.0 & TLSv1.1 and with a SHA-256 PRF with TLSv1.2. The highest security level (in the NIST SP800-57 part1 sense) that you can get with this cipher suite is the equivalent of 128-bit -- but that requires that you use server certificates with RSA keys of at least 3072-bit. The most commonly used server certificates today use 2048-bit RSA keys and limit the security to 112-bit. The use of a SHA-1 PRF in TLSv1.0 and TLSv1.1 is perfectly OK with NIST SP800-57 part1 for 128-bit security. The "weakness" of extension-less TLSv1.2 affects only the the weakened digitally-signed transform and the behaviour suggested in rfc5246 section 7.4.1.4.1 for the absence of the signature_algorithms extension, and the incredibly behaviour that some implementations exhibit. In the history of TLS RFCs there are two examples of completely botched descriptions of default behaviour for a TLS extension when it is not sent. The first extreme is in the informational document rfc4492 (TLS cipher suites with Elliptic Curves), where it says, when the extension is absent, assume that the peer supports *EVERYTHING*. The opposite extreme nonsense is what TLSv1.2 describes for the TLSv1.2 signature extension when the extension is not sent, because it suggest a braindead self-limitation to an algorithm that had already been deprecated and end-of-lifed with only 2 years left when TLSv1.2 was published, and no such limitation exists in earlier TLS versions. -Martin From nobody Sun Aug 2 08:38:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADB31A87BC for ; Sun, 2 Aug 2015 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 NBaqP2lMgdMD for ; Sun, 2 Aug 2015 08:38:11 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78BA1A8783 for ; Sun, 2 Aug 2015 08:38:10 -0700 (PDT) Received: by ioeg141 with SMTP id g141so125105059ioe.3 for ; Sun, 02 Aug 2015 08:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ECnFlzvipYxb7kv6r0ITn7bHQXe1KHNga8tGOtFBrNk=; b=jEFGFhcuMXC9bEdt3hgg1hAgD/saTkU7BIqtx+1+SQqRp4jvqiY+E5YMNbneBpCDQk 1ez5RGijU+tTb+ADJriBz/1NuS75rFIdPIMTMWz+TEhk81aX0ACmSw7+ppplcSksRbQi Ff/LkkLICnF+ZKzdPYKR5Pkz2gKyr4KJY4C40= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ECnFlzvipYxb7kv6r0ITn7bHQXe1KHNga8tGOtFBrNk=; b=E4zP88DfKE4b+6ioNd0U05bV5xxi5dYA+7OfGVxen+GEHXAb3qv59yjd3zUgNnlbvR GbEj5HcgCRNAuKupVh9QILG/ymU4DsBNecUrptm9uVH8LZDwbK56bV+OnBnz3TBfpp1b vXlFDCkFlhO3G/DrXhaaVXMzTE+nBwijk8ecKBMPE7nwlchQnxfHHc53xb31cnX/fdF3 2JX/rnpZpk2KQJp1ps2iNkyAYALsAvGzh8BldSQ2/PbbqqyROFxhWks6lEp33K+Hh0LV JdKEwFJUxLcr+8r3LASLWsQ4sZFOHOP6ALCQwA5xuevyB2CO0ZmQ1TRNX94L6T69+H2T 9t7A== X-Gm-Message-State: ALoCoQkSKZGZPaOtGXiiPanHS0eaXk79pAtxCPB/esylT8BMCDfarktGaw3ZCEvF6Lyn4Cn6LnK2 X-Received: by 10.107.137.95 with SMTP id l92mr16022265iod.2.1438529890168; Sun, 02 Aug 2015 08:38:10 -0700 (PDT) MIME-Version: 1.0 References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> In-Reply-To: <20150801084849.GA7162@LK-Perkele-VII> From: David Benjamin Date: Sun, 02 Aug 2015 15:38:00 +0000 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113ecbfe1a67e4051c55d7b8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 15:38:12 -0000 --001a113ecbfe1a67e4051c55d7b8 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara wrote: > > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin > wrote: > > > > > Are you intending that this mechanism be enabled by default for HTTP/2 > or > > > would the prohibition against renego still apply? Without any way for > the > > > client to tie the CertificateRequest to the HTTP request that > triggered it, > > > this mechanism would have many of the same problems as renego as far as > > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around > for a > > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > > > suppose.) > > Even if there would be way to tie it to request that triggered the request, > it would still IMO have some of the nastiest problems of renegotiation, > especially in context of HTTP/2 in web (the privilege involved is almost > impossible to handle in any sane way). > > > What I think would be very useful: A way for client to signal it has a > client certificate it expects to use, regardless of if valid configuration > is known. The vast majority of times client certificate is used, the > client knows about that before initiating a connection. > Unless I misunderstand you, this isn't true for a browser. Browsers only look for client certificates based on a CertificateRequest message. Some platforms, like Android, don't even let you list the user's certificate store. Instead there's an API to show a trusted certificate picker prompt. Or, given the paragraph below, are you suggesting that we'd start a second connection on receiving CertificateRequest and only advertise it then? Yeah, that's actually how Chrome implements client auth anyway. We always start a second connection with a client certificate configured, even if the server sent CertificateRequest on a renego. It makes a few things simpler. > IMO, the proper way to handle "this resource requires client certificate" > is for server to signal that in application protocol and then client to > establish a new connection with client certificate (or if application > protocol supports it, do the authentication at application layer without > ever involving TLS, except for channel binding). Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, and I don't want to allow this mechanism for it either. I consider renego-based per-resource client auth in HTTP/1.1 to be a legacy mistake we're currently stuck with. (It's the only reason we ever have to renego. In BoringSSL, we've settled on stripping renego down to the bare minimum needed to support this. Simplifies a lot of stuff.) I'm guessing Microsoft has different constraints/goals, given this proposal and TLS_RENEG_PERMITTED, so if we must have it in the transport, I'd rather it be some opt-in corner that I don't have to deal with. (Applications can return HTTP_1_1_REQUIRED in HTTP/2 if they really must do per-resource client auth.) But I do agree this is a problematic mechanism and don't think it belongs in TLS. Let the application layer do it with a channel binding. No need for new connections, and no messy questions about scope and multi-request protocols. David --001a113ecbfe1a67e4051c55d7b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 1,= 2015 at 4:48 AM Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Jul 28, 2015 at 6:28 PM David Benjamin <davidben@google.com<= /a>> wrote:
>
> > Are you intending that this mechanism be enabled by default for H= TTP/2 or
> > would the prohibition against renego still apply? Without any way= for the
> > client to tie the CertificateRequest to the HTTP request that tri= ggered it,
> > this mechanism would have many of the same problems as renego as = far as
> > HTTP/2 is concerned. (I realize Microsoft has a draft floating ar= ound for a
> > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this = too I
> > suppose.)

Even if there would be way to tie it to request that triggered the request,=
it would still IMO have some of the nastiest problems of renegotiation,
especially in context of HTTP/2 in web (the privilege involved is almost impossible to handle in any sane way).


What I think would be very useful: A way for client to signal it has a
client certificate it expects to use, regardless of if valid configuration<= br> is known. The vast majority of times client certificate is used, the
client knows about that before initiating a connection.

Unless I misunderstand you, this isn't true for a brow= ser. Browsers only look for client certificates based on a CertificateReque= st message. Some platforms, like Android, don't even let you list the u= ser's certificate store. Instead there's an API to show a trusted c= ertificate picker prompt.

Or, given the paragraph below, are = you suggesting that we'd start a second connection on receiving Certifi= cateRequest and only advertise it then? Yeah, that's actually how Chrom= e implements client auth anyway. We always start a second connection with a= client certificate configured, even if the server sent CertificateRequest = on a renego. It makes a few things simpler.
=C2=A0
IMO, the proper way to handle "this resource requires client certifica= te"
is for server to signal that in application protocol and then client to
establish a new connection with client certificate (or if application
protocol supports it, do the authentication at application layer without ever involving TLS, except for channel binding).

Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/= 2, and I don't want to allow this mechanism for it either.=C2=A0I consi= der renego-based per-resource client auth in HTTP/1.1 to be a legacy mistak= e we're currently stuck with. (It's the only reason we ever have to= renego. In BoringSSL, we've settled on stripping renego down to the ba= re minimum needed to support this. Simplifies a lot of stuff.)
I'm guessing Microsoft has different constraints/goals, given this pr= oposal and TLS_RENEG_PERMITTED, so if we must have it in the transport, I&#= 39;d rather it be some opt-in corner that I don't have to deal with. (A= pplications can return HTTP_1_1_REQUIRED in HTTP/2 if they really must do p= er-resource client auth.) But I do agree this is a problematic mechanism an= d don't think it belongs in TLS. Let the application layer do it with a= channel binding. No need for new connections, and no messy questions about= scope and multi-request protocols.

David
--001a113ecbfe1a67e4051c55d7b8-- From nobody Sun Aug 2 11:29:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E753E1A802E for ; Sun, 2 Aug 2015 11:29:13 -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 CYctnzXy4xd2 for ; Sun, 2 Aug 2015 11:29:11 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB061A802A for ; Sun, 2 Aug 2015 11:29:11 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DCB8469996; Sun, 2 Aug 2015 21:29:08 +0300 (EEST) Date: Sun, 2 Aug 2015 21:29:08 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20150802182908.GA29836@LK-Perkele-VII> References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@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: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 18:29:14 -0000 On Sun, Aug 02, 2015 at 03:38:00PM +0000, David Benjamin wrote: > On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara > wrote: > > > > What I think would be very useful: A way for client to signal it has a > > client certificate it expects to use, regardless of if valid configuration > > is known. The vast majority of times client certificate is used, the > > client knows about that before initiating a connection. > > Unless I misunderstand you, this isn't true for a browser. Browsers only > look for client certificates based on a CertificateRequest message. Some > platforms, like Android, don't even let you list the user's certificate > store. Instead there's an API to show a trusted certificate picker prompt. Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. There one likely "preconfigures" client certificates if needed. > Or, given the paragraph below, are you suggesting that we'd start a second > connection on receiving CertificateRequest and only advertise it then? > Yeah, that's actually how Chrome implements client auth anyway. We always > start a second connection with a client certificate configured, even if the > server sent CertificateRequest on a renego. It makes a few things simpler. Doesn't that count as "knowing about client certificate before connecting" (even if the knowledge has been received split-second before TLS handshake starts)? Also, signaling can be at application layer, as talked about below. > > IMO, the proper way to handle "this resource requires client certificate" > > is for server to signal that in application protocol and then client to > > establish a new connection with client certificate (or if application > > protocol supports it, do the authentication at application layer without > > ever involving TLS, except for channel binding). > > Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, and I > don't want to allow this mechanism for it either. I consider renego-based > per-resource client auth in HTTP/1.1 to be a legacy mistake we're currently > stuck with. (It's the only reason we ever have to renego. In BoringSSL, > we've settled on stripping renego down to the bare minimum needed to > support this. Simplifies a lot of stuff.) Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)... Good thing it is banned. > I'm guessing Microsoft has different constraints/goals, given this proposal > and TLS_RENEG_PERMITTED, so if we must have it in the transport, I'd rather > it be some opt-in corner that I don't have to deal with. (Applications can > return HTTP_1_1_REQUIRED in HTTP/2 if they really must do per-resource > client auth.) But I do agree this is a problematic mechanism and don't > think it belongs in TLS. Let the application layer do it with a channel > binding. No need for new connections, and no messy questions about scope > and multi-request protocols. Summary of what auth modes I think are needed: - TLS-level client certificate auth on client request on connect (this currently can't be cleanly done, sometimes one even sees that "renego immediately to provoke CR" hack). - Application-level client auth (via CB capability of TLS). -Ilari From nobody Mon Aug 3 04:36:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654991A8779 for ; Mon, 3 Aug 2015 04:36:34 -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_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 YfnlHcTS8HS6 for ; Mon, 3 Aug 2015 04:36:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444311A8799 for ; Mon, 3 Aug 2015 04:36:31 -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 (Postfix) with ESMTPS id 8E95F923B3; Mon, 3 Aug 2015 11:36:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-122.brq.redhat.com [10.34.0.122]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t73BaSbL007205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2015 07:36:30 -0400 From: Hubert Kario To: Florian Weimer Date: Mon, 03 Aug 2015 13:36:22 +0200 Message-ID: <2591292.9iByWAuqya@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.3-200.fc22.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <871tfm1zgl.fsf@mid.deneb.enyo.de> References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com> <871tfm1zgl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3429121.iyH3O6k2kQ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] No cypher overlap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 11:36:34 -0000 --nextPart3429121.iyH3O6k2kQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 01 August 2015 23:16:42 Florian Weimer wrote: > * Hubert Kario: > > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: > >> In that case, it should be said that a client MUST NOT advertise > >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers > >> (or perhaps less restrictive at least one TLS 1.3 compatible ciphe= r). > >=20 > > MTI does not mean Mandatory To Enable >=20 > Are you sure? That's extremely surprising. yes, I'm sure: per https://tools.ietf.org/html/rfc5246#page-65 >9. Mandatory Cipher Suites > > In the absence of an application profile standard specifying > otherwise, a TLS-compliant application MUST implement the cipher > suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the > definition). =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart3429121.iyH3O6k2kQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJVv1I2AAoJEJKo0bgB0vX1eRoP/0rRqU/Ah/p67HeU33vN0m74 nmJU+/oKnIsJ+Luz0l0H0KVs39yE10iqfZUyrl52HtN3I+RERMtMHGTlvAKc+TYY zEF6AycHfOY2SAC2Ufiob8QCn+kycL8Lv+xqQfNmTgl6eyGPbG/rIPXJrNPLWGQk 3+4etBJX/JRadVq7ULUoDgY1vdQkVqffLlvmJnJe4N1TlXGNy7D/XRBfqn1wDVZC 8CmNkapHQMabFT7ntQ2GL3boW+mb3HPK4yk9QwTM/EqltjCeBwqtJ2nFcTRcMci9 Th6gNaFKwiX1Llz5DJOHuroEp68SSXkDOrWMX613TmB+GUQKvRdqoaxFD2B01utZ YUBO9LtoHsubdVnsYmeqwAlYj1nboXf0VXxqoJ1q868RER/NTMLcxmvg0NgH/VyJ KHtScJ6uwRzEaBbTw+mnBaC1CIurbvIYuloc0xz3hFdDDHTgVMx2nafWEssoVB7S RF5ToJPvqgMKqZ8JiIBuIRp7RgbvotewdUdY8x4GGkQrJh++McDKtHyu9dTo3bqb w6Rem2Zx5BZWE7qPogcdsympQu5nwdClt/SeU4szSR3t3hG/xCW2vq8oQsBE1PBX ZX6L7W8ryrZ1DRM3897lsVFHa4ajsSumXgzp574xPNH7WZWcKvon3/eU7PPDp/40 ULn/ZepXJ67BcAM676eF =S1Bf -----END PGP SIGNATURE----- --nextPart3429121.iyH3O6k2kQ-- From nobody Mon Aug 3 07:29:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D41A0395 for ; Mon, 3 Aug 2015 07:29:52 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYXw9JWcS08H for ; Mon, 3 Aug 2015 07:29:47 -0700 (PDT) Received: from gateway30.websitewelcome.com (gateway30.websitewelcome.com [50.116.126.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C5D1A00C7 for ; Mon, 3 Aug 2015 07:29:47 -0700 (PDT) Received: by gateway30.websitewelcome.com (Postfix, from userid 500) id CAC63229CC2A; Mon, 3 Aug 2015 09:29:46 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway30.websitewelcome.com (Postfix) with ESMTP id B5226229CB90 for ; Mon, 3 Aug 2015 09:29:46 -0500 (CDT) Received: from [96.231.221.219] (port=53526 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZMGkL-00045S-Te; Mon, 03 Aug 2015 09:29:46 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> Date: Mon, 3 Aug 2015 10:29:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77F6EFC0-D544-4004-81B0-7CCE5B4DAE0D@ieca.com> References: <201507221307.10279.davemgarrett@gmail.com> <67B411CE-E6DD-4BC4-BEE5-1513C5C3D0AE@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) 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.221.219 X-Exim-ID: 1ZMGkL-00045S-Te X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:53526 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 4492 ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:29:52 -0000 On Jul 22, 2015, at 13:12, Yoav Nir wrote: > I=92d like to hear from the chairs if it=92s OK to rename stuff in the = IANA registry. It is fine to rename stuff in the registries. As Dave pointed out we = just did that in the FFDHE draft. Just make sure to put the = instructions about what to rename and what to rename it to in the IANA = considerations section. spt= From nobody Mon Aug 3 12:13:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A551ACD0C for ; Mon, 3 Aug 2015 12:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t6D_QWthDwCQ for ; Mon, 3 Aug 2015 12:13:25 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05901ACD01 for ; Mon, 3 Aug 2015 12:13:24 -0700 (PDT) Received: from latte.josefsson.org (host-78-65-208-9.homerun.telia.com [78.65.208.9]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t73JDAFi014934 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 3 Aug 2015 21:13:12 +0200 From: Simon Josefsson To: Hubert Kario References: <8087760.Ce9A43SzlW@pintsize.usersys.redhat.com> <2289724.pXJjcWpFTc@pintsize.usersys.redhat.com> <871tfm1zgl.fsf@mid.deneb.enyo.de> <2591292.9iByWAuqya@pintsize.usersys.redhat.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150803:hkario@redhat.com::mnYv2//llt2a8YRs:EogG X-Hashcash: 1:22:150803:tls@ietf.org::tHHklkFfsgUwoCrQ:B+mw X-Hashcash: 1:22:150803:fw@deneb.enyo.de::CObVuu2aDI4DdAKy:HV70 Date: Mon, 03 Aug 2015 21:13:09 +0200 In-Reply-To: <2591292.9iByWAuqya@pintsize.usersys.redhat.com> (Hubert Kario's message of "Mon, 03 Aug 2015 13:36:22 +0200") Message-ID: <87io8w6v96.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Florian Weimer , tls@ietf.org Subject: Re: [TLS] No cypher overlap X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:13:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hubert Kario writes: > On Saturday 01 August 2015 23:16:42 Florian Weimer wrote: >> * Hubert Kario: >> > On Tuesday 28 July 2015 16:01:55 Viktor Dukhovni wrote: >> >> In that case, it should be said that a client MUST NOT advertise >> >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers >> >> (or perhaps less restrictive at least one TLS 1.3 compatible cipher). >> >=20 >> > MTI does not mean Mandatory To Enable >>=20 >> Are you sure? That's extremely surprising. > > yes, I'm sure: > > per https://tools.ietf.org/html/rfc5246#page-65 > >>9. Mandatory Cipher Suites >> >> In the absence of an application profile standard specifying >> otherwise, a TLS-compliant application MUST implement the cipher >> suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the >> definition). I don't read anything about enable in deployments here? Having code implementing something does not prevent configuration (and even default settings) to disable something. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVv71FAAoJEIYLf7sy+BGdDK8H/AiGEw4z8sPIupnGmJJnnK4r tqlk+9x7LEZ++HoBMkrnDC+7LXcvMYa4hk/6wtf7iPayN1a7qix9AH3pGxtUvmIw HAoBHt07E1tZqZjGrMq1p50lyAEeZIg8P/qd6wTMLonnPmtDPmQfM9ysZmiyiEfJ 78LSWp8HZMfFboMohtiP/ZRUWrHgZN4Yulc9XfEoH8NBn5bpi6o1Jz35ZHZSOWR2 JNV/m0DEO/heOMDGcnroq1uwntYlxVY6eohE6AVfoTC8PPZjh6eRtSy69/pYu+xT 0D9rFk6Uz8pMz5lW51Mmo0nhx80lEuSCImGrDpd0yDHnB7JzVSgcQnbYHfpvx0o= =M1L8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 17:21:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE541B2A5D for ; Mon, 3 Aug 2015 17:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k4CZCJupSEHA for ; Mon, 3 Aug 2015 17:21:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64E11B2A5C for ; Mon, 3 Aug 2015 17:21:06 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 00:21:02 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 00:21:02 +0000 From: Andrei Popov To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Review of PR #209 Thread-Index: AQHQxuqZE5b0AgbP4UGzDBeqZzcHy537BwWQ Date: Tue, 4 Aug 2015 00:21:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:K4wKqBzWuUSC1rqP/L87mSQhNCvqoWa2Nxdn+e4QB0rwBJijPVhTjWSxYIpjLsqopKmDWof34OszEUvBIl2DI6a8NeaqvZZxC2rbZc073y+hRhm3BXqmyGpuC9CJhr6z0EDi1jf5qginooMFUVE1GQ==; 24:IhTHbalb8NjFo6tC429fMtUNTe+xy3NT85keBC1ohVo6VYPhJvd/8pjd1mXrE41IlKPOC2mW4XR2U4fbr24COY6QnvlMGOBxVPiiPycmWHU=; 20:YKqWSn6DGev1ygpLBqspDSaqonKzirNFzeYpRQFF7xyM9nuLlAcyGfcvKnh8+afsAu49tI6BA4w4f+jPUKJbDg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(51444003)(13464003)(92566002)(2950100001)(2900100001)(62966003)(81156007)(122556002)(106116001)(106356001)(105586002)(2501003)(5002640100001)(189998001)(68736005)(77096005)(40100003)(107886002)(4001540100001)(97736004)(5001960100002)(64706001)(5001770100001)(15975445007)(5003600100002)(102836002)(5001830100001)(5001860100001)(19580405001)(77156002)(101416001)(19580395003)(87936001)(10090500001)(33656002)(2656002)(76576001)(99286002)(76176999)(86612001)(74316001)(86362001)(46102003)(50986999)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 00:21:02.0728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Subject: Re: [TLS] Review of PR #209 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:21:09 -0000 > use CertificateRequest within the handshake, and the new content type out= side of it Would the client then also use this new content type for Certificate and Ce= rtificateVerify messages (when these are sent after the handshake is comple= te)? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Saturday, July 25, 2015 8:00 AM To: tls@ietf.org Subject: [TLS] Review of PR #209 Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209 The first expands the ways in which a server can identify certificates. Th= is is fine. I do wonder whether we can remove CertificateType entirely for= TLS 1.3 though (that can be done separately). The second is worrisome. I don't like that a handshake message now has two= different potential locations that it might appear in. That seems like a = hazard. I think that we need a new content type for a new message that can= be used after the handshake completes. Then there are two options: a) remove CertificateRequest from the handshake entirely and allow the han= dshake to complete before authenticating (this has a number of hazards that= make it probably worse than the duplication it addresses) b) use CertificateRequest within the handshake, and the new content type o= utside of it _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Aug 3 17:38:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316A71B3251 for ; Mon, 3 Aug 2015 17:38: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 aUIlicUJOjwm for ; Mon, 3 Aug 2015 17:38:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A575A1B325D for ; Mon, 3 Aug 2015 17:38:08 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 00:37:47 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 00:37:47 +0000 From: Andrei Popov To: Ilari Liusvaara , David Benjamin Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQ Date: Tue, 4 Aug 2015 00:37:47 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> In-Reply-To: <20150802182908.GA29836@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:Hmm+vOOwq0xdYgbphlKRl9En98ktj8nDb//TSAVho23XbrJ8avU04L//TjIDFpc1J1rqON9ScAelN0CCpKHlI6y/Oyc6q8CbD/pftNPaA9wEehOjacTV0GOxofYy+2gRRigvbIpTVKwmdMUHPLSVEQ==; 24:hxTiK+0t3r5M+ZkMCm2lgZEM7m+yJlfrDHB93Yhb02zqiEAFMzAuQoeAz/ehdwm2mQs/OMSgulxJP7LhJKss7a/zATY613zAL7OvrxKp1+g=; 20:jTXuxw2oNp6ffBE3SidZ+piVqjeGuFPkzojD4bTyevv9Py6JncTL65lEpwsED8/96oY5PLMf+pJcarViIF9Rog== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(189002)(199003)(19580395003)(2656002)(76576001)(87936001)(10090500001)(33656002)(93886004)(101416001)(99286002)(46102003)(561944003)(54356999)(50986999)(76176999)(86612001)(74316001)(86362001)(106356001)(105586002)(106116001)(5002640100001)(92566002)(2950100001)(2900100001)(122556002)(62966003)(81156007)(19580405001)(77156002)(40100003)(5001960100002)(64706001)(97736004)(189998001)(77096005)(68736005)(4001540100001)(102836002)(5001830100001)(5001860100001)(5003600100002)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: 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.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 00:37:47.3160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 00:38:11 -0000 PiBXZWxsLCBUTFMgaXMgYWxzbyB1c2VkIGZvciBub24tYnJvd3NlciBIVFRQUyBhbmQgc3R1ZmYg b3RoZXIgdGhhbiBIVFRQUy4NCj4gVGhlcmUgb25lIGxpa2VseSAicHJlY29uZmlndXJlcyIgY2xp ZW50IGNlcnRpZmljYXRlcyBpZiBuZWVkZWQuDQpUaGUgcHJvcG9zZWQgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbSBzcGVjaWZpY2FsbHkgYWRkcmVzc2VzIHRoZSBjYXNlIHdoZXJlIHRo ZSBjbGllbnQgZG9lcyBub3QgaGF2ZSBvbmUgInByZWNvbmZpZ3VyZWQiIGNlcnQuDQoNCj4gLSBU TFMtbGV2ZWwgY2xpZW50IGNlcnRpZmljYXRlIGF1dGggb24gY2xpZW50IHJlcXVlc3Qgb24gY29u bmVjdCAodGhpcw0KPiAgY3VycmVudGx5IGNhbid0IGJlIGNsZWFubHkgZG9uZSwgc29tZXRpbWVz IG9uZSBldmVuIHNlZXMgdGhhdCAicmVuZWdvDQo+ICBpbW1lZGlhdGVseSB0byBwcm92b2tlIENS IiBoYWNrKS4NCldpdGggdGhlIHByb3Bvc2VkIGNoYW5nZSwgdGhlcmUgd2lsbCBiZSBubyBuZWVk IHRvIHJlbmVnb3RpYXRlIGluIG9yZGVyIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50Lg0KDQog PiAtIEFwcGxpY2F0aW9uLWxldmVsIGNsaWVudCBhdXRoICh2aWEgQ0IgY2FwYWJpbGl0eSBvZiBU TFMpLg0KVGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBkb2VzIG5vdCBwcmVjbHVkZSB0aGlzIG9wdGlv bi4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IElsYXJpIExpdXN2YWFyYSBbbWFpbHRvOmlsYXJpLmxpdXN2YWFyYUBlbGlzYW5ldC5maV0g DQpTZW50OiBTdW5kYXksIEF1Z3VzdCAyLCAyMDE1IDExOjI5IEFNDQpUbzogRGF2aWQgQmVuamFt aW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz4NCkNjOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPjsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gQ29tbWVu dGFyeSBvbiB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHByZXNlbnRhdGlvbiBzbGlkZXMNCg0K T24gU3VuLCBBdWcgMDIsIDIwMTUgYXQgMDM6Mzg6MDBQTSArMDAwMCwgRGF2aWQgQmVuamFtaW4g d3JvdGU6DQo+IE9uIFNhdCwgQXVnIDEsIDIwMTUgYXQgNDo0OCBBTSBJbGFyaSBMaXVzdmFhcmEg DQo+IDxpbGFyaS5saXVzdmFhcmFAZWxpc2FuZXQuZmk+DQo+IHdyb3RlOg0KPiA+DQo+ID4gV2hh dCBJIHRoaW5rIHdvdWxkIGJlIHZlcnkgdXNlZnVsOiBBIHdheSBmb3IgY2xpZW50IHRvIHNpZ25h bCBpdCBoYXMgDQo+ID4gYSBjbGllbnQgY2VydGlmaWNhdGUgaXQgZXhwZWN0cyB0byB1c2UsIHJl Z2FyZGxlc3Mgb2YgaWYgdmFsaWQgDQo+ID4gY29uZmlndXJhdGlvbiBpcyBrbm93bi4gVGhlIHZh c3QgbWFqb3JpdHkgb2YgdGltZXMgY2xpZW50IA0KPiA+IGNlcnRpZmljYXRlIGlzIHVzZWQsIHRo ZSBjbGllbnQga25vd3MgYWJvdXQgdGhhdCBiZWZvcmUgaW5pdGlhdGluZyBhIGNvbm5lY3Rpb24u DQo+IA0KPiBVbmxlc3MgSSBtaXN1bmRlcnN0YW5kIHlvdSwgdGhpcyBpc24ndCB0cnVlIGZvciBh IGJyb3dzZXIuIEJyb3dzZXJzIA0KPiBvbmx5IGxvb2sgZm9yIGNsaWVudCBjZXJ0aWZpY2F0ZXMg YmFzZWQgb24gYSBDZXJ0aWZpY2F0ZVJlcXVlc3QgDQo+IG1lc3NhZ2UuIFNvbWUgcGxhdGZvcm1z LCBsaWtlIEFuZHJvaWQsIGRvbid0IGV2ZW4gbGV0IHlvdSBsaXN0IHRoZSANCj4gdXNlcidzIGNl cnRpZmljYXRlIHN0b3JlLiBJbnN0ZWFkIHRoZXJlJ3MgYW4gQVBJIHRvIHNob3cgYSB0cnVzdGVk IGNlcnRpZmljYXRlIHBpY2tlciBwcm9tcHQuDQoNCldlbGwsIFRMUyBpcyBhbHNvIHVzZWQgZm9y IG5vbi1icm93c2VyIEhUVFBTIGFuZCBzdHVmZiBvdGhlciB0aGFuIEhUVFBTLg0KVGhlcmUgb25l IGxpa2VseSAicHJlY29uZmlndXJlcyIgY2xpZW50IGNlcnRpZmljYXRlcyBpZiBuZWVkZWQuDQoN Cj4gT3IsIGdpdmVuIHRoZSBwYXJhZ3JhcGggYmVsb3csIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0 IHdlJ2Qgc3RhcnQgYSANCj4gc2Vjb25kIGNvbm5lY3Rpb24gb24gcmVjZWl2aW5nIENlcnRpZmlj YXRlUmVxdWVzdCBhbmQgb25seSBhZHZlcnRpc2UgaXQgdGhlbj8NCj4gWWVhaCwgdGhhdCdzIGFj dHVhbGx5IGhvdyBDaHJvbWUgaW1wbGVtZW50cyBjbGllbnQgYXV0aCBhbnl3YXkuIFdlIA0KPiBh bHdheXMgc3RhcnQgYSBzZWNvbmQgY29ubmVjdGlvbiB3aXRoIGEgY2xpZW50IGNlcnRpZmljYXRl IGNvbmZpZ3VyZWQsIA0KPiBldmVuIGlmIHRoZSBzZXJ2ZXIgc2VudCBDZXJ0aWZpY2F0ZVJlcXVl c3Qgb24gYSByZW5lZ28uIEl0IG1ha2VzIGEgZmV3IHRoaW5ncyBzaW1wbGVyLg0KDQpEb2Vzbid0 IHRoYXQgY291bnQgYXMgImtub3dpbmcgYWJvdXQgY2xpZW50IGNlcnRpZmljYXRlIGJlZm9yZSBj b25uZWN0aW5nIg0KKGV2ZW4gaWYgdGhlIGtub3dsZWRnZSBoYXMgYmVlbiByZWNlaXZlZCBzcGxp dC1zZWNvbmQgYmVmb3JlIFRMUyBoYW5kc2hha2Ugc3RhcnRzKT8NCg0KQWxzbywgc2lnbmFsaW5n IGNhbiBiZSBhdCBhcHBsaWNhdGlvbiBsYXllciwgYXMgdGFsa2VkIGFib3V0IGJlbG93Lg0KDQo+ ID4gSU1PLCB0aGUgcHJvcGVyIHdheSB0byBoYW5kbGUgInRoaXMgcmVzb3VyY2UgcmVxdWlyZXMg Y2xpZW50IGNlcnRpZmljYXRlIg0KPiA+IGlzIGZvciBzZXJ2ZXIgdG8gc2lnbmFsIHRoYXQgaW4g YXBwbGljYXRpb24gcHJvdG9jb2wgYW5kIHRoZW4gY2xpZW50IA0KPiA+IHRvIGVzdGFibGlzaCBh IG5ldyBjb25uZWN0aW9uIHdpdGggY2xpZW50IGNlcnRpZmljYXRlIChvciBpZiANCj4gPiBhcHBs aWNhdGlvbiBwcm90b2NvbCBzdXBwb3J0cyBpdCwgZG8gdGhlIGF1dGhlbnRpY2F0aW9uIGF0IA0K PiA+IGFwcGxpY2F0aW9uIGxheWVyIHdpdGhvdXQgZXZlciBpbnZvbHZpbmcgVExTLCBleGNlcHQg Zm9yIGNoYW5uZWwgYmluZGluZykuDQo+IA0KPiBDZXJ0YWlubHkuIENocm9tZSBkb2Vzbid0IGlt cGxlbWVudCBUTFNfUkVORUdfUEVSTUlUVEVEIGZvciBIVFRQLzIsIA0KPiBhbmQgSSBkb24ndCB3 YW50IHRvIGFsbG93IHRoaXMgbWVjaGFuaXNtIGZvciBpdCBlaXRoZXIuIEkgY29uc2lkZXIgDQo+ IHJlbmVnby1iYXNlZCBwZXItcmVzb3VyY2UgY2xpZW50IGF1dGggaW4gSFRUUC8xLjEgdG8gYmUg YSBsZWdhY3kgDQo+IG1pc3Rha2Ugd2UncmUgY3VycmVudGx5IHN0dWNrIHdpdGguIChJdCdzIHRo ZSBvbmx5IHJlYXNvbiB3ZSBldmVyIGhhdmUgDQo+IHRvIHJlbmVnby4gSW4gQm9yaW5nU1NMLCB3 ZSd2ZSBzZXR0bGVkIG9uIHN0cmlwcGluZyByZW5lZ28gZG93biB0byB0aGUgDQo+IGJhcmUgbWlu aW11bSBuZWVkZWQgdG8gc3VwcG9ydCB0aGlzLiBTaW1wbGlmaWVzIGEgbG90IG9mIHN0dWZmLikN Cg0KWWVhaCwgSSBjb25zaWRlciBpdCAocmVuZWdvIGF1dGggaW4gSFRUUC8xLjEpIGEgcG9vciBp ZGVhIGFzIHdlbGwsIGFuZCBJIGNvbnNpZGVyIGl0IHdvdWxkIGJlIGFjdGl2ZWx5IGRhbmdlcm91 cyBpbiBicm93c2VyIEhUVFAvMiAoZHVlIHRvIHRoZSBtdWx0aXBvaW50IG5hdHVyZSBvZiB0aGUg ZW52aXJvbm1lbnQgYW5kIG11bHRpcGxleGVkIG5hdHVyZSBvZiBIVFRQLzIpLi4uDQpHb29kIHRo aW5nIGl0IGlzIGJhbm5lZC4NCg0KPiBJJ20gZ3Vlc3NpbmcgTWljcm9zb2Z0IGhhcyBkaWZmZXJl bnQgY29uc3RyYWludHMvZ29hbHMsIGdpdmVuIHRoaXMgDQo+IHByb3Bvc2FsIGFuZCBUTFNfUkVO RUdfUEVSTUlUVEVELCBzbyBpZiB3ZSBtdXN0IGhhdmUgaXQgaW4gdGhlIA0KPiB0cmFuc3BvcnQs IEknZCByYXRoZXIgaXQgYmUgc29tZSBvcHQtaW4gY29ybmVyIHRoYXQgSSBkb24ndCBoYXZlIHRv IA0KPiBkZWFsIHdpdGguIChBcHBsaWNhdGlvbnMgY2FuIHJldHVybiBIVFRQXzFfMV9SRVFVSVJF RCBpbiBIVFRQLzIgaWYgDQo+IHRoZXkgcmVhbGx5IG11c3QgZG8gcGVyLXJlc291cmNlIGNsaWVu dCBhdXRoLikgQnV0IEkgZG8gYWdyZWUgdGhpcyBpcyANCj4gYSBwcm9ibGVtYXRpYyBtZWNoYW5p c20gYW5kIGRvbid0IHRoaW5rIGl0IGJlbG9uZ3MgaW4gVExTLiBMZXQgdGhlIA0KPiBhcHBsaWNh dGlvbiBsYXllciBkbyBpdCB3aXRoIGEgY2hhbm5lbCBiaW5kaW5nLiBObyBuZWVkIGZvciBuZXcg DQo+IGNvbm5lY3Rpb25zLCBhbmQgbm8gbWVzc3kgcXVlc3Rpb25zIGFib3V0IHNjb3BlIGFuZCBt dWx0aS1yZXF1ZXN0IHByb3RvY29scy4NCg0KU3VtbWFyeSBvZiB3aGF0IGF1dGggbW9kZXMgSSB0 aGluayBhcmUgbmVlZGVkOg0KDQotIFRMUy1sZXZlbCBjbGllbnQgY2VydGlmaWNhdGUgYXV0aCBv biBjbGllbnQgcmVxdWVzdCBvbiBjb25uZWN0ICh0aGlzDQogIGN1cnJlbnRseSBjYW4ndCBiZSBj bGVhbmx5IGRvbmUsIHNvbWV0aW1lcyBvbmUgZXZlbiBzZWVzIHRoYXQgInJlbmVnbw0KICBpbW1l ZGlhdGVseSB0byBwcm92b2tlIENSIiBoYWNrKS4NCi0gQXBwbGljYXRpb24tbGV2ZWwgY2xpZW50 IGF1dGggKHZpYSBDQiBjYXBhYmlsaXR5IG9mIFRMUykuDQoNCg0KDQotSWxhcmkNCg== From nobody Mon Aug 3 23:51:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C401B3671 for ; Mon, 3 Aug 2015 23:51:55 -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_40=-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 Ox7wwt-3X7_h for ; Mon, 3 Aug 2015 23:51:53 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C751B366C for ; Mon, 3 Aug 2015 23:51:51 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 784D33FC9; Tue, 4 Aug 2015 09:51:49 +0300 (EEST) Date: Tue, 4 Aug 2015 09:51:49 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150804065149.GA27148@LK-Perkele-VII> References: <201507251453.18237.davemgarrett@gmail.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT & resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:51:56 -0000 On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: > > > We agreed on how to do this in Prague. The sticking point was establishing > the cipher suite. I have WIP text on my machine for both of these which I > will be > sending early next week, once I get enough sleep to be able to clean it up, > so I'd ask people to sit tight till then. > Okay, now the PR (#211) seems to be up, let's review: - Lacks client-driven client authentication[1]. All client auth is server driven, which I think isn't very useful in real world (there are all sorts of bad hacks[2] trying to work around lack of client-driven auth). - EncryptedExtensions looks to be mandatory in some exchanges, optional in others. I agree it should be mandatory in all (issue #213). - "The client's cryptographic determining parameters match the parameters that the server has negotiated based on the rest of the ClientHello." ... Does that mean the client has to guess what ciphersuite the server will choose (more than pure-PSK vs. GDHE, which is unvaoidable with just one encrypted block)? - Regarding other extensions, it doesn't look to be the same list as ServerHello extensions, as max_fragment_length is on ServerHello, but certainly makes no sense as 0-RTT extension (I didn't see any other possibly relevant extensions). - Am I reading the syntax wrong, or does the extensions field in server configuration only allow exactly one extension (shouldn't it be zero or more)? Also, regarding issue #212, unless the Certificate is handled specially, it would mean that the signature does not cover certificate. And not signing the certificate (esp. the public key within) causes problems in some exotic cases (I don't know if any of those cases pop up in TLS 1.3). I think it would simplify the security analysis a bit if CertificateVerify was always immediately before Finished and covered everything before that point. On client side, one gets that "no certificate" special case anyway. [1] A lot of time, the client knows if it is going to present client certificate or not before it initiates the handshake. [2] At best ugly, at worst security problem. -Ilari From nobody Tue Aug 4 05:37:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DBA1A1A80 for ; Tue, 4 Aug 2015 05:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 cLq0wVvjkLY3 for ; Tue, 4 Aug 2015 05:37:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0D81A1A1D for ; Tue, 4 Aug 2015 05:37:07 -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 (Postfix) with ESMTPS id 8EDBE19F98E for ; Tue, 4 Aug 2015 12:37:07 +0000 (UTC) Received: from dhcp-10-40-3-77.brq.redhat.com (dhcp-10-40-3-77.brq.redhat.com [10.40.3.77]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t74Cb5LH004644 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 4 Aug 2015 08:37:07 -0400 Message-ID: <1438691824.10777.9.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Tue, 04 Aug 2015 14:37:04 +0200 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: Subject: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 12:37:09 -0000 Hi, An open issue for draft-ietf-tls-chacha20-poly1305-00 raised by Eric Rescorla is that this draft doesn't use the draft-TLS 1.3 mechanism for setting the nonce per record [0]. Is there any support for switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the redundant bytes redacted as the draft is now [1]. Are there any other issues than the listed above which may prevent early code point assignment? [0]. https://www.ietf.org/mail-archive/web/tls/current/msg16374.html [1]. https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00 From nobody Tue Aug 4 05:41:33 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA631A888E for ; Tue, 4 Aug 2015 05:41: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 sE8VimEx22Hc for ; Tue, 4 Aug 2015 05:41:29 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7C51A8889 for ; Tue, 4 Aug 2015 05:41:29 -0700 (PDT) Received: by wijp15 with SMTP id p15so4140584wij.0 for ; Tue, 04 Aug 2015 05:41: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=sZarvpVz+IKe+6l6eIvND8kerzAkCXjXpwecEhy6J5I=; b=ljhFBMqDeDMVRJDFEniJr6bK31T59rXMJHyOOY9c7V0fzqRwwtySKYnO6MO7T13OEj ZpYrsShKV4VilSUi3+ZGP/EGA30P0N9W9JTsgyAjQ3frTPuFkfGwDpK4qSRTsLEIYs7N ss/HudIENxKCbdzBwrIQkuiOzEv8w9kq90/8vIzwhaMtnmvvUzLYMn6el41m1L0bWjpN giU/SooS7vQCb0TvIc0t9uRrzVij9ar96wA+TWcCD9PYliK8ofMJCJ2z9lT5hl5SZMGA 5sX7cAfXwPf2KLpLH9BHQ9UKgYGBzB208VVggBVOUgVrMA/48yhY1BZ2DKe+LaRnr0W2 Qx8g== X-Gm-Message-State: ALoCoQmQGb2M2t7xUg1J5M5QDtN3FzE3fuE+QxDSWrkxbEXVb7EIo33puChfamqLJek8zcVlXbrO X-Received: by 10.180.73.244 with SMTP id o20mr7694294wiv.31.1438692088014; Tue, 04 Aug 2015 05:41:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.86 with HTTP; Tue, 4 Aug 2015 05:40:48 -0700 (PDT) In-Reply-To: <20150804065149.GA27148@LK-Perkele-VII> References: <201507251453.18237.davemgarrett@gmail.com> <20150804065149.GA27148@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 4 Aug 2015 05:40:48 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d0435c06ad8fc1b051c7b9af9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT & resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 12:41:31 -0000 --f46d0435c06ad8fc1b051c7b9af9 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: > > > > > > We agreed on how to do this in Prague. The sticking point was > establishing > > the cipher suite. I have WIP text on my machine for both of these which I > > will be > > sending early next week, once I get enough sleep to be able to clean it > up, > > so I'd ask people to sit tight till then. > > > > Okay, now the PR (#211) seems to be up, let's review Oops. It wasn't supposed to be done. I meant to make it a PR against my own branch so that I could get early comments from MT, but obviously that didn't work out. Regardless, thanks for your comments. - Lacks client-driven client authentication[1]. All client auth is server > driven, which I think isn't very useful in real world (there are all > sorts of bad hacks[2] trying to work around lack of client-driven auth). > This is just extending existing practice for 1-RTT handshakes. I tend to agree with you that it would be good to change that, but I didn't want to do that in this PR, because it would be a big semantic change in TLS. I suggest you start a new thread on this topic, or perhaps add it to Andrei's client auth thread? - EncryptedExtensions looks to be mandatory in some exchanges, optional > in others. I agree it should be mandatory in all (issue #213). > Me too. That's just editing error. > - "The client's cryptographic determining parameters match the parameters > that the server has negotiated based on the rest of the ClientHello." > ... Does that mean the client has to guess what ciphersuite the server > will choose (more than pure-PSK vs. GDHE, which is unvaoidable with > just one encrypted block)? > The client knows what the server selected based on his previous offer and the server's configuration (which by hypothesis is still extant) so the server should choose the same value again. > - Am I reading the syntax wrong, or does the extensions field in server > configuration only allow exactly one extension (shouldn't it be zero > or more)? > Yes. good catch. Also, regarding issue #212, unless the Certificate is handled specially, > it would mean that the signature does not cover certificate. And not > signing the certificate (esp. the public key within) causes problems > in some exotic cases (I don't know if any of those cases pop up in TLS > 1.3). > This seems like a good argument. > I think it would simplify the security analysis a bit if CertificateVerify > was always immediately before Finished and covered everything before that > point. > Isn't this always the case presently? Are you just thinking we should say it's a rule? -Ekr --f46d0435c06ad8fc1b051c7b9af9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= span class=3D"">On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wro= te:
>
>
> We agreed on how to do this in Prague. The sticking point was establis= hing
> the cipher suite. I have WIP text on my machine for both of these whic= h I
> will be
> sending early next week, once I get enough sleep to be able to clean i= t up,
> so I'd ask people to sit tight till then.
>

Okay, now the PR (#211) seems to be up, let's review

Oops. It wasn't supposed to be done. I meant to ma= ke it a PR against my
own branch so that I could get early commen= ts from MT, but obviously that
didn't work out. Regardless, t= hanks for your comments.


- Lacks client-driven client authentication[1]. All client auth is server =C2=A0 driven, which I think isn't very useful in real world (there are= all
=C2=A0 sorts of bad hacks[2] trying to work around lack of client-driven au= th).

This is just extending existing pr= actice for 1-RTT handshakes.

I tend to agree with = you that it would be good to change that, but I didn't want
t= o do that in this PR, because it would be a big semantic change in TLS.
I suggest you start a new thread on this topic, or perhaps add it to= Andrei's
client auth thread?


- EncryptedExtensions looks to be mandat= ory in some exchanges, optional
=C2=A0 in others. I agree it should be mandatory in all (issue #213).

Me too. That's just editing error.
=

=C2=A0
- "The client's cryptographic determining parameters match the par= ameters
=C2=A0 that the server has negotiated based on the rest of the ClientHello.= "
=C2=A0 ... Does that mean the client has to guess what ciphersuite the serv= er
=C2=A0 will choose (more than pure-PSK vs. GDHE, which is unvaoidable with<= br> =C2=A0 just one encrypted block)?

The c= lient knows what the server selected based on his previous offer and
<= div>the server's configuration (which by hypothesis is still extant) so= the server
should choose the same value again.=C2=A0
<= br>

- Am I reading the syntax wrong, or does the extensions field in server
=C2=A0 configuration only allow exactly one extension (shouldn't it be = zero
=C2=A0 or more)?

Yes. good catch.
=


Also, regarding issue #212, unless the Certificate is handled specially, it would mean that the signature does not cover certificate. And not
signing the certificate (esp. the public key within) causes problems
in some exotic cases (I don't know if any of those cases pop up in TLS<= br> 1.3).

This seems like a good argument.<= /div>

=C2=A0
I think it would simplify the security analysis a bit if CertificateVerify<= br> was always immediately before Finished and covered everything before that point.

Isn't this always the case p= resently? Are you just thinking we should say it's
a rule?

-Ekr

--f46d0435c06ad8fc1b051c7b9af9-- From nobody Tue Aug 4 09:13:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83D11A6FEA for ; Tue, 4 Aug 2015 09:13: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 nCHf8jfr7sRk for ; Tue, 4 Aug 2015 09:13:14 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4811A6FF1 for ; Tue, 4 Aug 2015 09:13:14 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so9044101lbb.0 for ; Tue, 04 Aug 2015 09:13: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=nR0/y5WRhXPaJjpND2racFVUlscQ4zrMfXmGDwq3E0w=; b=GHrjSmZuPgOx130QaHHPj3ZFSZ+lnHloeLd2SivuGcGFZs/wEW+jiFz9DSjILseZNu mYImQoxocvuxePIdwFvX7va5gPvvB5+6GzuEsQ9nRZrxoy67NytK/hY1Oy2jKkBq6UQ+ RC1PuCs1ZKh9ImmnewrZ52aLkdE4wpK5L3FQQelNJrZ18mES8wELQI9wqGQUw3MOncTl JawLI+/HJmBJ6mZqN0Of51nWFf40cXFJuFNtE316u9jLt9X4eNmlvKMqIE9fi4W3oYMh aLIaYTxYCOiLg9Ub8l1yJa+OK80vfLDzU4IUzfXDfrhwPrTLXx9m/Ve/4wwqJAb5QcJu Jvpw== MIME-Version: 1.0 X-Received: by 10.152.179.42 with SMTP id dd10mr4391667lac.89.1438704792621; Tue, 04 Aug 2015 09:13:12 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 4 Aug 2015 09:13:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 09:13:12 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Review of PR #209 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 16:13:16 -0000 On 3 August 2015 at 17:21, Andrei Popov wrote: >> use CertificateRequest within the handshake, and the new content type outside of it > > Would the client then also use this new content type for Certificate and CertificateVerify messages (when these are sent after the handshake is complete)? Yeah, I think that's best. From nobody Tue Aug 4 09:15:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0811A1B5C for ; Tue, 4 Aug 2015 09:15: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 zPkkgztgyxmI for ; Tue, 4 Aug 2015 09:15:36 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61DB1A870B for ; Tue, 4 Aug 2015 09:15:30 -0700 (PDT) Received: by lbbud7 with SMTP id ud7so9046778lbb.3 for ; Tue, 04 Aug 2015 09:15: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=P61GB5OcQME17ykCS7gu5mWo/jJKxUv7cm3QgE6lp6Q=; b=kRHR5m0NGmrqRKh7/qvyyKBnqfCV4eSHVjr9toaxntrZ8ZgpMTuNyWA1ZnBDr8OKzp WwzPyIX3mtebqxMybSJRrXnksXOyocgj42jso+4qOuj2fK7PB5jajbwEnQURlJX+1yNI yCYQ3Owo2DBqPDpONfcyaRfoWhqFzX97kpcDq2IN15Il0GGRBBmBQm7SvtmzlwEddM53 L9/rc0D6a+z8CBNz/HlLyiTV93kIGtMavw7HdR1N0ppM+vhCQbso+WG2k6doUOMCLzGc Hd7EGZjv6bUDZzgQaRrS9uXViYNHjHESA/9Miqf26RpOc+KTvRqeKey3Q3fS1XZH9pPy zFww== MIME-Version: 1.0 X-Received: by 10.152.121.4 with SMTP id lg4mr4372012lab.112.1438704929255; Tue, 04 Aug 2015 09:15:29 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 4 Aug 2015 09:15:29 -0700 (PDT) In-Reply-To: <1438691824.10777.9.camel@redhat.com> References: <1438691824.10777.9.camel@redhat.com> Date: Tue, 4 Aug 2015 09:15:29 -0700 Message-ID: From: Martin Thomson To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 16:15:37 -0000 On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos wrote: > Is there any support for > switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for > TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the > redundant bytes redacted as the draft is now [1]. Personally, I would rather see the nonce construction follow the form defined in the respective TLS version. That means including redundant bytes in TLS 1.2 and only getting the full advantage when we move to TLS 1.3. From nobody Tue Aug 4 09:20:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8384E1A1AA6 for ; Tue, 4 Aug 2015 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 inggoRGUpq-T for ; Tue, 4 Aug 2015 09:20: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 064C51A6FFD for ; Tue, 4 Aug 2015 09:20:21 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E59D229570; Tue, 4 Aug 2015 16:20:20 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C80302956E; Tue, 4 Aug 2015 16:20:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1438705220; bh=FngxOm69kxKmI21UBbNEGqPYXpVJqh14yAVdxy1oD1g=; l=140; h=From:To:CC:Date:References:In-Reply-To:From; b=GTgRKSbSI7rskER0KhGBP6zaouod48x31DY+07fH9mvgj6aYUkvJ35Kame9OOoHbb yb2V8V/0L2YbC9LNhJYj7XQAGPIN3wPwsdz+znPMqkwMb843XrWEbRL/lOi8TRlToN tKgKDx7QM5P7Lsb9n0X6DDWJWWm0NNkaReOooJGA= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id AE5318008D; Tue, 4 Aug 2015 16:20:20 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 4 Aug 2015 11:20:20 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Tue, 4 Aug 2015 11:20:20 -0500 From: "Salz, Rich" To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-00 Thread-Index: AQHQzrJa9kGS0C0C5E+zxa5T6wEh0538V/yA//+teDA= Date: Tue, 4 Aug 2015 16:20:19 +0000 Message-ID: References: <1438691824.10777.9.camel@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 16:20:23 -0000 > Personally, I would rather see the nonce construction follow the form > defined in the respective TLS version. Yes, consistency. +1 From nobody Tue Aug 4 10:04:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232DB1A88FA for ; Tue, 4 Aug 2015 10:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0T3HTSaCutFu for ; Tue, 4 Aug 2015 10:04:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5E61A88F4 for ; Tue, 4 Aug 2015 10:04:23 -0700 (PDT) Received: from BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) by BLUPR03MB1331.namprd03.prod.outlook.com (10.163.80.21) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 17:04:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8mApuG7h+b5KYXmVIn3+w4OTxpaGMUCtWWnmu9Vzlyc=; b=eCWEWYwUDAHg5txR8csq7sfZ0TIgQX8GlDpOmCpOIcYF5uW0wZZ4gSPeq5vDCK+QxT9ps0jJ6rftuR4crzHr7/7CsD5rlzv+Twu2Jurh/uIjfAKFR0ojjaTCoElsG53jG/E5BfIpEx4OB1+kgr6PKJTZ4IyAsgCAQMoOnhhFaLM= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 17:04:21 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Tue, 4 Aug 2015 17:04:21 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] Review of PR #209 Thread-Index: AQHQxuqZE5b0AgbP4UGzDBeqZzcHy537BwWQgAEMEQCAAA3XEA== Date: Tue, 4 Aug 2015 17:04:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:FBpFW91Pxx2y3xeVTkF4qKmnPX++lZ2B5fdoJBed1IEvIpU957yQ6W6vROTD9fwHszjlIzDxoJ6896eUE1Oeto8BYQxM14fZwlZghwNwbGJkyCduoMjICYah0DM1sTysuTYPO56gUEXk+RSeDqDqcg==; 24:hLR1itIt5QiCdAeP7LNs+xMfdpoygV8lk04mHrlAYJxME10CHY+xym+SHE8ASbn9bHeOHd9HqkXU0Re93xApkyuXNp3uJOhMYI1zNZ7SS0Y=; 20:xTfx5EO+O8qi6FA6/gdaS2yuk/gn7FKiwJ9eUQ0ITiK86FaTBNLCZBBROa3Mw/PERiVCd6djpL+vA2kCpb69yg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1331; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0658BAF71F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(199003)(189002)(51444003)(64706001)(62966003)(77156002)(19580395003)(40100003)(76576001)(46102003)(10090500001)(122556002)(74316001)(86362001)(54356999)(2950100001)(77096005)(68736005)(2900100001)(2656002)(99286002)(102836002)(189998001)(19580405001)(106116001)(106356001)(105586002)(5001860100001)(5001960100002)(50986999)(101416001)(33656002)(92566002)(81156007)(110136002)(5003600100002)(97736004)(5001830100001)(5002640100001)(4001540100001)(76176999)(86612001)(87936001)(5005710100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2015 17:04:21.3754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB1331; 2:ED8+pAmO2TewhYWw12oDDYWUmAcHRjboyB4/PPPcdgGMFHGhWQowqNvPWhwyVfB4vqBhEBeOtXRrf7DZ5i9+MLIZimz/2mmB62rp7wzidKZSBQwMsgYNnqDRRGU2XgFsE751MuDwddVzgR+bti/ZScUCN6+8R3Quq2Uv49c3KnM=; 3:R6SsgwdS91LawNSxtLxeAxLEbL6XcdmliM1Tu7py4hYZHoMTlyHjp/c0rZJL0nsNlMPM62X3KYh37iN8R7ztovDDIqPV/7FhSA0waIm0rIt3ibiyjaZ0vKfDK91H1c4HiKSAZXaLtep4X/YLmO66WA==; 25:9ssILiQTDiifMa/5dZI0rzUaBewfYspLvQ9ys5WFVw5+NdoXyCtAgDYd2ifuZlQ5QWfQ+R9ho+HNUpC6AnqDhcvMHsN0VM1ke23E44Bysk+k71JHB9N87KxkXpkcSClD/NAOTqlR1+gS3WIprY/zYZXPe46a5YQMFBJjNKY6gSAQrH5rnneHVMmPWjq0JkSgjHklHHP8HYH+16PsA+yS05LGMZryvNIKI7/wEET+5WTdzuzKl2S4Mz0+JbJbgr3zAZbsjBlBakNB4H87HU/yNA==; 23:ScVHIbtvVTTp0efmhXRbaX1j6DWZkGQW14LFfzb6bLeDf75ZAKa0zxcK0RLt3wQCUtT7h9Zm+M63livhVmr8S4NeOfKdkhRtNAuP9wNXXKHAsU34cSNmHf/KmV3Fp6B3m5rBOzUqSDDtQSIbaeTVII08Qn+1GYX+bkxXgOKXQgPVMf+i9LXCLaPUuwo9lzLBN5SS9PFTmoVYb1wwHZ2/JRigqfs3uw9FhyZeaBAy+uHi60NsUZOwtgZ8DzaZEtT3 X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Review of PR #209 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 17:04:29 -0000 SSdtIG5vdCBvcHBvc2VkIHRvIHVzaW5nIGEgbmV3IGNvbnRlbnQgdHlwZSBpbiB0aGlzIHdheSwg aWYgZm9sa3MgZmVlbCB0aGF0IHRoaXMgbWFrZXMgdGhpbmdzIGJldHRlci4NCg0KQ2hlZXJzLA0K DQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9t c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1 Z3VzdCA0LCAyMDE1IDk6MTMgQU0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNy b3NvZnQuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFJldmlldyBv ZiBQUiAjMjA5DQoNCk9uIDMgQXVndXN0IDIwMTUgYXQgMTc6MjEsIEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4gdXNlIENlcnRpZmljYXRlUmVxdWVz dCB3aXRoaW4gdGhlIGhhbmRzaGFrZSwgYW5kIHRoZSBuZXcgY29udGVudCB0eXBlIG91dHNpZGUg b2YgaXQNCj4NCj4gV291bGQgdGhlIGNsaWVudCB0aGVuIGFsc28gdXNlIHRoaXMgbmV3IGNvbnRl bnQgdHlwZSBmb3IgQ2VydGlmaWNhdGUgYW5kIENlcnRpZmljYXRlVmVyaWZ5IG1lc3NhZ2VzICh3 aGVuIHRoZXNlIGFyZSBzZW50IGFmdGVyIHRoZSBoYW5kc2hha2UgaXMgY29tcGxldGUpPw0KDQpZ ZWFoLCBJIHRoaW5rIHRoYXQncyBiZXN0Lg0K From nobody Tue Aug 4 10:22:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4726C1A88ED for ; Tue, 4 Aug 2015 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 LtWnxYuMG2vD for ; Tue, 4 Aug 2015 10:22:12 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7E51A887D for ; Tue, 4 Aug 2015 10:22:12 -0700 (PDT) Received: by iggf3 with SMTP id f3so15900316igg.1 for ; Tue, 04 Aug 2015 10:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=OFeuy3Bfx9wASLEO/ETJ+r/OFg89/Bt/P+OTGRuT648=; b=b9qcg+Gt50R31vPyp0khc3isalJIwsqmPUJwQApdFdk52oGscFoOLoQCsl7phqE7Jg UkUtkaBhH7s0bGvQRLxitnFBdnLYZiQLEBBnUqzoM3IUkf7AYkxIl+idYnl+RDZN2A2F yJNXEleJsOuR2qjlNj97NPItfXAvnKRKHu4Qo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=OFeuy3Bfx9wASLEO/ETJ+r/OFg89/Bt/P+OTGRuT648=; b=J835TtE4nunCLYKJI/FXXAIOR9xDxhZZfOaw4xd2XI6s2dQnYVZoY+jMIagvo4xMh4 F0cCp37B0omotxZtjh6ulF4n0T3ouB96KZ1XYSLA4SGWMCJEmK3hTqmCIl5gcABzAxQH 8A6wSFNG50SLEkRj3mwlho3ImmMulqhnisO769ZrKJeF9zwDIkm46bz2dSaE2+hzh6Nx X8zvC4UduCCgBIztNxpCEFe8xiU5/jnxpQt53VT8Fb6jIMDR2ZYrfXiS2IaJioqp3Y0F juo7bq4Hq7QocbehGoGTyAzutUgvUODvpHjJUfYz88lFyMPwoWp++f06LdK31gCdiKsI Ov/g== X-Gm-Message-State: ALoCoQnjykTtvWUORdrPjsvomd+ni7CtxbXUvv8+mxuRgD97mn6UIeV4BBAnotQUt4zpzJTXgpff X-Received: by 10.50.112.170 with SMTP id ir10mr5133301igb.69.1438708931401; Tue, 04 Aug 2015 10:22:11 -0700 (PDT) MIME-Version: 1.0 References: <1438691824.10777.9.camel@redhat.com> In-Reply-To: From: David Benjamin Date: Tue, 04 Aug 2015 17:22:01 +0000 Message-ID: To: "Salz, Rich" , Martin Thomson , Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=089e013c6a94cac9cc051c7f8696 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 17:22:14 -0000 --089e013c6a94cac9cc051c7f8696 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 4, 2015 at 12:20 PM Salz, Rich wrote: > > Personally, I would rather see the nonce construction follow the form > > defined in the respective TLS version. [DB: Adding back in for context: > "That means including redundant bytes in TLS 1.2 and only getting the full > advantage when we move to TLS 1.3."] > > Yes, consistency. +1 > I think this already came up: https://www.ietf.org/mail-archive/web/tls/current/msg16365.html This is a waste of bandwidth. Consistency is generally good, but a weak argument here. The complexity is minimal. If you don't care about decrypting in-place, none of this matters. If you do care, you already have to deal with: - RC4 and TLS 1.0 CBC use no prefix on the ciphertext - AES-GCM, TLS 1.1+ 3DES use an 8-byte prefix - TLS 1.1+ AES CBC use a 16-byte prefix Adding a 0-byte prefix cipher doesn't make anything worse. It already must vary. As for following what's defined in TLS 1.2, RFC 5246 just says that GenericAEADCipher has a nonce_explicit field and: Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. It then describes the 1.2 AES-GCM scheme, but prefaced with "In many cases, it is appropriate to [...]". Saying nonce_explicit is empty and the nonce is built from the sequence number is perfectly consistent here. David --089e013c6a94cac9cc051c7f8696 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 4,= 2015 at 12:20 PM Salz, Rich <rsalz@= akamai.com> wrote:
> Per= sonally, I would rather see the nonce construction follow the form
> defined in the respective TLS version. [DB: Adding back in for context= : "That means including redundant bytes in TLS 1.2 and only getting th= e full advantage when we move to TLS 1.3."]

Yes, consistency.=C2=A0 +1


This is a waste of bandwidth.= Consistency is generally good, but a weak argument here. The complexity is= minimal. If you don't care about decrypting in-place, none of this mat= ters. If you do care, you already have to deal with:

- RC4 and TLS 1.0 CBC use no prefix on the ciphertext
- AE= S-GCM, TLS 1.1+ 3DES use an 8-byte prefix
- TLS 1.1+ AES CBC use = a 16-byte prefix

Adding a 0-byte prefix cipher doesn't ma= ke anything worse. It already must vary.

As for fo= llowing what's defined in TLS 1.2, RFC 5246 just says that GenericAEADC= ipher has a nonce_explicit field and:

=C2=A0 = =C2=A0Each AEAD cipher suite MUST specify how the nonce supplied to the
=C2=A0 =C2=A0AEAD operation is constructed, and what is the length o= f the
=C2=A0 =C2=A0GenericAEADCipher.nonce_explicit part.

It then describes the 1.2 AES-GCM scheme, but prefaced wi= th "In many cases, it is appropriate to [...]". Saying nonce_expl= icit is empty and the nonce is built from the sequence number is perfectly = consistent here.

David
--089e013c6a94cac9cc051c7f8696-- From nobody Tue Aug 4 10:24:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40431A1F1D for ; Tue, 4 Aug 2015 10:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd8KeXnWNj9M for ; Tue, 4 Aug 2015 10:24:16 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00171A1EEA for ; Tue, 4 Aug 2015 10:24:16 -0700 (PDT) Received: by wijp15 with SMTP id p15so15412892wij.0 for ; Tue, 04 Aug 2015 10:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h9qAUkMRKGATIcM9K9FVNLnOY67oHhj+Mo158Dh+e9E=; b=RZK09D+iS4bBaVa4TB5IxdTTVbQtEq31L8DmsQeGJMIh+i8D4sRf71uqT8LOWThECC oyZ7MQa2Sj92ytvCauWMeAl/c4VpWSEH7gLnYl8bVKilf7YTfmfL12fUfHbqOJU28Plk BkzMWRdO/4BkqfCJ6IcUO3ZtMh3ta4rpN9I+EFVZuCTmiDhgEM+FZPsm/DNnXnOe3pMX A5a0a4nHAEnz0josbSwdvjGVJhir+nnrqya+A5zZxJvGZXXsKA773NK61ngKBIbpVU/x iacxofXgzToaotcNZkbZeUY44dRKWBVVgm5Kf78MmJyUAIeePVYnIUJ6qiI/IpN7CW/e uC7w== 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=h9qAUkMRKGATIcM9K9FVNLnOY67oHhj+Mo158Dh+e9E=; b=BwcX3eZUTM9u1FtqHBrF9j8N9afxPzk+tvDR8cYGiqADVwxGOBIxJwuwnBoRXUiPnF 1yxRlP0Uw9Zq8hLZQLxbgvh3naZ7qC2qix73dXgNIuOJUqiYqLSG/NzkO3DL6dcHQRMk Ff2tErr7SEP76CD1rDi7OkEVHEAjzNtyZ0ILaqi9QsXtNfFP78yRo4D3gZPuY3GARYyq yj6Pw/BVRfj5lwLnZljvCzCxAqiLyxnTw7ULsnp85YnRZbLb4lhTzKlmk7DEhVKkWPB2 5Arvwjw1VplcyJWU/WH3taOU1UEdM5uJcIadBFcEmBHuYe6fnqlK5cO2yQvwFgbMHKEr Zx+g== X-Gm-Message-State: ALoCoQnNgFJIk4DFy/bM4JPwAQyUhdIIAilt68Qo2Pol/ECHE++S6e0VanP7unp0IuZ3r2hsmJtv MIME-Version: 1.0 X-Received: by 10.180.73.2 with SMTP id h2mr10320329wiv.72.1438709055322; Tue, 04 Aug 2015 10:24:15 -0700 (PDT) Received: by 10.28.63.198 with HTTP; Tue, 4 Aug 2015 10:24:15 -0700 (PDT) In-Reply-To: References: <1438691824.10777.9.camel@redhat.com> Date: Tue, 4 Aug 2015 10:24:15 -0700 Message-ID: From: Wan-Teh Chang To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 17:24:17 -0000 On Tue, Aug 4, 2015 at 9:15 AM, Martin Thomson wrote: > > Personally, I would rather see the nonce construction follow the form > defined in the respective TLS version. That means including redundant > bytes in TLS 1.2 and only getting the full advantage when we move to > TLS 1.3. Martin, In TLS 1.2, the explicit part of the nonce (GenericAEADCipher.nonce_explicit in https://tools.ietf.org/html/rfc5246#section-6.2.3.3) is allowed to be zero-length. So it seems reasonable for draft-ietf-tls-chacha20-poly1305 to use the draft-TLS 1.3 nonce mechanism for TLS 1.2. The consistency you want to see seems to be consistency with the AES GCM cipher suites, rather than with TLS 1.2. My only concern with adopting the draft-TLS 1.3 nonce mechanism for TLS 1.2 is that it is not final. It will be bad if draft-ietf-tls-chacha20-poly1305 becomes an RFC before TLS 1.3 does, and the final TLS 1.3 nonce mechanism is different. Wan-Teh From nobody Tue Aug 4 10:35:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626B51A8A12 for ; Tue, 4 Aug 2015 10:35: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 tCGEQN1RqI9r for ; Tue, 4 Aug 2015 10:35:32 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DB21A88F2 for ; Tue, 4 Aug 2015 10:35:31 -0700 (PDT) Received: by labsr2 with SMTP id sr2so12244781lab.2 for ; Tue, 04 Aug 2015 10:35: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; bh=nvGPnAwORM7dfMUrsZkxiwZhm5XTuIbXfjW2hcNSYHc=; b=UdChPNU9cGgE36jJaCAJm3wdrPXzuO+P9roDvBShxHYji+OA8Nu6fTm+v+fAhEpQ5Q RwSCwR9tmbJKfaeclUfCFjTQNskHRqAqGYHPRsnmzp4jqYtTxgnZsxvmToDS3bHmZ9l4 QdVBjXR0bC0RbNNeVPUH8kxorrheAeOBfwueUMZxDsJ5IJBeB8HW9wZwD3kOxUWRXgBP FcNxUBHS5SaNM9bHleaca0rw2tX6PgQDn7BAIpWwu0AQQUWVSI8vR93RWNEXv+N8gPW5 rPo37iRSlzfsB0E7QFnSNuMPV1bEQXgwYMyhpOf18VciG3jyIeWvktzx4wrfKK439cCm W16w== MIME-Version: 1.0 X-Received: by 10.152.23.167 with SMTP id n7mr4790354laf.108.1438709730106; Tue, 04 Aug 2015 10:35:30 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Tue, 4 Aug 2015 10:35:30 -0700 (PDT) In-Reply-To: References: <1438691824.10777.9.camel@redhat.com> Date: Tue, 4 Aug 2015 10:35:30 -0700 Message-ID: From: Martin Thomson To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Tue, 04 Aug 2015 17:35:33 -0000 On 4 August 2015 at 10:24, Wan-Teh Chang wrote: > The consistency you want to see seems to be > consistency with the AES GCM cipher suites, rather than with TLS 1.2. Yes, this is correct. RFC 5288: struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; RFC 6655: struct { opaque salt[4]; opaque nonce_explicit[8]; } CCMNonce; Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS only (if I'm reading it correctly). Either way, I think that we should attempt to be consistent with these. Which suggests that perhaps we can adopt a zero-length explicit nonce and borrow the 6655 DTLS construction. As for the wasted bytes, I don't care for that. We will fix that later. From nobody Wed Aug 5 01:03:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541311B2D6B; Wed, 5 Aug 2015 01:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9498k-293C70; Wed, 5 Aug 2015 01:03:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CF61B2D68; Wed, 5 Aug 2015 01:03:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9DD6811CF6F7E; Wed, 5 Aug 2015 08:03:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t7583cw5025443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Aug 2015 10:03:38 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 5 Aug 2015 10:03:38 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "" Thread-Topic: Number of DTLS sessions/DTLS connections; RE: [rtcweb] What the gateway draft should say about mux/non-mux Thread-Index: AQHQzw3+KxT/0f1cqU+61qeHi7bRGJ38hlaAgAB9WhA= Date: Wed, 5 Aug 2015 08:03:37 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> In-Reply-To: <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: [TLS] Number of DTLS sessions/DTLS connections; RE: [rtcweb] What the gateway draft should say about mux/non-mux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:03:44 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4sIEJlcm5hcmQsDQpyaWdodCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3VlIG9uIHRoYXQgYXNw ZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zLCB3 aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy4NCldvdWxkIGFwcHJlY2lhdGUg aWYgdGhpcyBjb3VsZCBiZSBzb21ld2hlcmUgZml4ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0 byBzaWduaWZpY2FudCBzaWRlIGVmZmVjdHMuDQpUaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2lu ZyBGQVEuDQoNClRoZSBtb3N0IHNpbXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0 aCB1c2FnZSBvZiBidW5kbGluZyBwbHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcsIGxlYWRpbmcgdG8gYSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlv biwgd2hpY2ggY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEuDQoNCkJv dGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBpbiB0aGUgcnRwIHVzYWdlIGRyYWZ0Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNz ZWN0aW9uLTQuNA0KPT4gYnVuZGxpbmcNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjUNCj0+IFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmcNCg0KTm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAv UlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBi ZSBtb3JlIHRoYW4gb25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9y IDQgaW4gY2FzZSBvZiBhdWRpbyAmIHZpZGVvKS4NClJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNo IERUTFMgY29ubmVjdGlvbiBpcyB1c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZm aWM/IC0gQmVjYXVzZQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRj d2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRp b24uDQpXb3VsZCB0aGVuIGJlIGEgM3JkIChvciA1dGgpIHNlbGYtY29udGFpbmVkIERUTFMgc2Vz c2lvbi9EVExTIGNvbm5lY3Rpb24gZm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/DQoNClByb3Bvc2Fs Og0KQWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41DQphYm91dCAoaW4g cmVkKSwgc29tZXRoaW5nIGxpa2U6DQoNCiAgIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBz dXBwb3J0IG11bHRpcGxleGluZyBvZiBEVExTIGFuZCBSVFAgb3Zlcg0KICAgdGhlIHNhbWUgcG9y dCBwYWlyLCBhcyBkZXNjcmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uDQogICBb UkZDNTc2NF0sIHNlY3Rpb24gNS4xLjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3 NjQjc2VjdGlvbi01LjEuMj4uICBBbGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9h ZHMNCiAgIG92ZXIgdGhpcyBEVExTIGNvbm5lY3Rpb24gYXJlIFNDVFAgcGFja2V0cy4NCg0KDQoN CiAgIE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rp b25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBub3QgYXBwbGllZC4g V2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFyZSBvbmUgb2YgdGhlc2UgRFRMUyBj b25uZWN0aW9ucyDigKYgKOKAnHdoaWNoIG9uZT/igJ0pIOKApiBvciBUaGVyZSBzaG91bGQgYmUg dGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0 aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBXZWJSVEMgZGF0YS4NCg0KDQoNCiAgIE5v dGUgMjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGlu Zy4NCg0KICAgUHJvdG9jb2wgaWRlbnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBhcyBwYXJ0 IG9mIHRoZSBEVExTDQogICBoYW5kc2hha2UsIGFzIHNwZWNpZmllZCBpbiBbSS1ELmlldGYtcnRj d2ViLWFscG48aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRy YW5zcG9ydHMtMDkjcmVmLUktRC5pZXRmLXJ0Y3dlYi1hbHBuPl0uDQoNCkNvbW1lbnRzPw0KUmVn YXJkcywNCkFsYnJlY2h0DQoNClBTDQpVc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5n IHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9n eS0wMS50eHQNCg0KDQpGcm9tOiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb21dDQpTZW50OiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQNClRvOiBSb21h biBTaHBvdW50DQpDYzogQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBFcmljIFJl c2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gsIFV3ZSAo Tm9raWEgLSBERS9NdW5pY2gpOyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0K DQpPbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpNb3N0IG9mIHRoZSBwZW9w bGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlvdSBuZWVkIHRvIGNyZWF0ZSB0d28gRFRM UyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3RoZXIgZm9yIFJUQ1AuIEFuZCB0aGVuIHVz ZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVuIGVuY3J5cHRpb24gcHJvZmlsZXMgZm9y IFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQga2V5 cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBpcyB3 cm9uZy4NCg0KW0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24gbWlz dGFrZXMuICBVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2NCBkb2VzIG5vdCBydWxlIG91dCBhbGwgb2Yg dGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVudHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFyIG9u IGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBpcyBtdWNoIGhhcmRlciB0byBtZXNzIHVwIFJU UC9SVENQIG11eC4gIEdpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3VsZCBi ZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA3NDExNDc5NjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTczMTAzMzc4 IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3 NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Um9tYW4sIEJl cm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+cmlnaHQsIFJGQyA1NzY0IGlzIHRvbyB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZv ciBjb25maXJtaW5nIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5l IHdpdGggb3VyIHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgYXBwcmVjaWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNv bWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25pZmljYW50IHNpZGUg ZWZmZWN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEIj5UaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGhlIG1vc3Qgc2ltcGxlIGNh c2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdlIG9mIGJ1bmRsaW5nIHBsdXMgdXNh Z2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZywgbGVhZGluZyB0byBhIHNpbmds ZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLCB3aGljaA0KIGNvdWxkIGJlIHRoZW4gYWxz byBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkJvdGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBp biB0aGUgcnRwIHVzYWdlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQiPjxzcGFuIGxhbmc9IkRF Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC40PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+DQo8c3BhbiBsYW5nPSJE RSI+PGJyPg0KPSZndDsgYnVuZGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0 aW9uLTQuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPj0mZ3Q7IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Ob3csIElGIGJ1 bmRsaW5nIGlzIG5vdCB1c2VkIE9SIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMg bm90IHVzZWQgVEhFTiB0aGVyZSB3aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RU TFMgY29ubmVjdGlvbiAoZWl0aGVyIDIgb3IgNCBpbiBjYXNlIG9mIGF1ZGlvDQogJmFtcDsgdmlk ZW8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PlJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1c2VkIGZvciBh ZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24t My41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNw b3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgdGhl biBiZSBhIDM8c3VwPnJkPC9zdXA+IChvciA1PHN1cD50aDwvc3VwPikgc2VsZi1jb250YWluZWQg RFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Qcm9w b3NhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5BZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1c2UNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41Ij4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRz LTA5I3NlY3Rpb24tMy41PC9hPiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPmFib3V0IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11bHRpcGxleGluZyBv ZiBEVExTIGFuZCBSVFAgb3ZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNhbWUgcG9ydCBwYWlyLCBhcyBkZXNj cmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NCNzZWN0aW9uLTUuMS4yIj4NCltSRkM1 NzY0XSwgc2VjdGlvbiZuYnNwOzUuMS4yPC9hPi4mbmJzcDsgQWxsIGFwcGxpY2F0aW9uIGxheWVy IHByb3RvY29sIHBheWxvYWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvdmVyIHRoaXMgRFRMUyBjb25uZWN0aW9uIGFy ZSBTQ1RQIHBhY2tldHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgTm90 ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnMgd2hl biBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBsaWVkLiBXZWJSVEMg ZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBEVExTIGNvbm5lY3Rp b25zIOKApiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxs b3ciPijigJx3aGljaCBvbmU/4oCdKTwvc3Bhbj4g4oCmIG9yIFRoZXJlIHNob3VsZCBiZSB0aGVu IGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24g ZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5v dGUgMjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGlu Zy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IFByb3RvY29sIGlkZW50aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxp ZWQgYXMgcGFydCBvZiB0aGUgRFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaGFuZHNoYWtlLCBhcyBzcGVjaWZpZWQg aW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0Zi1ydGN3ZWItYWxwbiI+SS1ELmlldGYtcnRjd2Vi LWFscG48L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Db21tZW50cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Vc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNj b3JkaW5nIHRvDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxs YS10bHMtdGVybWlub2xvZ3ktMDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt Z3ViYWxsYS10bHMtdGVybWlub2xvZ3ktMDEudHh0PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJlcm5h cmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQ8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+IEFzdmVyZW4sIFRvbGdhOyBDaHJpc3RlciBIb2xtYmVy ZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5i YWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNo cG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Nb3N0IG9mIHRoZSBwZW9wbGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlv dSBuZWVkIHRvIGNyZWF0ZSB0d28gRFRMUyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3Ro ZXIgZm9yIFJUQ1AuIEFuZCB0aGVuIHVzZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVu IGVuY3J5cHRpb24NCiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNlZSBv bmUgc2Vzc2lvbiBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3IgYm90 aCBSVFAgYW5kIFJUQ1AsIHdoaWNoIGlzIHdyb25nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24gbWlzdGFrZXMu ICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0 aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90IGNyeXN0YWwgY2xlYXIgb24g aG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFyZGVyIHRvIG1lc3MgdXAgUlRQ L1JUQ1AgbXV4LiAmbmJzcDtHaXZlbg0KIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBj b3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB9197FR711WXCHMBA03z_-- From nobody Wed Aug 5 01:17:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8DC1B2D93; Wed, 5 Aug 2015 01:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xljVL1EfJhUm; Wed, 5 Aug 2015 01:17:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689BD1B2DA3; Wed, 5 Aug 2015 01:16:59 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 977C4DB24FF8B; Wed, 5 Aug 2015 08:16:56 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t758Gvrw008305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Aug 2015 10:16:57 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 5 Aug 2015 10:16:57 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1aGMlfTH2VOiEWUETQoEL7QIZ39Dwuw Date: Wed, 5 Aug 2015 08:16:56 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC7ADB91EC@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_" MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:17:10 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0ZXIsDQpkbyBhZ3JlZSBvZiBjb3Vyc2UuDQpCdXQgaW5kZXBlbmRlbnQgb2YgdGhlIFJG QyA1NzY0IGNvcnJlY3Rpb24sIGJlbG93IGNsYXJpZmljYXRpb24gcHJvcG9zYWwgZm9yIHJ0Y3dl Yi10cmFuc3BvcnQgcmVtYWlucyB2YWxpZCAo4oCcZHVlIHRvIHRoZSBzaGFyaW5nIGFzc3VtcHRp b27igJ0pLg0KDQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcg W21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBNaXR0d29jaCwg NS4gQXVndXN0IDIwMTUgMTA6MTMNClRvOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyA8 cnRjd2ViQGlldGYub3JnPg0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3JnKQ0KU3ViamVj dDogUkU6IFtydGN3ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7 IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KSGksDQoNCldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBS VENXRUIgc3BlY3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNjaHdhcnosIEFs YnJlY2h0IChBbGJyZWNodCkNClNlbnQ6IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQNClRvOiA8cnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KQ2M6IFRMU0BpZXRmLm9yZzxt YWlsdG86VExTQGlldGYub3JnPiAodGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+KQ0K U3ViamVjdDogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9u czsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eA0KDQpSb21hbiwgQmVybmFyZCwNCnJpZ2h0LCBSRkMgNTc2NCBpcyB0b28gdmFndWUgb24gdGhh dCBhc3BlY3QuIFRoYW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lv bnMsIHdoaWNoIGlzIGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5kaW5nLg0KV291bGQgYXBwcmVj aWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQg ZHVlIHRvIHNpZ25pZmljYW50IHNpZGUgZWZmZWN0cy4NClRoaXMgdG9waWMgaXMgYWxzbyBhbiBv bmdvaW5nIEZBUS4NCg0KVGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJp byB3aXRoIHVzYWdlIG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0 IG11bHRpcGxleGluZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25u ZWN0aW9uLCB3aGljaCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS4N Cg0KQm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC40DQo9PiBidW5kbGluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNQ0KPT4gUlRQL1JUQ1Ag dHJhbnNwb3J0IG11bHRpcGxleGluZw0KDQpOb3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1c2VkIE9S IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0aGVyZSB3 aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAoZWl0aGVy IDIgb3IgNCBpbiBjYXNlIG9mIGF1ZGlvICYgdmlkZW8pLg0KUmFpc2luZyB0aGUgcXVlc3Rpb24g d2hpY2ggRFRMUyBjb25uZWN0aW9uIGlzIHVzZWQgZm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEg dHJhZmZpYz8gLSBCZWNhdXNlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KaW5kaWNhdGVzIHRoZSBzaGFyaW5n IG9wdGlvbi4NCldvdWxkIHRoZW4gYmUgYSAzcmQgKG9yIDV0aCkgc2VsZi1jb250YWluZWQgRFRM UyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz8NCg0KUHJv cG9zYWw6DQpBZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1c2UgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmFib3V0 IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZToNCg0KICAgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBN VVNUIHN1cHBvcnQgbXVsdGlwbGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyDQogICB0aGUgc2Ft ZSBwb3J0IHBhaXIsIGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb24N CiAgIFtSRkM1NzY0XSwgc2VjdGlvbiA1LjEuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTc2NCNzZWN0aW9uLTUuMS4yPi4gIEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBw YXlsb2Fkcw0KICAgb3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLg0K DQoNCg0KICAgTm90ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29u bmVjdGlvbnMgd2hlbiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBs aWVkLiBXZWJSVEMgZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBE VExTIGNvbm5lY3Rpb25zIOKApiAo4oCcd2hpY2ggb25lP+KAnSkg4oCmIG9yIFRoZXJlIHNob3Vs ZCBiZSB0aGVuIGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNv bm5lY3Rpb24gZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLg0KDQoNCg0K ICAgTm90ZSAyOiBUaGVyZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1 bmRsaW5nLg0KDQogICBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFz IHBhcnQgb2YgdGhlIERUTFMNCiAgIGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0 Zi1ydGN3ZWItYWxwbjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItdHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4+XS4NCg0KQ29tbWVudHM/ DQpSZWdhcmRzLA0KQWxicmVjaHQNCg0KUFMNClVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2Nv cmRpbmcgdG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1p bm9sb2d5LTAxLnR4dA0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFi b2JhQGdtYWlsLmNvbV0NClNlbnQ6IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNA0KVG86 IFJvbWFuIFNocG91bnQNCkNjOiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEVy aWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJhdXNjaGVuYmFjaCwg VXdlIChOb2tpYSAtIERFL011bmljaCk7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBz aG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywg Um9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29t Pj4gd3JvdGU6DQoNCk1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2lu Y2UgeW91IG5lZWQgdG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQg YW5vdGhlciBmb3IgUlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5 IGV2ZW4gZW5jcnlwdGlvbiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNl ZSBvbmUgc2Vzc2lvbiBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3Ig Ym90aCBSVFAgYW5kIFJUQ1AsIHdoaWNoIGlzIHdyb25nLg0KDQpbQkFdIFllcywgdGhhdCBpcyBv bmx5IG9uZSBvZiBzZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gIFVuZm9ydHVuYXRlbHksIFJGQyA1 NzY0IGRvZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3Vt ZW50cyBhcmUgbm90IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0 IGlzIG11Y2ggaGFyZGVyIHRvIG1lc3MgdXAgUlRQL1JUQ1AgbXV4LiAgR2l2ZW4gd2hhdCBJJ3Zl IHNlZW4gc28gZmFyLCBub24tbXV4IGNvdWxkIGJlY29tZSBhIHN1cHBvcnQgbmlnaHRtYXJlLg0K --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5kbyBhZ3JlZSBvZiBjb3Vyc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBp bmRlcGVuZGVudCBvZiB0aGUgUkZDIDU3NjQgY29ycmVjdGlvbiwgYmVsb3cgY2xhcmlmaWNhdGlv biBwcm9wb3NhbCBmb3IgcnRjd2ViLXRyYW5zcG9ydCByZW1haW5zIHZhbGlkICjigJxkdWUgdG8g dGhlIHNoYXJpbmcgYXNzdW1wdGlvbuKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDUuIEF1Z3Vz dCAyMDE1IDEwOjEzPGJyPg0KPGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gVExTQGlldGYub3JnICh0 bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ug c2hhbGwgbm90IG1ha2UgUkZDIDU3NjQgY29ycmVjdGlvbnMgaW4gdGhlIFJUQ1dFQiBzcGVjcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk8YnI+DQo8Yj5TZW50Ojwv Yj4gNS4gZWxva3V1dGEgMjAxNSAxMTowNDxicj4NCjxiPlRvOjwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+ICg8YSBo cmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbcnRjd2ViXSBOdW1iZXIgb2YgRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25z OyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZJIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj5Sb21hbiwgQmVybmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5yaWdodCwgUkZDIDU3NjQgaXMgdG9v IHZhZ3VlIG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBv ZiBEVExTIHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Xb3Vs ZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdoZXJlIGZpeGVkIGluIGFuIHJ0Y3dl YiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZlY3RzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRoaXMgdG9waWMgaXMgYWxzbyBh biBvbmdvaW5nIEZBUS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5UaGUgbW9zdCBzaW1wbGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlv IHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQg bXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEgc2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24sIHdoaWNoDQogY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ Qm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2Fn ZS0yNSNzZWN0aW9uLTQuNCI+PHNwYW4gbGFuZz0iREUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQ8L3NwYW4+PC9h Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YnI+DQo9Jmd0OyBidW5kbGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUj c2VjdGlvbi00LjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjU8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj49Jmd0OyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVs dGlwbGV4aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+Tm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3Bv cnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4g b25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZSBv ZiBhdWRpbw0KICZhbXA7IHZpZGVvKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMUY0OTdEIj5SYWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5l Y3Rpb24gaXMgdXNlZCBmb3IgYWRkaXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1 c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5pbmRpY2F0ZXMgdGhlIHNo YXJpbmcgb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPldvdWxkIHRoZW4gYmUgYSAzPHN1cD5yZDwvc3VwPiAob3IgNTxzdXA+dGg8L3N1 cD4pIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gZm9yIFdlYlJU QyBkYXRhIHRyYWZmaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+UHJvcG9zYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+QWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNzZWN0aW9uLTMuNSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4gPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5hYm91dCAoaW4gcmVkKSwgc29t ZXRoaW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3Vw cG9ydCBtdWx0aXBsZXhpbmcgb2YgRFRMUyBhbmQgUlRQIG92ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSBzYW1l IHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGluIHRoZSBEVExTLVNSVFAgc3BlY2lmaWNhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjQjc2Vj dGlvbi01LjEuMiI+DQpbUkZDNTc2NF0sIHNlY3Rpb24mbmJzcDs1LjEuMjwvYT4uJm5ic3A7IEFs bCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2FkczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb3ZlciB0aGlz IERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJl ZCI+Jm5ic3A7Jm5ic3A7IE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBzZXNzaW9ucy9E VExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBu b3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFyZSBvbmUgb2Yg dGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93 O21zby1oaWdobGlnaHQ6eWVsbG93Ij4o4oCcd2hpY2ggb25lP+KAnSk8L3NwYW4+IOKApiBvciBU aGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Np b24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBXZWJSVEMgZGF0 YS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpy ZWQiPiZuYnNwOyZuYnNwOyBOb3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFyIGNvbnNpZGVyYXRpb25z IGluIGNhc2Ugb2YgYnVuZGxpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBQcm90b2NvbCBpZGVudGlmaWNh dGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBhcnQgb2YgdGhlIERUTFM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGhhbmRz aGFrZSwgYXMgc3BlY2lmaWVkIGluIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFs cG4iPkktRC5pZXRmLXJ0Y3dlYi1hbHBuPC9hPl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlBTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VXNpbmcgKEQp VExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0bw0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4dCI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4dDwvYT4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBCZXJuYXJkIEFib2JhIFs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb20iPm1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTWl0dHdvY2gsIDUuIEF1Z3VzdCAyMDE1IDA0OjA0PGJyPg0KPGI+VG86PC9i PiBSb21hbiBTaHBvdW50PGJyPg0KPGI+Q2M6PC9iPiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIg SG9sbWJlcmc7IEVyaWMgUmVzY29ybGE7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJh dXNjaGVuYmFjaCwgVXdlIChOb2tpYSAtIERFL011bmljaCk7ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0 IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywgUm9tYW4gU2hwb3VudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1vc3Qg b2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2luY2UgeW91IG5lZWQgdG8gY3Jl YXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQgYW5vdGhlciBmb3IgUlRDUC4g QW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5IGV2ZW4gZW5jcnlwdGlvbg0K IHByb2ZpbGVzIGZvciBSVFAgYW5kIFJUQ1AuIEkgY29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZv ciBSVFAgYW5kIGtleXMgbmVnb3RpYXRlZCB0aGVyZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRD UCwgd2hpY2ggaXMgd3JvbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkFdIFllcywg dGhhdCBpcyBvbmx5IG9uZSBvZiBzZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gJm5ic3A7VW5mb3J0 dW5hdGVseSwgUkZDIDU3NjQgZG9lcyBub3QgcnVsZSBvdXQgYWxsIG9mIHRoZXNlIGFuZCB0aGUg c2VjdXJpdHkgZG9jdW1lbnRzIGFyZSBub3QgY3J5c3RhbCBjbGVhciBvbiBob3cgdGhpbmdzIG11 c3QgYmUgZG9uZS4gSXQgaXMgbXVjaCBoYXJkZXIgdG8gbWVzcyB1cCBSVFAvUlRDUCBtdXguICZu YnNwO0dpdmVuDQogd2hhdCBJJ3ZlIHNlZW4gc28gZmFyLCBub24tbXV4IGNvdWxkIGJlY29tZSBh IHN1cHBvcnQgbmlnaHRtYXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_786615F3A85DF44AA2A76164A71FE1AC7ADB91ECFR711WXCHMBA03z_-- From nobody Wed Aug 5 03:44:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8990F1B2F18 for ; Wed, 5 Aug 2015 03:44:26 -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 hEkz26P2Eaqf for ; Wed, 5 Aug 2015 03:44:24 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCC01B2DA0 for ; Wed, 5 Aug 2015 03:44:23 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 96523699FA; Wed, 5 Aug 2015 13:44:20 +0300 (EEST) Date: Wed, 5 Aug 2015 13:44:20 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150805104420.GA17150@LK-Perkele-VII> References: <1438691824.10777.9.camel@redhat.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Wed, 05 Aug 2015 10:44:26 -0000 On Tue, Aug 04, 2015 at 10:35:30AM -0700, Martin Thomson wrote: > > As for the wasted bytes, I don't care for that. We will fix that later. It is not just wasted bytes. It is also increased auditing requirements: Auditing that the nonce generation is sound (e.g. not random). And in constructs like this, if you get it wrong, you will notice very quickly (contrast to AES-GCM nonce generation: Serious errors can remain hidden). Also, unifying the GCM scheme, CCM scheme the scheme from this draft and TLS 1.3 scheme isn't hard (supporting CBC is loads more annoying, as it is much harder to unify[1]). [1] Well, there are tricks with TLS 1.1/1.2 CBC modes, but TLS 1.0 CBC modes just won't unify. -Ilari From nobody Wed Aug 5 11:13:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76261A8704 for ; Wed, 5 Aug 2015 11:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ea0EjqaCxBS for ; Wed, 5 Aug 2015 11:13:46 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A871A88DC for ; Wed, 5 Aug 2015 11:13:46 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so203269962wic.1 for ; Wed, 05 Aug 2015 11:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UT7MMcEvQlAHzWGRG0oa8OS1mvogvRYFIFzqrMHf8U8=; b=e2X9YDCmCBcBfnIHslDZ5KEdwpGn98zdWxH+yiPpEKjgb/fo+domQCwPmdS+aFfX+A r/iV6Gzcxj58hnVwsZZIWbZ2gXXMvwQ5M7H4H11OEHvISgPoLtoXiZ7eWs2/OpFKp+Xy +jYClEBhShi5NTx5clfi9VSEwd/bwcSCgX4II2Hrmt4BIRJnByX5xFnDEJvbYI1kMNq+ KuACGTMMrx22LUksBWv7J2rD9eb7UgqCxyAeLwTd8VXnbkMSuO71dlnUu3extKBacB1u l8jn/guekW6gBuNBQd9RnxEKfpaXYOA/84tmF63cPiNMMrlTzBXFUiMlDObWcqVte9FH mTKg== 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=UT7MMcEvQlAHzWGRG0oa8OS1mvogvRYFIFzqrMHf8U8=; b=PgLZX8Rzbd/mmFFp6OP+uu93MIU0X3UIAJn8tOspxAuaGBoCdpax36k+PGmM9NWv0X Cmv9XDhqyxZi1SOR3WAdnK4Sn1ll4d245NHlhC9KVChan/lJ2/YPBWd8XT0yTIjhs5iY xAssTMxGi0BQHvSUcg+GpsCKryeaHWzlMoUTN5qjTnZ2OkzSZA2dzq5FAYuCnXGdcvH8 OFnkOSVq1t+JxrS5rnmXXWf75ZM0YdsJsKEPi1Jsl1osuoDq7moOX2+tOByuvPQ3GhrY Cb2L/4bYk4jymdJlUv6vEVJLUQYoLErLFQkvJm0HVhHePvFq84npyAM2TEjPPPyF/T3K jRPA== X-Gm-Message-State: ALoCoQmDQrjCxWGgaREf+TUCa3O4z4yZbnbrm/1cQTRpVaWGt7aN1ZLc5UhGagmrTc65H3Cl8mn9 MIME-Version: 1.0 X-Received: by 10.194.6.37 with SMTP id x5mr24497990wjx.73.1438798425139; Wed, 05 Aug 2015 11:13:45 -0700 (PDT) Received: by 10.28.63.198 with HTTP; Wed, 5 Aug 2015 11:13:45 -0700 (PDT) In-Reply-To: References: <1438691824.10777.9.camel@redhat.com> Date: Wed, 5 Aug 2015 11:13:45 -0700 Message-ID: From: Wan-Teh Chang To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Wed, 05 Aug 2015 18:13:47 -0000 On Tue, Aug 4, 2015 at 10:35 AM, Martin Thomson wrote: > On 4 August 2015 at 10:24, Wan-Teh Chang wrote: >> The consistency you want to see seems to be >> consistency with the AES GCM cipher suites, rather than with TLS 1.2. > > Yes, this is correct. > > RFC 5288: > struct { > opaque salt[4]; > opaque nonce_explicit[8]; > } GCMNonce; > > RFC 6655: > struct { > opaque salt[4]; > opaque nonce_explicit[8]; > } CCMNonce; > > Interestingly, RFC 6655 removes the explicit nonce for DTLS, but DTLS > only (if I'm reading it correctly). I don't see that special handling for DTLS in RFC 6655. The only DTLS-specific statement in RFC 6655 is the clarification on how to build a 64-bit seq_num: In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the 48-bit seq_num. So I am afraid that you read it incorrectly. It doesn't seem useful to be consistent with the AES GCM and CCM cipher suites. In my experience implementing both ChaCha20+Poly1305 and AES GCM cipher suites in TLS 1.2, the lengths of the explicit nonce can be easily parameterized. I am now inclined to support adopting the draft-TLS 1.3 nonce mechanism for TLS 1.2. Specifically, this means in TLS 1.2, ChaCha20+Poly1305 has these parameters: SecurityParameters.record_iv_length = 0 // zero-length explicit nonce. // No change from // draft-ietf-tls-chacha20-poly1305-00. SecurityParameters.fixed_iv_length = 12 // increased from the value 4 used in // draft-ietf-tls-chacha20-poly1305-00. Then, define the ChaChaNonce struct as described in the draft-TLS 1.3. struct { opaque nonce[12]; } ChaChaNonce; 1. The 64-bit record sequence number is padded to the left with zeroes to 96 bits (12 octets). 2. The padded sequence number is XORed with either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending) 3. Store the XOR result in ChaChaNonce.nonce. Wan-Teh From nobody Wed Aug 5 14:17:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFD1AC3B2 for ; Wed, 5 Aug 2015 14:17: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 zVikphwdGW04 for ; Wed, 5 Aug 2015 14:17:10 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82241AC3A6 for ; Wed, 5 Aug 2015 14:17:09 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so224713998wib.0 for ; Wed, 05 Aug 2015 14:17:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=3wD3K243TKrIIX5+i/0GeFUS20zr6hC91YJxahUEdCc=; b=eUxU94wQcl4ZsGQIugk7T/3FR04degHFIAclu4iEMJlvBmyb3xaTiGo9Lzwzb4uzlj B4rFCPxyWprtQDDA6Ffg25fQ/GeWJl6ZZaUhTz77dleNkya4CevpH191lXj7gBXsunys 3BzabPucxbDtARywuuPaFRxUofezk4aIX+NY1Nu1Jl71tWnS2L1lQxhbY9LRsrIA6jH3 sJpRsFdg39zF6teNWKL+S/UsHsaUaU4H0hXmFliVMr28lZk+ohDbslbpuCwfZbQ1Ssb9 pDa9alsxryN2xBhVyXGlelgMcuWza9gsVPtWnpQqj3w6ForHtpw5NZ4qFrE6e29qa4+8 BYig== X-Gm-Message-State: ALoCoQnuTfly2Q4SWSCLKBVK7Ehp9M5LDxU5wNazbcZuhtfJrltq2OQMBgcvcpUNWgoVSyZTQpM7 X-Received: by 10.194.178.1 with SMTP id cu1mr23993823wjc.59.1438809428669; Wed, 05 Aug 2015 14:17:08 -0700 (PDT) Received: from [10.0.0.112] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by smtp.gmail.com with ESMTPSA id i6sm5946264wje.33.2015.08.05.14.17.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Aug 2015 14:17:07 -0700 (PDT) Message-ID: <55C27D51.4060502@azet.org> Date: Wed, 05 Aug 2015 23:17:05 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: TLS Mailing List References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <87vbf1384m.fsf@latte.josefsson.org> In-Reply-To: <87vbf1384m.fsf@latte.josefsson.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigDEC012CF859105BE03FE2118" Archived-At: Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.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, 05 Aug 2015 21:17:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDEC012CF859105BE03FE2118 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, A short update on the matter of IPR related to AES-OCB in TLS: It took some time but over the past couple of weeks all IPR exemptions have been filed by the original patent holders (Rogaway and IBM [Jutla]). These IPR exemptions can be viewed over here: https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-zauner= -tls-aes-ocb Specifically.. Rogaway: https://datatracker.ietf.org/ipr/2640/ IBM: https://datatracker.ietf.org/ipr/2647/ The current document is available on the IETF website, I've made a few minor editorial changes in my git repository [0] but not yet uploaded a new version of the document as I'm still waiting if people would like to see more substantial changes to the document. I'd be happy to receive feedback on the document and am looking forward for people to try out AES-OCB in TLS (an upcoming OpenSSL version will ship with default-support I am told). Thanks for your patience, Aaron [0] https://github.com/azet/draft-zauner-tls-aes-ocb/commits/master --------------enigDEC012CF859105BE03FE2118 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVwn1RAAoJEOTbZJL9ubXVNJAQAJyAjRIlvkfyyYd9e3frQC5A L5DCMj3jxGP4RVySXdPMhb4c/cGwy6IDCRtk/3zGAldcYV0PLBtcbVlFIYxXj+SU ncKzz+MtLMauhAqk9Uft/U+I/JoPxqdX++NgXweXjZVWT9I5AIKmvukd4a5wWCF+ oD50T+mayUn8ClWnNH+ePlnbVZPkPQ0vW3XjC+b3LBd+NaLG2IIx2bL6D7YRipof X6+p3u5rB/wQo4ymoiIQzopl81PVZI4kVc9lNevdtNmcMX7MJRezMcJ0qD24Bxal zG5zviusBPnfTPYnluExlSby9a9ltVA4kdssf3vbt80CUFop/cYhGP4NlKoG0qx5 NaEz1Z30Z1nHw6kOc8pmb7S36oEsHwVa9kb/puU4n6DpedBgRS4KHGWpqCkGP/qR w7oHpyo3idYf/REAJarSz60RKE9lH7MBnyYS21dI95PNOL502eSeDZZwilJyAEfM gztS4BQj5YBs0OiDW1p5zfLQ+l68WQ7IftRqNJ4d5DGk3JlyjNctg4s4NtByeVHO t7oE53wUR49rqGR2riY+LP5GvEiAOnJfbDWqALmsiWyIljrpbHme/nOpQTtSFxdf jskJUk7LaClK72iu8t7C+JG/DaCY20v0wJEWZise4Da7O9mq4VDTwVJIz2qIOpTy 5D/zyy4elCPQdxtZnPtH =NbSO -----END PGP SIGNATURE----- --------------enigDEC012CF859105BE03FE2118-- From nobody Wed Aug 5 15:37:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CA1ACE31 for ; Wed, 5 Aug 2015 15:37:05 -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 SlmRL0OpxJEI for ; Wed, 5 Aug 2015 15:37:04 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id B33DB1ACE11 for ; Wed, 5 Aug 2015 15:37:03 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t75Mb1mj031703; Wed, 5 Aug 2015 18:37:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Aaron Zauner , TLS Mailing List Thread-Topic: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.txt] Thread-Index: AdDPzz5Fld5Y/+3Mo06ccZ8owJA9ag== Date: Wed, 5 Aug 2015 22:37:00 +0000 Message-ID: <20150805223709.17788996.37225.15481@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1415813500==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-05_11:2015-08-05,2015-08-05,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-1506180000 definitions=main-1508050357 Archived-At: Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.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, 05 Aug 2015 22:37:05 -0000 --===============1415813500== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Aaron, Great work! I can't wait to see OCB standardized and implemented. One thing though. There has been mentioning of Gligor patent(s) - were you = able to look into that? Or perhaps Phil or Charanjit could comment on this = (though technical people seldom make legal statements :)? Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the Verizon=A0Wirele= ss=A04G=A0LTE=A0network. =A0 Original Message =A0 From: Aaron Zauner Sent: Wednesday, August 5, 2015 17:17 To: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zaune= r-tls-aes-ocb-03.txt] Hi, A short update on the matter of IPR related to AES-OCB in TLS: It took some time but over the past couple of weeks all IPR exemptions have been filed by the original patent holders (Rogaway and IBM [Jutla]). These IPR exemptions can be viewed over here: https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-zauner-t= ls-aes-ocb Specifically.. Rogaway: https://datatracker.ietf.org/ipr/2640/ IBM: https://datatracker.ietf.org/ipr/2647/ The current document is available on the IETF website, I've made a few minor editorial changes in my git repository [0] but not yet uploaded a new version of the document as I'm still waiting if people would like to see more substantial changes to the document. I'd be happy to receive feedback on the document and am looking forward for people to try out AES-OCB in TLS (an upcoming OpenSSL version will ship with default-support I am told). Thanks for your patience, Aaron [0] https://github.com/azet/draft-zauner-tls-aes-ocb/commits/master --===============1415813500== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKTM8n7QAAAABB0TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE1MDYwNTE4MTY0NFoXDTE2MDYwNDE4MTY0NFowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDQ 0ZYk84x0NrbLSMf9w+9rvO8Z3d5dfpynEt9it4HkQ3Fht5wpD1DOICbdPmcuoNGv73LUI6oRn7XT CnAFOeW9dGZetOUBIL44l0BoMYlUOvqOhtXUIoxm6PNbnDsYW3HpNuiskGO+jjH5CrvSFsZ//GHA dMGsQpRNBU7ZHCoOZF7+rv9RUh5pN5OgKumv9p24nWtGHNR1AHHDjB50Df9/1DVGhpe6aqf5DBhe f+1rf/dgAhjFSzrj3lTgNuczkZcB9Xs6fktq1jRCuwCdVTXQ/xgM5I3FHnVP73QEccOFR9qfdEVA 5IT7jo/7hMIvOBMWUJGOP7BpYXJd4VKj8CxLAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUr3pideNu 8mmOhHY8C2sJnlo/HVAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAKVaDwP2SaWtXtIINTrHpvDXC9dslWAv Tfg3TmHrQMtlKM6GQqkgIzF4WMZgM64RyUOqEnXrDcD7a3GPrcf8zDjRnsTiYaGkzhEUb/do5igL Al5x+FwAvhwvEuLJwHpAk0sfbxfX4lxY1S1YUngS+5PXGJbbFaNPAOefDG8jGgaM4TJ1weWlLT8F /MJudL6L6azCfOWQZhxpnT037XWGPeUfuqNnmwkwwlrCQB2QYgLQJtlUZQPqnb8Y2hd6OfhE7qvv /fcvX7i+Q4UKh3xGlMN2QHoX0Sk9sxxc4vgJnKk7MhaufGtOuNJLZlSfzCQRGd9Zprq9M+ROXuwN u72bKQkwggTqMIID0qADAgECAgpMzyftAAAAAEHRMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTUwNjA1MTgxNjQ0WhcNMTYwNjA0MTgxNjQ0WjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANDRliTzjHQ2tstIx/3D72u87xnd3l1+nKcS32K3geRDcWG3nCkPUM4gJt0+Zy6g0a/v ctQjqhGftdMKcAU55b10Zl605QEgvjiXQGgxiVQ6+o6G1dQijGbo81ucOxhbcek26KyQY76OMfkK u9IWxn/8YcB0waxClE0FTtkcKg5kXv6u/1FSHmk3k6Aq6a/2nbida0Yc1HUAccOMHnQN/3/UNUaG l7pqp/kMGF5/7Wt/92ACGMVLOuPeVOA25zORlwH1ezp+S2rWNEK7AJ1VNdD/GAzkjcUedU/vdARx w4VH2p90RUDkhPuOj/uEwi84ExZQkY4/sGlhcl3hUqPwLEsCAwEAAaOCAbIwggGuMB0GA1UdDgQW BBSvemJ1427yaY6EdjwLawmeWj8dUDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEFMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEApVoPA/ZJpa1e0gg1Osem 8NcL12yVYC9N+DdOYetAy2UozoZCqSAjMXhYxmAzrhHJQ6oSdesNwPtrcY+tx/zMONGexOJhoaTO ERRv92jmKAsCXnH4XAC+HC8S4snAekCTSx9vF9fiXFjVLVhSeBL7k9cYltsVo08A558MbyMaBozh MnXB5aUtPwX8wm50vovprMJ85ZBmHGmdPTftdYY95R+6o2ebCTDCWsJAHZBiAtAm2VRlA+qdvxja F3o5+ETuq+/99y9fuL5DhQqHfEaUw3ZAehfRKT2zHFzi+AmcqTsyFq58a0640ktmVJ/MJBEZ31mm ur0z5E5e7A27vZspCTCCBO0wggPVoAMCAQICCihwejIAAAAALQcwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNTAxMjMxNzQ5MjlaFw0xNjAxMjMxNzQ5MjlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxfkXLPYTTuYb5RNGHpbanlxlFtbt0VTBuP9moOidhYHLDicTmcv5vuxX mHwqN12Kzasev9yGZg0mJZ9yZ8cz4qJw3GytkyfcQDqFpa1MpAIYFJfjwjvGoQ1eWHNLZjM3+TFw a7Lm9J1MiXg5MTlGNiHefA9VFc814fSr43PmQnAURaFYgIJ+zM557ryvGOZuy6K9aC1ksTTVMqff IAuBKXRy5wPMj9Vqpja9MfmLLIyYBIiH2RasfBr79jqrR2hRh4e2OvljliGVCzGgHPSSRKvHLZ7P ZhiEZXX9iTBXDbGoUCQ4YFLKZj+nNVs/Tq1MbIMJxkOX3iKvXP+GGWBGfwIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFEdIXm5OIutOt2J6RBFV8kFMn0hTMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQA4puc4 02/4d3mv+ugzTOsEpotU4vRdn9vwK3tmu2vRPyD135Xod/ZVRu7k2p3hCTEh8w5bZAeZOg2DL/7d vJ7UJtoyyPWnTMHHA5SkkdriA7IgO46HYk8W6i/2kYvlguMm1loV7s0m5DHrGsreUACqbiiwK+53 sH2WlsfMz51lNZ1mQWyUe3CyoFE2hIkLvzZQliBSSAvckYc3vikeNbyGvu54kJ1ADY6GAgrt9mfM YMYSuJEK+bXlFVDQ6Ao9Nse/NRhX8ApJ8abFhJveTljNYmlyghifHIoqLpRM5LGVKyB3SJiEmkFV fl3Zm3Hdzh+svHzZdZmXV5/LMTSXPv4NMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgpMzyftAAAAAEHRMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgwNTIyMzcwN1owLwYJKoZIhvcNAQkEMSIEIGM57yCqZ2JM SMri9TMWUswe/hjbtrXALGlrrCzC9hGfMAsGCSqGSIb3DQEBCwSCAQB5Cy6QrbYfjluP1mgy2T4P FFYkNVanbLv3WP7yghhYFFrLFqHPe1n/wQgoY9ZFLjx3EpCl6J1xFbSLooieZtohByUK9/9DMXzC uJKwGQPVGlc/rsCj39QMmXLDarDR7ifIZsxRT4i5Dojsh7LMVGsf9xoQIYemlN0EqSF5dNEDUXb5 lk3TOLRn9+ef2hyZy8p+ijmEmf4Kk1BAIksGEBfEYlIg9VuHUlabhhbsGTZIAYjtHVtU74+hLRS6 o9PohM24/EmLyZDbqAxgWnreOuQM26rT1jdFgsLpR4oigxJ/54TBkQcb3MNIYERAEuNOLJs6KAbu oUCeCNHRuXizuSxgAAAAAAAA --===============1415813500==-- From nobody Wed Aug 5 15:48:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C6A1ACE5E for ; Wed, 5 Aug 2015 15:48:09 -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 Qjy-gcjOorqK for ; Wed, 5 Aug 2015 15:48:05 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479381ACE65 for ; Wed, 5 Aug 2015 15:48:05 -0700 (PDT) Received: by wicne3 with SMTP id ne3so834651wic.1 for ; Wed, 05 Aug 2015 15:48:04 -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=vPNPRIKjPQ1liWIoWnKrhjQdFzN8YU1LhHdgXULXG9E=; b=I5jzdpNbA5wjuXBmq+VnEblIMQ+R/c2KpLNHTs4BBVL1p3/mJ9xG8s2gqv1v0whjzP Zq49UpktUqhemOAhf1ceAVac5/g3VxV9IUKIIiHDgDImL2OqEA9Vc/1/BQoEBgIsOGlv 7dTSvl+TrW5kXMmlCB0Ej0r93zvy0BzAHMON3smy6qEM27R4XfU0kxQ3fwtj5Hw6arFD pwNwn8CqRCXPgXNZT+l/rC0pNsncZGtmAHIy6zJPFcmmgDSGDNzS12B1lEV4folmMLOk VQOEvh5zSzJtANdzV2D0uG0aXHaTleiIavhB2Y8fecdm4cAHkM4GFkv5F52DeGb3e9mh UkiQ== X-Gm-Message-State: ALoCoQkPL7RVjKjITBJBS85Btzk3WNn8JkWAxtTO0GSEOqx+JQC8QzAZbmxxR2Q6lbDx5OOwdDvE X-Received: by 10.180.74.52 with SMTP id q20mr90690wiv.94.1438814883921; Wed, 05 Aug 2015 15:48:03 -0700 (PDT) Received: from [10.0.0.112] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by smtp.gmail.com with ESMTPSA id yz10sm6291091wjc.0.2015.08.05.15.48.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Aug 2015 15:48:03 -0700 (PDT) Message-ID: <55C292A1.8080909@azet.org> Date: Thu, 06 Aug 2015 00:48:01 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Blumenthal, Uri - 0553 - MITLL" References: <20150805223709.17788996.37225.15481@ll.mit.edu> In-Reply-To: <20150805223709.17788996.37225.15481@ll.mit.edu> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig6667C22A10158FDF1BC2CDBF" Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.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, 05 Aug 2015 22:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6667C22A10158FDF1BC2CDBF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Blumenthal, Uri - 0553 - MITLL wrote: > Aaron, >=20 > Great work! I can't wait to see OCB standardized and implemented. >=20 > One thing though. There has been mentioning of Gligor patent(s) - were = you able to look into that? Or perhaps Phil or Charanjit could comment on= this (though technical people seldom make legal statements :)? >=20 I've written to Gligor and Donescu (his mail address is bouncing though and I do not have another/current one). I've not received any replies as of today. Rogaway, like myself, is not sure if that patent actually relates to OCB. He's included it in his initial IPR statement on RFC 7253 [0] as a pre caution as far as I can tell. The patent by Gligor and Donescu will expire on 18th of January 2021. Aaron [0] see https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-irtf-c= frg-ocb and https://datatracker.ietf.org/ipr/1682/ --------------enig6667C22A10158FDF1BC2CDBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVwpKhAAoJEOTbZJL9ubXVmdYQAKh9F1vnn3s0knUFbJDRjwNM C4u/XbKf6Vf8j3NpZlbTmGicPP9s689EHGfv3DvhaXKLutb3STgxDZcW9Z1jbMHZ 2SsZgH2ZNkQR9otG4lJA0xO13vX5jEblkHSY5Vr3eY4v30ks4TVINGHyhH1U3aeb DsIq9dBbqbJ16Ilwgm7aCWPPkrjJ5xr7AH4M07ixu4jLEHS8GdAnzuo2Ez5fDDo3 l5S/uoJuIJtqJ7G+RTPg45vwYFeol/JFlVsYynJryersY+rDaBoftEJGq62R5iZO kDw66mzwhWtA3e2ljngc2Jm/M41y6jiAqhs30/F1Y+JuwLmNC7aFFAHJoU4cO/KF pKXRHmN/9RboUfT3KBjmftH0Mdb2oe00SP6G7oUANmqazMKUAGppBLUF8nNfwOem LsjQQShw5/qinxdMFtVOSkmJ41XINV67syqgUcr2TpW9gccqs0q+dsZaM38OBRBn vYaqNz1Pitkc8N5uzLkzPcdFqiL0VXkUuDM0VKrgaZCIY0BcynCiPLrUX30Den2i V0nsOrlvrYqW5wQDGmSmVqG3myGZBKjg+aoNh52U8ADQ6vUyzzWXhI8cVvNaFwCr AvGkhFrv6cC7Rm5oTK5JrDug8Ka5KW/z7NuajC6Rwtmo0ySA2kD3wQr3RilWN2J1 oT5cJ6CxldLiKvjCXJRb =Q8O3 -----END PGP SIGNATURE----- --------------enig6667C22A10158FDF1BC2CDBF-- From nobody Wed Aug 5 22:29:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07A1B39A0 for ; Wed, 5 Aug 2015 22:29: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 SLhA8WvpGwOk for ; Wed, 5 Aug 2015 22:29:30 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591AA1B399E for ; Wed, 5 Aug 2015 22:29:29 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so7629181wic.1 for ; Wed, 05 Aug 2015 22:29:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ZzY/AGnHWLqDCJyyplJynh5+UihlMnd3+jSeIVtYOqI=; b=XF4aCWjXSI9CrNIxPl9L8LTocnr1WvXAh4BgZnD6+ngDKgNXukTN1LMgqYN++a3yk3 iOKyFmxU+HwKwZ6IVvFPEtZtv1cXJkFEqiEfOvRYL6FmfRMT4ddcaozYmDb2HaLNIRfc kguZh0RBKgrV7Rul+zdYOkbai/XmkkaqQTy0fU0J4mU53b+pcEUxhg9fRE0PYbQ1ww7f n9p/wMqk6whhMk5BS8V4ZWzE9sqXhqZEUqXv3MCAF5ohiE6wjaeRVGprXU/9gY8VWJRO v/3AoKhxfebd7XdygRvwxenTCur6ZugaNc3/w94m476/SW19FReWtvgjvp3eCPo36zf5 c5Wg== X-Gm-Message-State: ALoCoQkl3omu7C4kr7tkTEbJNm5BdsvCqCVtpO5pOoz5fZZOyyjVfgwxtqxv4/KRbT3+tzohd48u X-Received: by 10.194.171.129 with SMTP id au1mr29180433wjc.115.1438838968109; Wed, 05 Aug 2015 22:29:28 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by smtp.gmail.com with ESMTPSA id eu2sm1270106wic.8.2015.08.05.22.29.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 22:29:27 -0700 (PDT) Date: Thu, 6 Aug 2015 07:29:25 +0200 From: Aaron Zauner To: "Blumenthal, Uri - 0553 - MITLL" Message-ID: <20150806052924.GA7196@typhoon.azet.org> References: <20150805223709.17788996.37225.15481@ll.mit.edu> <55C292A1.8080909@azet.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <55C292A1.8080909@azet.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: TLS Mailing List Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.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: Thu, 06 Aug 2015 05:29:31 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=utf-8 Content-Disposition: inline PS: * Aaron Zauner [06/08/2015 00:48:03] wrote: > I've written to Gligor and Donescu (his mail address is bouncing though > and I do not have another/current one). I've not received any replies as > of today. Rogaway, like myself, is not sure if that patent actually > relates to OCB. He's included it in his initial IPR statement on RFC > 7253 [0] as a pre caution as far as I can tell. The patent by Gligor and > Donescu will expire on 18th of January 2021. FYI: It's only been 1.5w since I've written to them (holiday high season as well). Jutla now also reached out. Let's see how this goes. I'm optimistic. Aaron --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVwvC0AAoJEOTbZJL9ubXV9JMP/21unB+4HdI2KNl3HOROY6mI 7SiSt4FjKzx2pD+ny+na+jsi7ISnBL/wPVN89Wf4B46aCe1iaaIhex23XS6ObgM+ GyUG3lL9u0SlLtmMWBIrG3HgqrZxK4jPHILfM7mOhtV+15TZpsxABB8q0EyVmuCb BKz9NAtxISZyQl1meCba6LjXQzBySAsDLn7anj/X80Q8kxOMVkvl/cx4MGxKEQuD w2ygRz5xEDG8xUQNV7rpOxS6bgvcnVJfT9b1UVt0supl77tx3bVA+Pk+3EoBQfgc 8r/mEfLZlPB5vPeUiqp9P4gi3E+bPdAeqEVrvzvgnw0rWNW9Hkd+l9P2Ld/ql1/s rn9qLqoh68f7slTjmzCdpFG3VvD1RLDgUVO356Ej4cyBFIzTNGCJ7pQ8ZfnJOwXH LfNJGBBjF/6T+DVShrPR9ltDArrTYngQhyo+pJKddPSvgUcjctkEyiBr1sPbTPck 77jKZnQBDvyg3tNCLGHFl5kBDMJhrvtN5ka0UeUD0qNR8S0u8ktTFmuqPYRbtIsE TxXZPArKzraSUhY/mg0Zvf1eDrMuQM0lLJAAV5D94x0OeIfLpGoF//or8zCiSYA3 BlJ6SxmAc0XBEi4OtZ33czl0ctNTozgmqPaqPMFgU5zdJO4kokN5omjqYoeesMgM Ba9WgZhQHRmVob5XJWJN =q+Be -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From nobody Thu Aug 6 04:42:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521BA1B2DA9 for ; Thu, 6 Aug 2015 04:42: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 WwlLiycXmSzX for ; Thu, 6 Aug 2015 04:42:51 -0700 (PDT) Received: from ns3.dns-engine.com (ns3.dns-engine.com [87.106.189.53]) by ietfa.amsl.com (Postfix) with ESMTP id A8EA71B2D97 for ; Thu, 6 Aug 2015 04:42:51 -0700 (PDT) Received: from [10.102.1.6] (unknown [104.238.169.37]) by ns3.dns-engine.com (Postfix) with ESMTPSA id 791C818021E2 for ; Thu, 6 Aug 2015 12:42:31 +0100 (BST) Message-ID: <55C34810.6000708@baggins.org> Date: Thu, 06 Aug 2015 12:42:08 +0100 From: Matt Caswell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: tls@ietf.org References: <556C4ACD.9040002@azet.org> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <87vbf1384m.fsf@latte.josefsson.org> <55C27D51.4060502@azet.org> In-Reply-To: <55C27D51.4060502@azet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] AES-OCB in TLS [New Version Notification for draft-zauner-tls-aes-ocb-03.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: Thu, 06 Aug 2015 11:42:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/08/15 22:17, Aaron Zauner wrote: > I'd be happy to receive feedback on the document and am looking > forward for people to try out AES-OCB in TLS (an upcoming OpenSSL > version will ship with default-support I am told). We already have AES-OCB in libcrypto in OpenSSL master (forthcoming version 1.1.0). However we don't yet have any OCB TLS ciphersuite support and I'm not aware of anyone currently working on it. That's not to say it couldn't be included if someone were to provide a patch. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVw0gQAAoJENnE0m0OYESRDjIH/1BrzOANeT6lTC+rklcY4UFN 2DOeohxojCeYkB7e9XzvnFUqbpVrd8O+5SLMaCHzAz5510XdbunTegjjb5DZNkkL BI52Y3edP0ftTEa2o9tKBJ7ngkg+3cizGR8iVh3+m5Px6chluase8e8Zp6g9Agys nNvhRxAaycyPXA7z3GrzHzUSSNvA2v2Y9vN69qt+NUyicBxnMYZ7bztW3GEvA+l+ do/Oy0Uv0f3SLxierbnZ18QUaCr4+feWdeq7/B0TvXg5B7QV1Z0XPbVEPGSEv//K NnJrputtgGB2jfBzM75zI/z6AElyjM4nV1RWTx01qMfUh45xXX9mqrTRld044tk= =1V// -----END PGP SIGNATURE----- From nobody Thu Aug 6 06:22:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810B41B2F3B for ; Thu, 6 Aug 2015 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVPoDBWQH-HY for ; Thu, 6 Aug 2015 06:22:12 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9441B2F28 for ; Thu, 6 Aug 2015 06:22:12 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id DECB7C5217DDA; Thu, 6 Aug 2015 08:22:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id CE959C5217D77 for ; Thu, 6 Aug 2015 08:22:11 -0500 (CDT) Received: from [96.231.221.219] (port=53708 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZNL7b-0008a4-9b for tls@ietf.org; Thu, 06 Aug 2015 08:22:11 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <3057217.d0lbc7rhst@pintsize.usersys.redhat.com> Date: Thu, 6 Aug 2015 09:22:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150716014248.5333071.47478.4400@certicom.com> <201507152242.55454.davemgarrett@gmail.com> <3057217.d0lbc7rhst@pintsize.usersys.redhat.com> To: "" X-Mailer: Apple Mail (2.1878.6) 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.221.219 X-Exim-ID: 1ZNL7b-0008a4-9b X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:53708 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] sect571r1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 13:22:14 -0000 I looks like we=E2=80=99ve come to WG consensus that the sect571r1 curve = should be removed from the TLS 1.3 & 4492bis drafts. spt On Jul 20, 2015, at 09:08, Hubert Kario wrote: > On Wednesday 15 July 2015 22:42:54 Dave Garrett wrote: >> On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: >>> What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the = way >>> it has no unexplained constants...). Has it been removed already, or = does >>> the question also refer K-571 too? >> Already dropped. That's obviously not irreversible, but it's = unambiguously >> in the virtually unused camp. The initial goal was to drop all = largely >> unused curves. >>=20 >> This question is just about sect571r1, which is far closer to = secp384r1 & >> secp521r1 in terms of usage, though still notably less. If you want = to >> argue for going with sect571k1 and not sect571r1, I don't think the = WG is >> on-board with that. Even if we continued to allow it, I doubt much = would >> add support for it to be worthwhile. >=20 > This is likely just an artefact of use of OpenSSL curve order, if = K-571 was=20 > first, the servers would likely select it over B-571 more often >=20 >> The scan I linked to found one; literally a single server on the = entire >> Internet, >=20 > _not_ a single server in the Internet, a single server among Alexa top = 1=20 > million websites - the scan is checking only a set of popular = _websites_, not=20 > even all popular services that use TLS, let alone the whole Internet >=20 >> that actually supports sect571k1 for ECDHE. The stats also show >> 1575 "support" it, so I'm not sure what's going on there = specifically. (if >> someone can explain this bit of those stats, please do) >=20 > The "Supported PFS" section describes what the server selects if the = client=20 > advertises default OpenSSL order of all defined curves. The "Prefer" = lines,=20 > means that the ciphersuite selected by server by default uses this key=20= > exchange. >=20 > IOW, if server supports FFDHE 2048 and ECDHE P-256 and prefers ECDHE, = then the=20 > server will be counted in three lines: > DH,2048bits > ECDH,P-256,256bits > Prefer ECDH,P-256,256bits >=20 > The "Supported ECC curves" section describes what curves the server = will use=20 > for ECDHE key exchange if its preferred one is not advertised by = client (in=20 > most cases that means what happens if the client doesn't advertise = P-256=20 > curve). Then that curve is removed and the process repeated until the = server=20 > picks a ciphersuite that doesn't use ECDHE or aborts connection. >=20 > feel free to ask more questions about the scans if something is still = unclear > --=20 > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech = Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 6 10:24:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4C1A21C3 for ; Thu, 6 Aug 2015 10:24: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1Jk28tp8s-h for ; Thu, 6 Aug 2015 10:24:14 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AA31A1F02 for ; Thu, 6 Aug 2015 10:24:14 -0700 (PDT) Received: by labjt7 with SMTP id jt7so35720739lab.0 for ; Thu, 06 Aug 2015 10:24: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:date:message-id:subject:from:to :content-type; bh=5SxpeNux9CLMi0fRWQfLKJHyTs/ByO/RDktxGX4toog=; b=bqPBdhOnQli2jutIKBxhTUuXYLGHPQ/9ciNEu4mwiYD4Vg+WSY1em49TFhrwS/IbIF cYz4AyOFsT4aRhyfjeXohb2vUFHJqORDQmjfvkysYOgUA4A3y2KJSl3+2W8a1+HeOQc1 IckyLvOyctCv3OFitv4+9HbvCuqLaANzBk79xGymo+aouYADYwQoW3Vx/lk0tlf0Ew6V GX+XEODsxFIhKkB5H0aUpzgps5XLeQpLKXnOC8NhHtTk4dam5OdxIW4/9+g+ZCNKE8nv 8+/QyzxGk/m8ERMJUHx3NfeVs1epL0PKU7GYiILaly7TGhrcyoyBs5swFBQw5kZ8hJkh 7a4Q== X-Gm-Message-State: ALoCoQnMiTfdu4lUjHQO/htcZKAJSKsKRQUzgxbdGNeW2GTxiu22a9ig39ENhi3HaIoPwO/L5bMy MIME-Version: 1.0 X-Received: by 10.112.158.70 with SMTP id ws6mr3526467lbb.28.1438881852616; Thu, 06 Aug 2015 10:24:12 -0700 (PDT) Received: by 10.112.122.17 with HTTP; Thu, 6 Aug 2015 10:24:12 -0700 (PDT) Date: Thu, 6 Aug 2015 10:24:12 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c23886b315fe051ca7c929 Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-cached-info-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 17:24:16 -0000 --001a11c23886b315fe051ca7c929 Content-Type: text/plain; charset=UTF-8 Hi Folks, This is the Working Group last call for draft-ietf-tls-cached-info-19. This document has undergone modification since last WGLC so another WGLC is appropriate. This document is a dependency for the DICE working group TLS/DTLS profile. Please send your comments to the TLS list by September 2, 2015. Thanks, J&S --001a11c23886b315fe051ca7c929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks,=C2=A0

This is th= e Working Group last call for=C2=A0draft-ietf-tls-cached-info-19.=C2=A0 Thi= s document has undergone modification since last WGLC so another WGLC is ap= propriate.=C2=A0 This document is a dependency for the DICE working group T= LS/DTLS profile. Please send your comments to the TLS list by September 2, = 2015.=C2=A0

Thanks,

J&S =C2=A0
--001a11c23886b315fe051ca7c929-- From nobody Thu Aug 6 11:02:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D571B3CC8 for ; Thu, 6 Aug 2015 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzdETbN7UKVz for ; Thu, 6 Aug 2015 11:02:23 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7BB1B3CC4 for ; Thu, 6 Aug 2015 11:02:23 -0700 (PDT) Received: by labow3 with SMTP id ow3so54191543lab.1 for ; Thu, 06 Aug 2015 11:02: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=nBapgLErZuUvNjRdr1PQ+m5IDqt4uxEZFMEPNtzt6xw=; b=vABfERquhQRpA/on1QbfyGqRUI/dHQ+YSFut4GKJorU4jK5KhUme19/7wLkhRTHxb0 6/X6UhVrKyJYbZOzJNpCddoAmwSBKYjVykGWQX/fYXf+6NXQlVYiNS+gitmAYZVF63mu KnrmM6pDCXpOaVglB5Wg8qFnm/zNlLAztxV8BUURy67qVVceQGczlfTDvCbvRxgAnUe/ K7dgSrqoIm8/nF1GDayU4Oz66PQR4tkmOL7/CmRD/yAzr5W6CQvnslts0KDHf5ft0D/M 1qWHcuZGea8EDlPoWW/os5LCal4Hc0V7qw0fNaq/LmQ8JWzBzpIHzu+xB9n34MU5T4xX SC0A== MIME-Version: 1.0 X-Received: by 10.112.55.105 with SMTP id r9mr3652832lbp.89.1438884141808; Thu, 06 Aug 2015 11:02:21 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 11:02:21 -0700 (PDT) In-Reply-To: References: <1438691824.10777.9.camel@redhat.com> Date: Thu, 6 Aug 2015 11:02:21 -0700 Message-ID: From: Martin Thomson To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] open issues for draft-ietf-tls-chacha20-poly1305-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: Thu, 06 Aug 2015 18:02:25 -0000 On 5 August 2015 at 11:13, Wan-Teh Chang wrote: > Then, define the ChaChaNonce struct as described in the draft-TLS 1.3. > > struct { > opaque nonce[12]; > } ChaChaNonce; > > 1. The 64-bit record sequence number is padded to the left with > zeroes to 96 bits (12 octets). > 2. The padded sequence number is XORed with either the > client_write_IV (when the client is sending) or the > server_write_IV (when the server is sending) > 3. Store the XOR result in ChaChaNonce.nonce. This looks fine. Note that the general construction in TLS 1.3 should be, more formally: assert(N_MAX > 64bits) nonce = {client|server|_{read|write}_IV[0..N_MAX] XOR lpad0(seq_num) Of course, ChaChaX sets N_MAX to 96 bits, so what you described was correct. --Martin From nobody Thu Aug 6 13:33:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D51A00C8 for ; Thu, 6 Aug 2015 13:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSzohNQmnXsZ for ; Thu, 6 Aug 2015 13:33:53 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F86E1A001A for ; Thu, 6 Aug 2015 13:33:53 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so22221348lbb.3 for ; Thu, 06 Aug 2015 13:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rMh2BPeC695DaSKJk2t4uLrWlEvhq5UEoD2TuEz7ItQ=; b=QnMxikVOijm+pOlp+y+GghxsX8J0gwoVuvSOE/5bNHPbtTddWY5n/NjVoCGjQmljyz YEi8a+dZ83x+81UoGv11E8bjon3j61WW2XRaoxUG7Jl1ohVAHuu29j5tpZ3Vl6vkyZOl dxHoHv2vffGm2GL9Au8PRp0QwaWESdNOSqKC+y8PbKRoAPlZVTKxAkdQydfDiQ+y6ctq w4N0OzFAZteNQsCu1y4EZRDMp1Uf4rnAUYhdu6nHJkaQPEh+pA2YVw7R3WjrsjfyPdu2 USQH3U1JW4qJoIjbRjo+TWZ+Z9UzSI0UsNpgP3wlpmJagRxX0FKxXOi6KWQSQlRsl09A Aaog== MIME-Version: 1.0 X-Received: by 10.152.121.4 with SMTP id lg4mr4178541lab.112.1438893231800; Thu, 06 Aug 2015 13:33:51 -0700 (PDT) Received: by 10.25.197.87 with HTTP; Thu, 6 Aug 2015 13:33:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Aug 2015 13:33:51 -0700 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:33:55 -0000 I've read this draft before, but this is considerably different to what I read, and I haven't been following the discussion, so consider this as a review with fresh eyes. First the high points. I think that this is useful, the right scope, and reasonably well formulated. I have a couple of minor points Figure 2 is in error: it shows CertificateRequest instead of Certificate. I'd like to see the document explicitly note that msg_type and length from the handshake message are not covered by the hash. The description of what is covered is a little too terse (and badly formatted). I'm not sure that I like the lack of both negotiation and signaling for the hashes that are used here. Though I think the chances of a collision being found, or that a collision would lead to an attack, are slim, I would rather see this use the PRF hash so we have at least that much flexibility. If the current design is retained, I would like to see a little discussion of this in the document. A little analysis of the properties we expect the hash to provide would also be good. I think that truncated hashes might be advantageous from the server side. Given that the server only uses hashes to identify which of the offered (available, known?) cached information is in use, is there any reason you can't save additional space by arbitrarily truncating the hash? In many cases I would imagine that the client would be offering only one option and even if there were a small number of options presented, a single byte would suffice to disambiguate. I'm trying to think why you might want the full-length hash on the client side, but I believe that the only problem there is that there might be a collision between the certificates that a server might offer if you truncate too aggressively. The connection still relies on the server presenting proof of knowledge of a key that the client extracts from a certificate bound to the server identity, so I believe that it would be equally secure if you removed all mention of certificates from the protocol. And that makes me nervous, because I'm fairly sure that Karthik will tell me that I'm wrong very shortly; since we've put in a lot of work to cover key fields in the handshake hash, and I'm concerned that this could be exploited somehow. The more I think about this, the more I think that we need a little more analysis on this point (i.e., what properties the hash function needs to provide and why). If it has already happened, mention of that in the security considerations is needed. (I think that truncation on the server side is safe if the client uses a strong hash function to identify the certificate, but I'm frequently wrong about these things.) On 6 August 2015 at 10:24, Joseph Salowey wrote: > Hi Folks, > > This is the Working Group last call for draft-ietf-tls-cached-info-19. This > document has undergone modification since last WGLC so another WGLC is > appropriate. This document is a dependency for the DICE working group > TLS/DTLS profile. Please send your comments to the TLS list by September 2, > 2015. > > Thanks, > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Aug 6 13:35:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162D31A0334 for ; Thu, 6 Aug 2015 13:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qinsbsfxlBlM for ; Thu, 6 Aug 2015 13:35:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000751A00D0 for ; Thu, 6 Aug 2015 13:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10532; q=dns/txt; s=iport; t=1438893310; x=1440102910; h=from:to:subject:date:message-id:mime-version; bh=AsCH/r5fS4MWNv+TrEpKj4kukQEI5JBJ0JxhLxFlbF4=; b=dtq3oTR8UZwvJBq8FJN3YKb0OyMWljBNfNc79CuLZcxWdXUatT81kJWI e9UanwiTuou8KxJPGQIl8O4oDjB+/c6NFcmRdOckrg8bYcK2NbmQWnl4/ M+aPOQoacmIZ7N+P8rLB7NYi3k25fIOqkP4ElOHF30qAc4UpKCnvJKY82 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjAwCRxMNV/5pdJa1bgk5NVG+9EQmGbYEQAoFJOBQBAQEBAQEBfwuEJQEELV4BKlYmAQQbE4gTqBamEwEBAQEBAQQBAQEBAR2QJ4NQgRQFkX2DBAGmRSaCDQEBG4FTgjeBBAEBAQ X-IronPort-AV: E=Sophos; i="5.15,624,1432598400"; d="scan'208,217"; a="16526440" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 06 Aug 2015 20:35:04 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t76KZ40r017767 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Aug 2015 20:35:04 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 6 Aug 2015 15:35:03 -0500 Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 6 Aug 2015 15:35:03 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.103]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Thu, 6 Aug 2015 15:35:03 -0500 From: "Scott Fluhrer (sfluhrer)" To: "tls@ietf.org" Thread-Topic: Comments on the TLS 1.3 draft Thread-Index: AdDQh1sDmNL//7S4RNq25TsEbTcNdQ== Date: Thu, 6 Aug 2015 20:35:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.58] Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340420D164FC1xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Comments on the TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:35:14 -0000 --_000_A113ACFD9DF8B04F96395BDEACB340420D164FC1xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I recently reviewed the most recent TLS 1.3 draft, and I must say that I am= impressed; the protocol appears to be a significant improvement. In parti= cular, you simplify the protocol significantly, and as we all know, complex= ity is the enemy of security. You also drop many of the weak options, such= as RC4 and the export ciphers; that sounds like an excellent idea. That said, I do see a few things that puzzle me: - When dealing with ECDSA signatures, the default hash algorithm i= s SHA1, and any other hash function needs to be specified explicitly. Migh= t I ask why that is? No one has demonstrated a SHA1 collision yet; however= people are creeping closer. If you ask me (which you didn't, but I'll giv= e my opinion anyways), the default should be (at least) SHA-256; you should= allow SHA-1 as a downgrade option only if someone makes a strong case that= they can implement ECDSA and the rest of TLS 1.3, but implementing SHA-256= is just too hard. Otherwise, it should be discarded just like the other k= nown weak cryptographical primitives (such as RC4). - You also allow the provision of someone using MD5 as the hash al= gorithm. Take the above comments about how SHA-1 is not a good idea, and m= ultiply it by a factor of about 10. I see no justification for allowing so= meone to use a known broken hash algorithm. - Given the general theme of simplification, I was a bit puzzled b= y something; you appear to provide two different solutions to "how do I qui= ckly reestablish a TLS tunnel"; you have both 0-RTT and session resumption.= While both appear to have minor advantages over the other, I don't immedi= ately see any real justification for including the complexity of both. Now= , it might be that I'm catching a draft in the middle, and that you fully i= ntend to combine them. Alternatively, there might be strong reasons to hav= e both (and it just doesn't occur to me). In either of those two cases, "ne= ver mind" However, despite these minor nits, I would end with saying that the working= group has done good work on this draft; I look forward to the end product. Thanks! --_000_A113ACFD9DF8B04F96395BDEACB340420D164FC1xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I recently reviewed the most recent TLS 1.3 draft, a= nd I must say that I am impressed; the protocol appears to be a significant= improvement.  In particular, you simplify the protocol significantly,= and as we all know, complexity is the enemy of security.  You also drop many of the weak options, such as R= C4 and the export ciphers; that sounds like an excellent idea.

 

That said, I do see a few things that puzzle me:

 

-     &= nbsp;    When dealing with ECDSA signatures, the default has= h algorithm is SHA1, and any other hash function needs to be specified expl= icitly.  Might I ask why that is?  No one has demonstrated a SHA1= collision yet; however people are creeping closer.  If you ask me (which you didn’t, but I’ll give m= y opinion anyways), the default should be (at least) SHA-256; you should al= low SHA-1 as a downgrade option only if someone makes a strong case that th= ey can implement ECDSA and the rest of TLS 1.3, but implementing SHA-256 is just too hard.  Otherwise, it should be disca= rded just like the other known weak cryptographical primitives (such as RC4= ).

-     &= nbsp;    You also allow the provision of someone using MD5 a= s the hash algorithm.  Take the above comments about how SHA-1 is not = a good idea, and multiply it by a factor of about 10.  I see no justif= ication for allowing someone to use a known broken hash algorithm.

-     &= nbsp;    Given the general theme of simplification, I was a = bit puzzled by something; you appear to provide two different solutions to = “how do I quickly reestablish a TLS tunnel”; you have both 0-RT= T and session resumption.  While both appear to have minor advantages over the other, I don’t immediately see any= real justification for including the complexity of both.  Now, it mig= ht be that I’m catching a draft in the middle, and that you fully int= end to combine them.  Alternatively, there might be strong reasons to have both (and it just doesn’t occur to me). In= either of those two cases, “never mind”

 

However, despite these minor nits, I would end with = saying that the working group has done good work on this draft; I look forw= ard to the end product.

 

Thanks!

--_000_A113ACFD9DF8B04F96395BDEACB340420D164FC1xmbrcdx04ciscoc_-- From nobody Thu Aug 6 13:41:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABFF1A6F2D for ; Thu, 6 Aug 2015 13:41: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 5K0TMqGsUzqf for ; Thu, 6 Aug 2015 13:41:03 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1021D1A1DBC for ; Thu, 6 Aug 2015 13:41:03 -0700 (PDT) Received: by wicgj17 with SMTP id gj17so37284045wic.1 for ; Thu, 06 Aug 2015 13:41:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1P9/c3NXUNKDzrcJUAFcc0Xzle84iCEX9HF3IWxgbCc=; b=Fbw4hcAD5WSm65o4gmGJt7zO0u2aifwKZt6nqLK9H8XJBAf4rSlVS/Ttk6imJCRfGP RuAefW79TQzfO1t0afHzK4t79Rx1xjvwSnsh2ptmsS9wqC006iKJSvDmET7WYzCcoFfq pQ67r1kL71z2EZmw20OkplHVPEWaUe3im1B3kpHxygxP+75bqrc4KWCpCrBc8gk2UkFD XvHweJgDb1mhCZ9uj+o/YxHKb/UI+RMa95YOwoOW2HmvyZ5sQ9jK2arcIgiS8oRMSH0S oW85NhpfUDF03WbxHS/IwH4jK7qd6Y56WJNaYGPSTGerDb2XJFn0zXRGoSzYaTUcs6yq Bf+g== X-Gm-Message-State: ALoCoQlzZfcfyKfMD7qefyP6w90msceitlNvGz0IMBTarpRV+J8OyUyQDfflFt/GmdCRJ6BfYlvk X-Received: by 10.194.133.73 with SMTP id pa9mr7042499wjb.148.1438893661785; Thu, 06 Aug 2015 13:41:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Thu, 6 Aug 2015 13:40:22 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 6 Aug 2015 13:40:22 -0700 Message-ID: To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=089e011771a994a51e051caa8971 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on the TLS 1.3 draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 20:41:05 -0000 --089e011771a994a51e051caa8971 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) wrote: > I recently reviewed the most recent TLS 1.3 draft, and I must say that I > am impressed; the protocol appears to be a significant improvement. In > particular, you simplify the protocol significantly, and as we all know, > complexity is the enemy of security. You also drop many of the weak > options, such as RC4 and the export ciphers; that sounds like an excellen= t > idea. > > > > That said, I do see a few things that puzzle me: > > > > - When dealing with ECDSA signatures, the default hash algorithm > is SHA1, and any other hash function needs to be specified explicitly. > Might I ask why that is? No one has demonstrated a SHA1 collision yet; > however people are creeping closer. If you ask me (which you didn=E2=80= =99t, but > I=E2=80=99ll give my opinion anyways), the default should be (at least) S= HA-256; > you should allow SHA-1 as a downgrade option only if someone makes a stro= ng > case that they can implement ECDSA and the rest of TLS 1.3, but > implementing SHA-256 is just too hard. Otherwise, it should be discarded > just like the other known weak cryptographical primitives (such as RC4). > > - You also allow the provision of someone using MD5 as the hash > algorithm. Take the above comments about how SHA-1 is not a good idea, a= nd > multiply it by a factor of about 10. I see no justification for allowing > someone to use a known broken hash algorithm. > This is just a transient state. We have patches in progress to remove both of these. - Given the general theme of simplification, I was a bit puzzled > by something; you appear to provide two different solutions to =E2=80=9Ch= ow do I > quickly reestablish a TLS tunnel=E2=80=9D; you have both 0-RTT and sessio= n > resumption. While both appear to have minor advantages over the other, I > don=E2=80=99t immediately see any real justification for including the co= mplexity > of both. Now, it might be that I=E2=80=99m catching a draft in the middl= e, and > that you fully intend to combine them. Alternatively, there might be > strong reasons to have both (and it just doesn=E2=80=99t occur to me). In= either of > those two cases, =E2=80=9Cnever mind=E2=80=9D > Each of these has some benefit, though I agree that it would be nice to combine them. The big issue is: - For security reasons it's much easier to work with 0-RTT DH exchanges. - For performance reasons it's nice to have resumption. -Ekr > > > However, despite these minor nits, I would end with saying that the > working group has done good work on this draft; I look forward to the end > product. > > > > Thanks! > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e011771a994a51e051caa8971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) <sfluhrer@ci= sco.com> wrote:

I recently reviewed the most recent TLS 1.3 draft, a= nd I must say that I am impressed; the protocol appears to be a significant= improvement.=C2=A0 In particular, you simplify the protocol significantly,= and as we all know, complexity is the enemy of security.=C2=A0 You also drop many of the weak options, such as R= C4 and the export ciphers; that sounds like an excellent idea.

=C2=A0

That said, I do see a few things that puzzle me:<= /u>

=C2=A0

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When dealing with ECDSA signatures, the default hash a= lgorithm is SHA1, and any other hash function needs to be specified explici= tly.=C2=A0 Might I ask why that is?=C2=A0 No one has demonstrated a SHA1 co= llision yet; however people are creeping closer.=C2=A0 If you ask me (which you didn=E2=80=99t, but I=E2=80=99ll gi= ve my opinion anyways), the default should be (at least) SHA-256; you shoul= d allow SHA-1 as a downgrade option only if someone makes a strong case tha= t they can implement ECDSA and the rest of TLS 1.3, but implementing SHA-256 is just too hard.=C2=A0 Otherwise, it should be disca= rded just like the other known weak cryptographical primitives (such as RC4= ).

-=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You also allow the provision of someone using MD5 as t= he hash algorithm.=C2=A0 Take the above comments about how SHA-1 is not a g= ood idea, and multiply it by a factor of about 10.=C2=A0 I see no justifica= tion for allowing someone to use a known broken hash algorithm.


Thi= s is just a transient state. We have patches in progress to remove both
of these.

-=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Given the general theme of simplification, I was a bit puzzle= d by something; you appear to provide two different solutions to =E2=80=9Ch= ow do I quickly reestablish a TLS tunnel=E2=80=9D; you have both 0-RTT and = session resumption.=C2=A0 While both appear to have minor advantages over the other, I don=E2=80=99t immediately see a= ny real justification for including the complexity of both.=C2=A0 Now, it m= ight be that I=E2=80=99m catching a draft in the middle, and that you fully= intend to combine them.=C2=A0 Alternatively, there might be strong reasons to have both (and it just doesn=E2=80=99t occur to me). = In either of those two cases, =E2=80=9Cnever mind=E2=80=9D

<= /blockquote>

Each of these has some benefit, though I ag= ree that it would be nice to combine them.
The big issue is:

- For security reasons it's much easier to work wi= th 0-RTT DH exchanges.
- For performance reasons it's nice to= have resumption.

-Ekr
=C2=A0

=C2=A0

However, despite these minor nits, I would end with = saying that the working group has done good work on this draft; I look forw= ard to the end product.

=C2=A0

Thanks!


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


--089e011771a994a51e051caa8971-- From nobody Thu Aug 6 22:40:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED721B363E for ; Thu, 6 Aug 2015 22:40:02 -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 0QfxOgPy3ySy for ; Thu, 6 Aug 2015 22:40:00 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51541B363B for ; Thu, 6 Aug 2015 22:39:59 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DA1A4699C2 for ; Fri, 7 Aug 2015 08:39:56 +0300 (EEST) Date: Fri, 7 Aug 2015 08:39:56 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150807053956.GA5394@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: [TLS] Adding a new signature scheme X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 05:40:03 -0000 This is about adding a new signature primitive (such as the (eventual) CFRG scheme). There are basically two issues: 1) Do we allocate new ciphersuite codepoints or not? So far each certificate algorithm in ciphersuite has corresponded to only one signature algorithm. Implications of new codepoints: - More ciphersuites (about 11). - Needs TLS 1.2+ anyway, because the ciphers are presumably AEAD mode and those need TLS 1.2+. - Keep existing semantics. Implication of reusing ECDSA codepoints. - No new ciphersuites - Needs TLS 1.2+ - Redefines existing semantics a bit. 2) What does the SignatureAndHashAlgorithm.hash mean exactly? The TLS 1.2 RFC isn't specific enough. I see two choices: a) The field sets hash (prehash) to perform before passing the hash to be signed (the description of "none" and description of Certificate Verify message hints at this interpretation). b) The field parameterizes the signature scheme in some scheme- specific way (but what would "none" mean in context of this, the scheme having no hash parameters?). All the existing schemes are compatible with interpratation a). But for proposals for CFRG scheme: All proposed schemes have a hash parameter (the only one or one of two) that is incompatible with interpretation a): 1) Only one hash that does not prehash the message. 2) Two hash functions, one prehash (can be identity) and one internal hash. Prehash can be chosen per-signature. 3) Two hash functions, one prehash (can be identity) and one internal hash. Prehash is not indicated, so one has to be careful changing it. So if interpretation a) is the correct one, one presumably has to fix the internal hash in signature scheme codepoint (E.g. to SHA-512 for signature scheme #4). -Ilari From nobody Fri Aug 7 14:50:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537741A1A97 for ; Fri, 7 Aug 2015 14:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gP1iwd7WadK for ; Fri, 7 Aug 2015 14:50:56 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F641A1A04 for ; Fri, 7 Aug 2015 14:50:55 -0700 (PDT) Received: by wicne3 with SMTP id ne3so74527896wic.1 for ; Fri, 07 Aug 2015 14:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i21hygIt6h2SZSEcJuHpvbhBZlE4KRNiYDljZ6bpDuU=; b=CD+z6eslcIL5Eab855YSJKMSDBLvmHtd4gcoQCcwUmJ5CQDkg1z4DcyeNbHVvvmalJ vsQ3IJyDSaoXRS8vBRbC6ZAu/kpQSePOfa/lUBny+SdgsZe5JCP9UIMVFEvT8rEUeKPQ NO3bB+g6Gb6Plvp8HUg2pD0zFp7X/9XvGcsgc24toF8hDS04CAQ2h8L6I5sZIYVutlj/ Q6+InGdr0CmJl49q8ASMD4dTP7vlND2/R38gu9xAcZt556bGwGfhBO/FegsizjXwDxT+ yIUVX7cJH8x9mjtwuzIYL9quGDOXZa8jRdeDryFvoxpesvZVEc7DrwDj93uDIp0e4TrH vHIA== X-Gm-Message-State: ALoCoQnC0uXQPGbWm+hJehAXYQVpuyqDw4OcY73WZ4n/OW647/R2Ioo1feMmnm8W5xyRQkkkxrpm X-Received: by 10.194.79.225 with SMTP id m1mr19395037wjx.8.1438984254213; Fri, 07 Aug 2015 14:50:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.85.99 with HTTP; Fri, 7 Aug 2015 14:50:14 -0700 (PDT) In-Reply-To: References: <201507251453.18237.davemgarrett@gmail.com> <20150804065149.GA27148@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 7 Aug 2015 14:50:14 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b10c9034fbf6e051cbfa1ba Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT & resumption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 21:50:58 -0000 --047d7b10c9034fbf6e051cbfa1ba Content-Type: text/plain; charset=UTF-8 I've updated the PR based on feedback from Dave, Ilari, and Martin. https://github.com/tlswg/tls13-spec/pull/211 I'll merge this PR on 8/11 unless there are serious objections. As usual please send minor changes as github comments and/or PRs. -Ekr On Tue, Aug 4, 2015 at 5:40 AM, Eric Rescorla wrote: > > > On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > >> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: >> > >> > >> > We agreed on how to do this in Prague. The sticking point was >> establishing >> > the cipher suite. I have WIP text on my machine for both of these which >> I >> > will be >> > sending early next week, once I get enough sleep to be able to clean it >> up, >> > so I'd ask people to sit tight till then. >> > >> >> Okay, now the PR (#211) seems to be up, let's review > > > Oops. It wasn't supposed to be done. I meant to make it a PR against my > own branch so that I could get early comments from MT, but obviously that > didn't work out. Regardless, thanks for your comments. > > > - Lacks client-driven client authentication[1]. All client auth is server >> driven, which I think isn't very useful in real world (there are all >> sorts of bad hacks[2] trying to work around lack of client-driven auth). >> > > This is just extending existing practice for 1-RTT handshakes. > > I tend to agree with you that it would be good to change that, but I > didn't want > to do that in this PR, because it would be a big semantic change in TLS. > I suggest you start a new thread on this topic, or perhaps add it to > Andrei's > client auth thread? > > > - EncryptedExtensions looks to be mandatory in some exchanges, optional >> in others. I agree it should be mandatory in all (issue #213). >> > > Me too. That's just editing error. > > > >> - "The client's cryptographic determining parameters match the parameters >> that the server has negotiated based on the rest of the ClientHello." >> ... Does that mean the client has to guess what ciphersuite the server >> will choose (more than pure-PSK vs. GDHE, which is unvaoidable with >> just one encrypted block)? >> > > The client knows what the server selected based on his previous offer and > the server's configuration (which by hypothesis is still extant) so the > server > should choose the same value again. > > >> - Am I reading the syntax wrong, or does the extensions field in server >> configuration only allow exactly one extension (shouldn't it be zero >> or more)? >> > > Yes. good catch. > > > Also, regarding issue #212, unless the Certificate is handled specially, >> it would mean that the signature does not cover certificate. And not >> signing the certificate (esp. the public key within) causes problems >> in some exotic cases (I don't know if any of those cases pop up in TLS >> 1.3). >> > > This seems like a good argument. > > > >> I think it would simplify the security analysis a bit if CertificateVerify >> was always immediately before Finished and covered everything before that >> point. >> > > Isn't this always the case presently? Are you just thinking we should say > it's > a rule? > > -Ekr > > --047d7b10c9034fbf6e051cbfa1ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've updated the PR based on feedback from Dave, Ilari= , and Martin.


I'll merge this PR on 8/11 unless there are serious o= bjections. As usual
please send minor changes as github comments = and/or PRs.

-Ekr


On Tue, Aug 4, 2015 at 5= :40 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Aug 3, 2015 at 11:51 PM, Ilari L= iusvaara <ilari.liusvaara@elisanet.fi> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Sat, Jul 25, 2015 at 09:07:49PM +020= 0, Eric Rescorla wrote:
>
>
> We agreed on how to do this in Prague. The sticking point was establis= hing
> the cipher suite. I have WIP text on my machine for both of these whic= h I
> will be
> sending early next week, once I get enough sleep to be able to clean i= t up,
> so I'd ask people to sit tight till then.
>

Okay, now the PR (#211) seems to be up, let's review

Oops. It wasn't supposed to be done. I mean= t to make it a PR against my
own branch so that I could get early= comments from MT, but obviously that
didn't work out. Regard= less, thanks for your comments.

<= br>
- Lacks client-driven client authentication[1]. All client auth is server =C2=A0 driven, which I think isn't very useful in real world (there are= all
=C2=A0 sorts of bad hacks[2] trying to work around lack of client-driven au= th).

This is just extending exis= ting practice for 1-RTT handshakes.

I tend to agre= e with you that it would be good to change that, but I didn't want
to do that in this PR, because it would be a big semantic change in T= LS.
I suggest you start a new thread on this topic, or perhaps ad= d it to Andrei's
client auth thread?


- EncryptedExten= sions looks to be mandatory in some exchanges, optional
=C2=A0 in others. I agree it should be mandatory in all (issue #213).

Me too. That's just editing error= .

=C2=A0
- "The client's cryptographic determining parameters match the par= ameters
=C2=A0 that the server has negotiated based on the rest of the ClientHello.= "
=C2=A0 ... Does that mean the client has to guess what ciphersuite the serv= er
=C2=A0 will choose (more than pure-PSK vs. GDHE, which is unvaoidable with<= br> =C2=A0 just one encrypted block)?

The client knows what the server selected based on his previous offer and=
the server's configuration (which by hypothesis is still ext= ant) so the server
should choose the same value again.=C2=A0


- Am I reading the syntax wrong, or does the extensions field in server
=C2=A0 configuration only allow exactly one extension (shouldn't it be = zero
=C2=A0 or more)?

Yes. good catch= .


Also, regarding issue #212, unless the Certificate is handled specially, it would mean that the signature does not cover certificate. And not
signing the certificate (esp. the public key within) causes problems
in some exotic cases (I don't know if any of those cases pop up in TLS<= br> 1.3).

This seems like a good arg= ument.

=C2=A0
I think it would simplify the security analysis a bit if CertificateVerify<= br> was always immediately before Finished and covered everything before that point.

Isn't this always the= case presently? Are you just thinking we should say it's
a r= ule?

-Ekr


--047d7b10c9034fbf6e051cbfa1ba-- From nobody Fri Aug 7 22:42:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434FD1ACD97 for ; Fri, 7 Aug 2015 22:42:38 -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 xYcZvu55L8Nq for ; Fri, 7 Aug 2015 22:42:36 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6351ACD90 for ; Fri, 7 Aug 2015 22:42:34 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 9F6B99005F; Sat, 8 Aug 2015 08:42:32 +0300 (EEST) Date: Sat, 8 Aug 2015 08:42:32 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150808054232.GA13285@LK-Perkele-VII> References: <201507251453.18237.davemgarrett@gmail.com> <20150804065149.GA27148@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: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT & 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: Sat, 08 Aug 2015 05:42:38 -0000 On Fri, Aug 07, 2015 at 02:50:14PM -0700, Eric Rescorla wrote: > I've updated the PR based on feedback from Dave, Ilari, and Martin. > > https://github.com/tlswg/tls13-spec/pull/211 > > I'll merge this PR on 8/11 unless there are serious objections. As usual > please send minor changes as github comments and/or PRs. Few small comments (I leave larger stuff out): 1) "If indicate the same parameters as the server indicated in that connection." I can't parse this. 2) "Send the same cryptographic determining parameters (Section {{cryptographic-determining-parameters}}) with the previous connection" What if client is resuming connection for the first time and is keying 0-RTT accordingly? I presume that the ciphersuite used for 0-RTT is then the ciphersuite from session being resumed but key exchange changed to PSK (e.g. TLS_ECDHE_FOO_WITH_BAR -> TLS_PSK_WITH_BAR), as this is the ciphersuite resumed session would use. (Where is the rule on what ciphersuite resumed session uses stated? I thought the ciphersuite always needed to have the same symmetric part?) -Ilari From nobody Sat Aug 8 02:03:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9330D1B2A2F for ; Sat, 8 Aug 2015 02:03:57 -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 76ptIVe-etuF for ; Sat, 8 Aug 2015 02:03:55 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E691ACD84 for ; Sat, 8 Aug 2015 02:03:54 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 0C0F518879A; Sat, 8 Aug 2015 12:03:51 +0300 (EEST) Date: Sat, 8 Aug 2015 12:03:51 +0300 From: Ilari Liusvaara To: Andrei Popov Message-ID: <20150808090351.GA14947@LK-Perkele-VII> References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@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: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 09:03:57 -0000 On Tue, Aug 04, 2015 at 12:37:47AM +0000, Andrei Popov wrote: > > Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. > > There one likely "preconfigures" client certificates if needed. > The proposed client authentication mechanism specifically addresses > the case where the client does not have one "preconfigured" cert. What sort of usecase you have in mind for this? I can't come up with single one that I don't think is a hack at best. Note: It is very easy to misuse capability like this (even if it is restricted to work only once per connection) to create nasty security issues (one example being trying to use this for HTTP/2 in browser environment). > > - TLS-level client certificate auth on client request on connect (this > > currently can't be cleanly done, sometimes one even sees that "renego > > immediately to provoke CR" hack). > With the proposed change, there will be no need to renegotiate in > order to authenticate the client. Where's the capability for client to unilaterially decide to send a certificate without valid configuration? The 0-RTT certificate authentication requires a valid configuration. E.g. one way to implement that would be certificate_request_request extension, which would request server to send a CertificateRequest. Tho with the changes to always sign the key exchange, using 0-RTT client certs doesn't work unless the server requested certificates back then. > > - Application-level client auth (via CB capability of TLS). > The proposed mechanism does not preclude this option. That was given as second of two entries in list of kinds of authentication I think are useful (and precluding it would mean removing TLS-Unique and TLS-Extractor, which is something that I really don't see happening). -Ilari From nobody Mon Aug 10 10:10:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469451B3A19 for ; Mon, 10 Aug 2015 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0G2N6e3IRaO2 for ; Mon, 10 Aug 2015 10:10:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B92E1B3A17 for ; Mon, 10 Aug 2015 10:10:40 -0700 (PDT) Received: from BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) by BLUPR03MB215.namprd03.prod.outlook.com (10.255.212.154) with Microsoft SMTP Server (TLS) id 15.1.231.11; Mon, 10 Aug 2015 17:10:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aGHcTvctw3zAQFkHXeP/KQPEZTobK7wSiIYFqVD2O3k=; b=RnJ/I3YKtVbWgBaH/Sr5y3PLtPEcyYWymGqKJoT0s1uab+lzYfmhTJQ2FgMwl0G68Ii21UZW1lFKR/VqPPgirg4ZoaYQuoYAQ9/tUX8JbDk7q1qmWIyAHJ6mLWTA4Zmu2ehboK909o+tj9lTDpkLQlIXtMAMmKlTjS+fSzYTP80= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 17:10:38 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 17:10:38 +0000 From: Andrei Popov To: Ilari Liusvaara Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQgAbZS4CAA6ghwA== Date: Mon, 10 Aug 2015 17:10:38 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> In-Reply-To: <20150808090351.GA14947@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:WrzIG0XeiD3MKp9bdeWGMiCb03dFVSckwANpqLubnRsYXRJ/0WA7iR7tdWUkvOpZt11rDMcPixjdb4OHzn6Ueq/QP/h/+lTTl6SnmN9G1StFrXagSCjAuknsUUJa5Im/WdAQr7lNuA0cQDV45zUklA==; 24:25jVUQ3o3PgzbC8oqG3SguZBFkOz/BAmSczsQGD1d9d4AFYNN5msKL0jGEU3WC+sJitQH9HRQgvpUDhPXPjiqHQpyWJ7GkHCT9F6Rmhuq9s=; 20:WHyI9NXFjl/AcKPTVKb3cHQPOWDRe7ofK+eBtkQ2E365Mdseyga51sbVRE3ma/V/OZi2ne397TVaozBZBLyY8w== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB215; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(24454002)(199003)(19580395003)(10400500002)(68736005)(5001830100001)(97736004)(5002640100001)(5001860100001)(54356999)(74316001)(40100003)(189998001)(5005710100001)(8990500004)(76176999)(10290500002)(110136002)(81156007)(122556002)(101416001)(4001540100001)(62966003)(77156002)(99286002)(2950100001)(105586002)(76576001)(92566002)(50986999)(64706001)(5001920100001)(5001960100002)(46102003)(2656002)(87936001)(19580405001)(5003600100002)(77096005)(102836002)(86612001)(106356001)(86362001)(106116001)(33656002)(10090500001)(2900100001)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 17:10:38.8679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB215; 2:9qvr8LuGYSUvEqXrOUI53FvxBL9hmc9pYV7AIo7AjSPLbZdZtGrEHq6bgbdz34f5RJqsXQbx6llKn82H+vXpe2FQfjYJgoBHtTwIBvUQOxb230ZorYW7tTWjQNOFM5jLf6TeM7phKbYoXSzOY+X8nw8nlGayXzyirDN4FxUnHz0=; 3:RrpN208Bi/dh4acx++LLXKJdDRQ+9u6tvNRRXCffoP/NJZzHakAIBqarlTH2WHlPQoYtU+bhwAlqDH4x10rwpaz/vaMI9lFdXDpcPtwcaoamKGHgwvqv5/HgB9jPrRaOyTk4ySOrh2SAbiGSo5rs+Q==; 25:zi/cBDZ9CJe30o/NeHNYUHpNW1PtJ3EwBFPLGt9hBNyjJGV//Nm9A/qr2/Meq+TPnwZ87rOgpbSrDUL7sk/xrmR2RJB8IKlnCjrjd/JhqCRr4XZTKu/HI/7W8rtZdHybtaaEup2udjOXKZrrPtun9ve+TeWSAahf1MknCEPljLHiZlg+H2ZKKkhUyOVa343IZpeQLaZU8cYYwSSx92SCc64uOvwntULqcfS7YnnJvfSI0kRn2mk4DbmTNLTlNJm2Bp/JNC+ltC9YbbsfiXfnmw==; 23:FOfSyjMMypaTPCEiZS8swooq8YD5PJnGpD8gujwrie63+qaWoy6k1khtaMkPf//u6pBLu6TzS4CkfiQsoJM6zt9U9edt/XkidG9buAE5yhdAbLAHWaL0latS78P3IbpZTm4hOK4dwLAZDyxMNtTzAOwpB3NjiizJIP8ZguZjXAQketYcDpPdZV60xcCSiUCd X-OriginatorOrg: microsoft.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:10:43 -0000 SGkgSWxhcmksDQoNCj4gV2hhdCBzb3J0IG9mIHVzZWNhc2UgeW91IGhhdmUgaW4gbWluZCBmb3Ig dGhpcz8NClRoaXMgaXMgdG8gc3VwcG9ydCBhIGZhaXJseSBjb21tb24gd2Vic2l0ZSBkZXNpZ24g d2hlcmUgdGhlIGxhbmRpbmcgcGFnZSBkb2VzIG5vdCByZXF1aXJlIGNsaWVudCBhdXRoLCBidXQg c3Vic2VxdWVudCByZXF1ZXN0IHRvIGEgcHJvdGVjdGVkIHJlc291cmNlIHRyaWdnZXJzIGNsaWVu dCBhdXRoZW50aWNhdGlvbiB3aXRoaW4gYW4gZXhpc3RpbmcgVExTIGNvbm5lY3Rpb24uDQpJbiBU TFM8PTEuMiwgdGhpcyB3YXMgYWNjb21wbGlzaGVkIHZpYSByZW5lZ290aWF0aW9uLiBJbiBUTFMx LjMsIHRoZXJlIGlzIG5vIHJlbmVnb3RpYXRpb24sIHNvIHdlIG5lZWQgYW4gYWx0ZXJuYXRpdmUg c29sdXRpb24gaWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoZXNlIGV4aXN0aW5nIHNpdGVzIG92ZXIg VExTMS4zLg0KDQo+IFdoZXJlJ3MgdGhlIGNhcGFiaWxpdHkgZm9yIGNsaWVudCB0byB1bmlsYXRl cmlhbGx5IGRlY2lkZSB0byBzZW5kIGEgY2VydGlmaWNhdGUgd2l0aG91dCB2YWxpZCBjb25maWd1 cmF0aW9uPw0KTXkgcHVsbCByZXF1ZXN0IGlzIGRlc2lnbmVkIHRvIGFkZHJlc3MgY2xpZW50IGF1 dGggaW4gdGhlIG1pZGRsZSBvZiBhIFRMUyBjb25uZWN0aW9uLCBhZnRlciB0aGUgaGFuZHNoYWtl IGlzIGNvbXBsZXRlLCB3aGljaCBpcyBhbiBleGlzdGluZyBzY2VuYXJpbyB0aGF0IHdhcyBicm9r ZW4gYnkgdGhlIHJlbW92YWwgb2YgcmVuZWdvdGlhdGlvbiBpbiBUTFMgMS4zLg0KSWYgZW5vdWdo IHBlb3BsZSB3YW50IHRoZSBjYXBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIHZvbHVudGVlciBh IGNlcnRpZmljYXRlLCBJIGRvbid0IG1pbmQgYWRkaW5nIHRoaXMgdG8gbXkgcHVsbCByZXF1ZXN0 LiBSaWdodCBub3cgSSBkb24ndCBoYXZlIGEgc2Vuc2Ugb2YgaG93IHVzZWZ1bCBXRyBwYXJ0aWNp cGFudHMgdGhpbmsgdGhpcyB3b3VsZCBiZS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElsYXJpIExpdXN2YWFyYSBbbWFpbHRvOmlsYXJp LmxpdXN2YWFyYUBlbGlzYW5ldC5maV0gDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDgsIDIwMTUg MjowNCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpD YzogRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz47IHRsc0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtUTFNdIENvbW1lbnRhcnkgb24gdGhlIGNsaWVudCBhdXRoZW50aWNhdGlv biBwcmVzZW50YXRpb24gc2xpZGVzDQoNCk9uIFR1ZSwgQXVnIDA0LCAyMDE1IGF0IDEyOjM3OjQ3 QU0gKzAwMDAsIEFuZHJlaSBQb3BvdiB3cm90ZToNCj4gPiBXZWxsLCBUTFMgaXMgYWxzbyB1c2Vk IGZvciBub24tYnJvd3NlciBIVFRQUyBhbmQgc3R1ZmYgb3RoZXIgdGhhbiBIVFRQUy4NCj4gPiBU aGVyZSBvbmUgbGlrZWx5ICJwcmVjb25maWd1cmVzIiBjbGllbnQgY2VydGlmaWNhdGVzIGlmIG5l ZWRlZC4NCj4gVGhlIHByb3Bvc2VkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gc3Bl Y2lmaWNhbGx5IGFkZHJlc3NlcyANCj4gdGhlIGNhc2Ugd2hlcmUgdGhlIGNsaWVudCBkb2VzIG5v dCBoYXZlIG9uZSAicHJlY29uZmlndXJlZCIgY2VydC4NCg0KV2hhdCBzb3J0IG9mIHVzZWNhc2Ug eW91IGhhdmUgaW4gbWluZCBmb3IgdGhpcz8gSSBjYW4ndCBjb21lIHVwIHdpdGggc2luZ2xlIG9u ZSB0aGF0IEkgZG9uJ3QgdGhpbmsgaXMgYSBoYWNrIGF0IGJlc3QuDQoNCk5vdGU6IEl0IGlzIHZl cnkgZWFzeSB0byBtaXN1c2UgY2FwYWJpbGl0eSBsaWtlIHRoaXMgKGV2ZW4gaWYgaXQgaXMgcmVz dHJpY3RlZCB0byB3b3JrIG9ubHkgb25jZSBwZXIgY29ubmVjdGlvbikgdG8gY3JlYXRlIG5hc3R5 IHNlY3VyaXR5IGlzc3VlcyAob25lIGV4YW1wbGUgYmVpbmcgdHJ5aW5nIHRvIHVzZSB0aGlzIGZv ciBIVFRQLzIgaW4gYnJvd3NlciBlbnZpcm9ubWVudCkuDQoNCj4gPiAtIFRMUy1sZXZlbCBjbGll bnQgY2VydGlmaWNhdGUgYXV0aCBvbiBjbGllbnQgcmVxdWVzdCBvbiBjb25uZWN0IA0KPiA+ICh0 aGlzICBjdXJyZW50bHkgY2FuJ3QgYmUgY2xlYW5seSBkb25lLCBzb21ldGltZXMgb25lIGV2ZW4g c2VlcyB0aGF0IA0KPiA+ICJyZW5lZ28gIGltbWVkaWF0ZWx5IHRvIHByb3Zva2UgQ1IiIGhhY2sp Lg0KPiBXaXRoIHRoZSBwcm9wb3NlZCBjaGFuZ2UsIHRoZXJlIHdpbGwgYmUgbm8gbmVlZCB0byBy ZW5lZ290aWF0ZSBpbiANCj4gb3JkZXIgdG8gYXV0aGVudGljYXRlIHRoZSBjbGllbnQuDQoNCldo ZXJlJ3MgdGhlIGNhcGFiaWxpdHkgZm9yIGNsaWVudCB0byB1bmlsYXRlcmlhbGx5IGRlY2lkZSB0 byBzZW5kIGEgY2VydGlmaWNhdGUgd2l0aG91dCB2YWxpZCBjb25maWd1cmF0aW9uPyBUaGUgMC1S VFQgY2VydGlmaWNhdGUgYXV0aGVudGljYXRpb24gcmVxdWlyZXMgYSB2YWxpZCBjb25maWd1cmF0 aW9uLg0KDQpFLmcuIG9uZSB3YXkgdG8gaW1wbGVtZW50IHRoYXQgd291bGQgYmUgY2VydGlmaWNh dGVfcmVxdWVzdF9yZXF1ZXN0IGV4dGVuc2lvbiwgd2hpY2ggd291bGQgcmVxdWVzdCBzZXJ2ZXIg dG8gc2VuZCBhIENlcnRpZmljYXRlUmVxdWVzdC4NCg0KVGhvIHdpdGggdGhlIGNoYW5nZXMgdG8g YWx3YXlzIHNpZ24gdGhlIGtleSBleGNoYW5nZSwgdXNpbmcgMC1SVFQgY2xpZW50IGNlcnRzIGRv ZXNuJ3Qgd29yayB1bmxlc3MgdGhlIHNlcnZlciByZXF1ZXN0ZWQgY2VydGlmaWNhdGVzIGJhY2sg dGhlbi4NCg0KPiAgPiAtIEFwcGxpY2F0aW9uLWxldmVsIGNsaWVudCBhdXRoICh2aWEgQ0IgY2Fw YWJpbGl0eSBvZiBUTFMpLg0KPiBUaGUgcHJvcG9zZWQgbWVjaGFuaXNtIGRvZXMgbm90IHByZWNs dWRlIHRoaXMgb3B0aW9uLg0KDQpUaGF0IHdhcyBnaXZlbiBhcyBzZWNvbmQgb2YgdHdvIGVudHJp ZXMgaW4gbGlzdCBvZiBraW5kcyBvZiBhdXRoZW50aWNhdGlvbiBJIHRoaW5rIGFyZSB1c2VmdWwg KGFuZCBwcmVjbHVkaW5nIGl0IHdvdWxkIG1lYW4gcmVtb3ZpbmcgVExTLVVuaXF1ZSBhbmQgVExT LUV4dHJhY3Rvciwgd2hpY2ggaXMgc29tZXRoaW5nIHRoYXQgSSByZWFsbHkgZG9uJ3Qgc2VlIGhh cHBlbmluZykuDQoNCg0KDQoNCi1JbGFyaQ0K From nobody Mon Aug 10 10:28:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4661B3A72 for ; Mon, 10 Aug 2015 10:28: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 QR3XwGLm45Wm for ; Mon, 10 Aug 2015 10:28:22 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124431B3A75 for ; Mon, 10 Aug 2015 10:28:21 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so160564112wib.0 for ; Mon, 10 Aug 2015 10:28:18 -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=o9+FVPhtTCRFN/ucBCjuFx35JgheYGyXvMahNwUhyrQ=; b=H5hAr7Ghmt6P14CTFe5gmfQPnRH6hYWVJfrPR+i8Q9r1kNe3Hmrv5oahQg+9dqNpIF zlttGZ7N1dd/68SfxwYt/5nnxy2He6WWAn8OwzcGyB3HcjFgy1V0lFuKBbloLJ3pD3or WRl9FyK4LiecyIjRTSDfKqo/GFjNXjFybl1oafhAERtVCM+cfhzzlhWKxdAB+TgcpTm3 DkDV2FHbZ/nRduytIT+ON6hM4/vwtrFVNpf2yYRNhCwvPiH48vams953TpN5hHT5z9Xa /1dnL6t7DjmCRp5ekrJ9AczmU1GE1XgswzOoCy9oG060YCCL7+SawxscklOq0gdQayY+ fxYg== X-Received: by 10.180.108.210 with SMTP id hm18mr25683754wib.45.1439227698848; Mon, 10 Aug 2015 10:28:18 -0700 (PDT) Received: from [192.168.1.50] (antoniah.static.otenet.gr. [79.129.103.151]) by smtp.gmail.com with ESMTPSA id b13sm14759472wic.15.2015.08.10.10.28.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Aug 2015 10:28:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Mon, 10 Aug 2015 20:28:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> To: Andrei Popov X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:28:23 -0000 > On Aug 10, 2015, at 8:10 PM, Andrei Popov = wrote: >=20 > Hi Ilari, >=20 >> What sort of usecase you have in mind for this? > This is to support a fairly common website design where the landing = page does not require client auth, but subsequent request to a protected = resource triggers client authentication within an existing TLS = connection. > In TLS<=3D1.2, this was accomplished via renegotiation. In TLS1.3, = there is no renegotiation, so we need an alternative solution if we want = to support these existing sites over TLS1.3. I=E2=80=99d like to point out that I am very interested in this use = case, but I=E2=80=99m not sure that this is the solution. Such sites were first broken by HTTP/2 which forbade renegotiation. Then = they were broken again by TLS 1.3 that does not include renegotiation. Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS = 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.=20 Assuming that HTTP/2 is the HTTP of the future (meaning that relegating = these sites to HTTP/1 is a temporary thing), I don=E2=80=99t think that = this new mechanism fixes the issue with renegotiation that caused = httpbis to reject its usage. We still get a race condition where several = requests might be answered before, after or during authentication = depending on the timing of the TLS handshake message vs the HTTP = messages. It would be useless IMO to create an alternate renegotiation in TLS only = for it to not be used in HTTP/2. Yoav From nobody Mon Aug 10 12:05:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077951B3CBD for ; Mon, 10 Aug 2015 12:05: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 lG2dzoN-soWO for ; Mon, 10 Aug 2015 12:05:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDBB1B3CC3 for ; Mon, 10 Aug 2015 12:05:16 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 19:04:57 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 19:04:57 +0000 From: Andrei Popov To: Yoav Nir Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQgAbZS4CAA6ghwIAACXUAgAAYGbA= Date: Mon, 10 Aug 2015 19:04:57 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> In-Reply-To: <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:X00fJBucSA88tmTBPQRLt/FUjnbfP8CArNp2qU949vSYbsDFqjYkSKv4wdndlxA0tpRM7LMowJiHvC6rrjTcjjr95k//JP78ue9j3+SzBDQ/QR2msZARl5kcKmdv87xJXWShIQvXzKQ2k/+JbljIUA==; 24:uqnD4sk5XRMxj8CSCQlKjjfZoCNG5/V52FkKZnN5zFDCKn0g7ibHL/or+mkLqXNRioDlTWMUxJXyvlM88rjBI+5USKmhi/OS3mBxSbEadt0=; 20:ZSAG5RNA+CsWpVCIzYzC8CT+7aLKG15cUnhW2pADB20wtLI5h35TFYnHEu2wodLUfQwkxC9FAjsa5YZl4rb9Ag== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(24454002)(199003)(377454003)(46102003)(2656002)(76576001)(2950100001)(33656002)(4001540100001)(81156007)(189998001)(19580405001)(5005710100001)(5001830100001)(64706001)(68736005)(122556002)(40100003)(62966003)(97736004)(5001860100001)(102836002)(110136002)(5002640100001)(77156002)(5001960100002)(10090500001)(77096005)(54356999)(5003600100002)(106116001)(106356001)(87936001)(19580395003)(99286002)(105586002)(86362001)(93886004)(50986999)(2900100001)(10400500002)(92566002)(74316001)(86612001)(76176999)(10290500002)(101416001)(8990500004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 19:04:57.3401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:05:28 -0000 PiBJZGVhbGx5IGEgc29sdXRpb24gd291bGQgd29yayB3aXRoIEhUVFAvMSBvdmVyIFRMUyAxLjMs IEhUVFAvMiBvdmVyIFRMUyAxLjMsIEhUVFAvMiBvdmVyIFRMUyAxLjIsIGFuZCBmb3IgY29tcGxl dGVuZXNzIEhUVFAvMSBvdmVyIFRMUyAxLjIuDQpDb3JyZWN0LCBhbnl0aGluZyBsZXNzIHRoYW4g dGhpcyB3aWxsIGNyZWF0ZSBkZXBsb3ltZW50IHByb2JsZW1zLg0KDQo+IEnigJlkIGxpa2UgdG8g cG9pbnQgb3V0IHRoYXQgSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhpcyB1c2UgY2FzZSwgYnV0 IEnigJltIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyB0aGUgc29sdXRpb24uDQpJJ20gb3BlbiB0byBh bHRlcm5hdGl2ZXMgdGhhdCBmaXggdGhlIGJyb2tlbiB1c2UgY2FzZS4gDQoNCj4gV2Ugc3RpbGwg Z2V0IGEgcmFjZSBjb25kaXRpb24gd2hlcmUgc2V2ZXJhbCByZXF1ZXN0cyBtaWdodCBiZSBhbnN3 ZXJlZCBiZWZvcmUsIGFmdGVyIG9yIGR1cmluZyBhdXRoZW50aWNhdGlvbiBkZXBlbmRpbmcgb24g dGhlIHRpbWluZyBvZiB0aGUgVExTIGhhbmRzaGFrZSBtZXNzYWdlIHZzIHRoZSBIVFRQIG1lc3Nh Z2VzLg0KVGhlIGlkZWEgaXMgdGhhdCBiZWZvcmUgYW5zd2VyaW5nIGEgcmVxdWVzdCB0aGF0IHJl cXVpcmVzIGNsaWVudCBhdXRoLCB0aGUgc2VydmVyIGNoZWNrcyBpZiBhIGNsaWVudCBjcmVkIGlz IGF2YWlsYWJsZS4gSWYgdGhlcmUgaXMgbm8gc3VpdGFibGUgY2xpZW50IGNyZWQgYXZhaWxhYmxl LCB0aGUgcmVxdWVzdCBpcyBibG9ja2VkIHVudGlsIHRoZSBjbGllbnQgYXV0aGVudGljYXRlcy4g VGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBoYXZlIHRvIGJsb2NrIG90aGVyIHJlcXVlc3RzIHRo YXQgZG8gbm90IHJlcXVpcmUgY2xpZW50IGF1dGguDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBZb2F2IE5pciBbbWFpbHRvOnluaXIuaWV0 ZkBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMTUgMTA6MjggQU0NClRv OiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IElsYXJpIExp dXN2YWFyYSA8aWxhcmkubGl1c3ZhYXJhQGVsaXNhbmV0LmZpPjsgdGxzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW1RMU10gQ29tbWVudGFyeSBvbiB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHBy ZXNlbnRhdGlvbiBzbGlkZXMNCg0KDQo+IE9uIEF1ZyAxMCwgMjAxNSwgYXQgODoxMCBQTSwgQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBJ bGFyaSwNCj4gDQo+PiBXaGF0IHNvcnQgb2YgdXNlY2FzZSB5b3UgaGF2ZSBpbiBtaW5kIGZvciB0 aGlzPw0KPiBUaGlzIGlzIHRvIHN1cHBvcnQgYSBmYWlybHkgY29tbW9uIHdlYnNpdGUgZGVzaWdu IHdoZXJlIHRoZSBsYW5kaW5nIHBhZ2UgZG9lcyBub3QgcmVxdWlyZSBjbGllbnQgYXV0aCwgYnV0 IHN1YnNlcXVlbnQgcmVxdWVzdCB0byBhIHByb3RlY3RlZCByZXNvdXJjZSB0cmlnZ2VycyBjbGll bnQgYXV0aGVudGljYXRpb24gd2l0aGluIGFuIGV4aXN0aW5nIFRMUyBjb25uZWN0aW9uLg0KPiBJ biBUTFM8PTEuMiwgdGhpcyB3YXMgYWNjb21wbGlzaGVkIHZpYSByZW5lZ290aWF0aW9uLiBJbiBU TFMxLjMsIHRoZXJlIGlzIG5vIHJlbmVnb3RpYXRpb24sIHNvIHdlIG5lZWQgYW4gYWx0ZXJuYXRp dmUgc29sdXRpb24gaWYgd2Ugd2FudCB0byBzdXBwb3J0IHRoZXNlIGV4aXN0aW5nIHNpdGVzIG92 ZXIgVExTMS4zLg0KDQpJ4oCZZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IEkgYW0gdmVyeSBpbnRl cmVzdGVkIGluIHRoaXMgdXNlIGNhc2UsIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMg dGhlIHNvbHV0aW9uLg0KDQpTdWNoIHNpdGVzIHdlcmUgZmlyc3QgYnJva2VuIGJ5IEhUVFAvMiB3 aGljaCBmb3JiYWRlIHJlbmVnb3RpYXRpb24uIFRoZW4gdGhleSB3ZXJlIGJyb2tlbiBhZ2FpbiBi eSBUTFMgMS4zIHRoYXQgZG9lcyBub3QgaW5jbHVkZSByZW5lZ290aWF0aW9uLg0KDQpJZGVhbGx5 IGEgc29sdXRpb24gd291bGQgd29yayB3aXRoIEhUVFAvMSBvdmVyIFRMUyAxLjMsIEhUVFAvMiBv dmVyIFRMUyAxLjMsIEhUVFAvMiBvdmVyIFRMUyAxLjIsIGFuZCBmb3IgY29tcGxldGVuZXNzIEhU VFAvMSBvdmVyIFRMUyAxLjIuIA0KDQpBc3N1bWluZyB0aGF0IEhUVFAvMiBpcyB0aGUgSFRUUCBv ZiB0aGUgZnV0dXJlIChtZWFuaW5nIHRoYXQgcmVsZWdhdGluZyB0aGVzZSBzaXRlcyB0byBIVFRQ LzEgaXMgYSB0ZW1wb3JhcnkgdGhpbmcpLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGlzIG5ldyBt ZWNoYW5pc20gZml4ZXMgdGhlIGlzc3VlIHdpdGggcmVuZWdvdGlhdGlvbiB0aGF0IGNhdXNlZCBo dHRwYmlzIHRvIHJlamVjdCBpdHMgdXNhZ2UuIFdlIHN0aWxsIGdldCBhIHJhY2UgY29uZGl0aW9u IHdoZXJlIHNldmVyYWwgcmVxdWVzdHMgbWlnaHQgYmUgYW5zd2VyZWQgYmVmb3JlLCBhZnRlciBv ciBkdXJpbmcgYXV0aGVudGljYXRpb24gZGVwZW5kaW5nIG9uIHRoZSB0aW1pbmcgb2YgdGhlIFRM UyBoYW5kc2hha2UgbWVzc2FnZSB2cyB0aGUgSFRUUCBtZXNzYWdlcy4NCg0KSXQgd291bGQgYmUg dXNlbGVzcyBJTU8gdG8gY3JlYXRlIGFuIGFsdGVybmF0ZSByZW5lZ290aWF0aW9uIGluIFRMUyBv bmx5IGZvciBpdCB0byBub3QgYmUgdXNlZCBpbiBIVFRQLzIuDQoNCllvYXYNCg0K From nobody Mon Aug 10 12:34:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14A81A0366 for ; Mon, 10 Aug 2015 12:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 qHxAP-Xth6mY for ; Mon, 10 Aug 2015 12:34:04 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749E21A028A for ; Mon, 10 Aug 2015 12:34:04 -0700 (PDT) Received: by iodd187 with SMTP id d187so180112182iod.2 for ; Mon, 10 Aug 2015 12:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=2FUCNjmjE7q5HTcABhowwMAYwWoMJjrmqPxfx3TvzF4=; b=FOqVx1krBukjLIT77OAdyiRDhbcs91O52yrINXsdl1zlwEkNSyJMMNkzeF0zdPAFvO XO0023jw7Xy+0ehiaiDnYSF/kWsesjh/qQbxsaHNmLBsMdC6R+p4CS5gwKa0p3AsPAOk T6PieaYm/f08gR5AffSdkuzxEGMPsekHI2T0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=2FUCNjmjE7q5HTcABhowwMAYwWoMJjrmqPxfx3TvzF4=; b=CdOrubAo+QXt6P5CHqGpLhQue2n8dM5CH4U4lroZwMa7OElCYs4Ab5r2HcYPCUza/G zgRpOaPBLwukgExWvja7hKSM9rJNHGSy+iTzpikSJwOiHYnSA6pyxJQR158Qn4QLBXNS rUPXjnIa3UoDRj0/WKQw6NNw9NgBDyOd7Z5ZiIxu2O30fw+YMbsM3cam/XoVpLs/zntu I5G/PlO0FXzpp7Shxl4C6MR5BEe77D5d2XkD7IgR7AE2yUoadyuOQHZDkRiFAcZcTbeB WaXmzyaZlWTFtryzwy2tHy64BdoBonmCfdRgrExcHlKAua2+ZgVILTw7//035hRQ3Kkf TYZQ== X-Gm-Message-State: ALoCoQlrJF0KT5LsWql2lm+A6SOvgvIymMw3+XGQxqN5DVL3MecXq8ia7XPJF1a+ZAy1nCbqkTYs X-Received: by 10.107.9.142 with SMTP id 14mr21912869ioj.142.1439235243500; Mon, 10 Aug 2015 12:34:03 -0700 (PDT) MIME-Version: 1.0 References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> In-Reply-To: From: David Benjamin Date: Mon, 10 Aug 2015 19:33:53 +0000 Message-ID: To: Andrei Popov , Yoav Nir Content-Type: multipart/alternative; boundary=001a113f8cf6700dd9051cfa11b9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:34:06 -0000 --001a113f8cf6700dd9051cfa11b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov wrote: > > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS > 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. > But this proposal is only suitable for HTTP/1 over TLS 1.3 anyway. It can't be used for HTTP/2 over TLS 1.3 as a client has no way to correlate transport-level certificate requests with the HTTP request. This is part of why renego was rightly banned for HTTP/2. Otherwise you need to show a contextless prompt on a client, and that's really bad UI. Chrome tries very hard to avoid those. I would grudgingly consider it acceptable for HTTP/1 over TLS 1.3, but only because it's no worse than the renego one and we're stuck with that legacy mistake right now. If that weren't the case, I wouldn't want it in HTTP/1 either. Changing connection-level state mid-stream underneath a multi-request protocol is very messy, particularly when combined with socket-pooling optimizations. Why not do this using HTTP's own auth framework? Have the client sign something which includes a channel binding, placing it and the certificate chain in an Authorization header. You could even transition to it in TLS 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not negotiated, fall back to the legacy thing. David > > I=E2=80=99d like to point out that I am very interested in this use cas= e, but > I=E2=80=99m not sure that this is the solution. > I'm open to alternatives that fix the broken use case. > > > We still get a race condition where several requests might be answered > before, after or during authentication depending on the timing of the TLS > handshake message vs the HTTP messages. > The idea is that before answering a request that requires client auth, th= e > server checks if a client cred is available. If there is no suitable clie= nt > cred available, the request is blocked until the client authenticates. Th= is > does not necessarily have to block other requests that do not require > client auth. > > Cheers, > > Andrei > > -----Original Message----- > From: Yoav Nir [mailto:ynir.ietf@gmail.com] > Sent: Monday, August 10, 2015 10:28 AM > To: Andrei Popov > Cc: Ilari Liusvaara ; tls@ietf.org > Subject: Re: [TLS] Commentary on the client authentication presentation > slides > > > > On Aug 10, 2015, at 8:10 PM, Andrei Popov > wrote: > > > > Hi Ilari, > > > >> What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing pag= e > does not require client auth, but subsequent request to a protected > resource triggers client authentication within an existing TLS connection= . > > In TLS<=3D1.2, this was accomplished via renegotiation. In TLS1.3, ther= e > is no renegotiation, so we need an alternative solution if we want to > support these existing sites over TLS1.3. > > I=E2=80=99d like to point out that I am very interested in this use case,= but I=E2=80=99m > not sure that this is the solution. > > Such sites were first broken by HTTP/2 which forbade renegotiation. Then > they were broken again by TLS 1.3 that does not include renegotiation. > > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS > 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > > Assuming that HTTP/2 is the HTTP of the future (meaning that relegating > these sites to HTTP/1 is a temporary thing), I don=E2=80=99t think that t= his new > mechanism fixes the issue with renegotiation that caused httpbis to rejec= t > its usage. We still get a race condition where several requests might be > answered before, after or during authentication depending on the timing o= f > the TLS handshake message vs the HTTP messages. > > It would be useless IMO to create an alternate renegotiation in TLS only > for it to not be used in HTTP/2. > > Yoav > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113f8cf6700dd9051cfa11b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 10= , 2015 at 3:05 PM Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> Ideally a solution would work with HTTP/1 over TLS 1.3, = HTTP/2 over TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over = TLS 1.2.
Correct, anything less than this will create deployment problems.

But this proposal is only suitable for HTTP/1 ov= er TLS 1.3 anyway. It can't be used for HTTP/2 over TLS 1.3 as a client= has no way to correlate transport-level certificate requests with the HTTP= request. This is part of why renego was rightly banned for HTTP/2. Otherwi= se you need to show a contextless prompt on a client, and that's really= bad UI. Chrome tries very hard to avoid those.

I = would grudgingly consider it acceptable for HTTP/1 over TLS 1.3, but only b= ecause it's no worse than the renego one and we're stuck with that = legacy mistake right now. If that weren't the case, I wouldn't want= it in HTTP/1 either. Changing connection-level state mid-stream underneath= a multi-request protocol is very messy, particularly when combined with so= cket-pooling optimizations.

Why not do this using = HTTP's own auth framework? Have the client sign something which include= s a channel binding, placing it and the certificate chain in an Authorizati= on header. You could even transition to it in TLS 1.2 deployments, provided= EMS is negotiated. When TLS 1.3 and EMS are not negotiated, fall back to t= he legacy thing.

David
=C2=A0
> I=E2=80=99d like to point out that I am very interested in this use ca= se, but I=E2=80=99m not sure that this is the solution.
I'm open to alternatives that fix the broken use case.

> We still get a race condition where several requests might be answered= before, after or during authentication depending on the timing of the TLS = handshake message vs the HTTP messages.
The idea is that before answering a request that requires client auth, the = server checks if a client cred is available. If there is no suitable client= cred available, the request is blocked until the client authenticates. Thi= s does not necessarily have to block other requests that do not require cli= ent auth.

Cheers,

Andrei

-----Original Message-----
From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent: Monday, August 10, 2015 10:28 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation sli= des


> On Aug 10, 2015, at 8:10 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:
>
> Hi Ilari,
>
>> What sort of usecase you have in mind for this?
> This is to support a fairly common website design where the landing pa= ge does not require client auth, but subsequent request to a protected reso= urce triggers client authentication within an existing TLS connection.
> In TLS<=3D1.2, this was accomplished via renegotiation. In TLS1.3, = there is no renegotiation, so we need an alternative solution if we want to= support these existing sites over TLS1.3.

I=E2=80=99d like to point out that I am very interested in this use case, b= ut I=E2=80=99m not sure that this is the solution.

Such sites were first broken by HTTP/2 which forbade renegotiation. Then th= ey were broken again by TLS 1.3 that does not include renegotiation.

Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS 1.3= , HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.

Assuming that HTTP/2 is the HTTP of the future (meaning that relegating the= se sites to HTTP/1 is a temporary thing), I don=E2=80=99t think that this n= ew mechanism fixes the issue with renegotiation that caused httpbis to reje= ct its usage. We still get a race condition where several requests might be= answered before, after or during authentication depending on the timing of= the TLS handshake message vs the HTTP messages.

It would be useless IMO to create an alternate renegotiation in TLS only fo= r it to not be used in HTTP/2.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113f8cf6700dd9051cfa11b9-- From nobody Mon Aug 10 12:54:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB011A86EB for ; Mon, 10 Aug 2015 12:54: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 ND0mb0DjRXHE for ; Mon, 10 Aug 2015 12:54:07 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDCA1A011B for ; Mon, 10 Aug 2015 12:54:06 -0700 (PDT) Received: by wicja10 with SMTP id ja10so40047419wic.1 for ; Mon, 10 Aug 2015 12:54:05 -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=MbDLnuhFVdYTi7uPhMa0uWtM2YGULLItTXpOejKH048=; b=fZhbNJpt9VT8cmzTxdBM5Pu1S/9GAPQfBxZYqk603kdqIo/uoCljcEDmKCm/5L1K0y IHg8OkdShw1/RojD8dBP6ohE7FXsEQD7fGiu1tXx4I+wA9WtE9eL9xJBOmsgadcA5mKg qqXPIvaxXK83yOKMhA6y0mifTSId8iJq83W1MvyRXAMdg5trtKZbAP+Z+tqX49WDwO+i 2XWJFDL2Z8m8adXQj+VZifdSngcu4xuK7FAEpov/oTOhJUOOMTwFcE5ept4w9GXjdP7w eqdxamIV+++T/IdTWRkeWb0ilToVsbYXdUXZobM6mKfCD1RFx0jxhqI73OxPr1WZ48RE OEaw== X-Received: by 10.194.192.99 with SMTP id hf3mr45984018wjc.78.1439236445274; Mon, 10 Aug 2015 12:54:05 -0700 (PDT) Received: from [192.168.1.50] (antoniah.static.otenet.gr. [79.129.103.151]) by smtp.gmail.com with ESMTPSA id fn8sm1430845wib.2.2015.08.10.12.53.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Aug 2015 12:54:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Yoav Nir In-Reply-To: Date: Mon, 10 Aug 2015 22:53:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <17986EB3-08CC-4AB5-92FB-D101FA23A6E1@gmail.com> References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> To: Andrei Popov X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:54:08 -0000 > On Aug 10, 2015, at 10:04 PM, Andrei Popov = wrote: >=20 >> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over = TLS 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2. > Correct, anything less than this will create deployment problems. >=20 >> I=E2=80=99d like to point out that I am very interested in this use = case, but I=E2=80=99m not sure that this is the solution. > I'm open to alternatives that fix the broken use case.=20 One solution would be to move the authentication for this use case (and = perhaps for HTTPS in general) from the transport layer to either HTTP as = an authentication method or to the application (through some = standardized exchange of JSON objects). Another option is to allow renegotiation and your mechanism in HTTP/2 = with some change of behavior that eliminates the race condition. For = example: 1. The server receives a request for a resource that requires a client = certificate 2. The server sends a new HTTP message (or code) that says that client = certificate authentication is required. 3. The client sends a new HTTP control frame with the highest number of = resource that it has requested. 4. The server finishes serving all resources that don=E2=80=99t need = authentication with a number below what the client sent 5. The client does not initiate any new requests. 6. When the server is done, it initiates renegotiation or the new = mechanism 7. After renegotiation, the client can resume sending requests, all of = which are authenticated. The details may be different, but something like this can bring = determinism to the process. >> We still get a race condition where several requests might be = answered before, after or during authentication depending on the timing = of the TLS handshake message vs the HTTP messages. > The idea is that before answering a request that requires client auth, = the server checks if a client cred is available. If there is no suitable = client cred available, the request is blocked until the client = authenticates. This does not necessarily have to block other requests = that do not require client auth. This is a somewhat contrived example, but consider an object in the web = page that says =E2=80=9CHello, guest=E2=80=9D when no credential is = available, and =E2=80=9CHello, Andrei=E2=80=9D when a credential is = available. If the page has optional authentication and you have = presented the certificate, then depending on timing you might still see = =E2=80=9CHello, guest=E2=80=9D on the page. Yoav From nobody Mon Aug 10 13:18:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE63D1B3DA7 for ; Mon, 10 Aug 2015 13:18:27 -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 QmbgkmBOmMrn for ; Mon, 10 Aug 2015 13:18:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851F61B3DA0 for ; Mon, 10 Aug 2015 13:18:25 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 10 Aug 2015 20:18:05 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Mon, 10 Aug 2015 20:18:05 +0000 From: Andrei Popov To: Yoav Nir Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAd2zoCAAABcAIAFY9OAgAIEqACAAC/RAIAB9sGQgAbZS4CAA6ghwIAACXUAgAAYGbCAABB0AIAAAkiw Date: Mon, 10 Aug 2015 20:18:05 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> <17986EB3-08CC-4AB5-92FB-D101FA23A6E1@gmail.com> In-Reply-To: <17986EB3-08CC-4AB5-92FB-D101FA23A6E1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:cmvKJfPjMWdvjyhdZjulUqy7Zggsy7X5wtaS+FPZTired3mT6+z5nB0iX4w3E/ds4Jq+gkTB4hXhWwHLbOf5n8n4+QAazj9/enrhMhyBt0M43IKNByud0R55rQYwNKwnfk8k7aHSTkmSA4EJU/BtHg==; 24:xhClxONz74kXDp+943rsvmVbENSP7DD54sEVkSMKE2FrGSMC9aJDjD17AeOMw3PQU/tTUXaBtLzhA8n8uTMn/Aabr++cWApxLpRDmM5buEA=; 20:sO7L5qKTBtoeD+uE7YF0EJW8kxV+1M8fX2ChSGmIScCY97Zk5Cq4PtjS3mtBfEGR4VduMSB3kcKnl6gykIw4Xg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 06640999CA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(199003)(189002)(50986999)(110136002)(40100003)(2950100001)(93886004)(10090500001)(86362001)(81156007)(76576001)(101416001)(102836002)(122556002)(19580405001)(77096005)(68736005)(77156002)(8990500004)(10400500002)(5005710100001)(62966003)(2900100001)(92566002)(46102003)(5003600100002)(5001860100001)(10290500002)(74316001)(4001540100001)(2656002)(76176999)(97736004)(99286002)(54356999)(33656002)(189998001)(19580395003)(64706001)(106116001)(5001960100002)(5001830100001)(105586002)(87936001)(106356001)(5002640100001)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2015 20:18:05.3561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:18:28 -0000 PiBPbmUgc29sdXRpb24gd291bGQgYmUgdG8gbW92ZSB0aGUgYXV0aGVudGljYXRpb24gZm9yIHRo aXMgdXNlIGNhc2UgKGFuZCBwZXJoYXBzIGZvciBIVFRQUyBpbiBnZW5lcmFsKSBmcm9tIHRoZSB0 cmFuc3BvcnQgbGF5ZXIgdG8gZWl0aGVyIEhUVFAgYXMgYW4gYXV0aGVudGljYXRpb24gbWV0aG9k IG9yIHRvIHRoZSBhcHBsaWNhdGlvbiAodGhyb3VnaCBzb21lIHN0YW5kYXJkaXplZCBleGNoYW5n ZSBvZiBKU09OIG9iamVjdHMpLg0KRG9lc24ndCB0aGlzIHJlcXVpcmUgYW4gdXBkYXRlIG9mIHRo ZSBzaXRlPyBJZiBzbywgaXQgZGVmZWF0cyBvdXIgZ29hbCBvZiBzdXBwb3J0aW5nIGV4aXN0aW5n IHNpdGVzIG92ZXIgbmV3IHByb3RvY29scy4NCg0KPiBBbm90aGVyIG9wdGlvbiBpcyB0byBhbGxv dyByZW5lZ290aWF0aW9uIGFuZCB5b3VyIG1lY2hhbmlzbSBpbiBIVFRQLzIgd2l0aCBzb21lIGNo YW5nZSBvZiBiZWhhdmlvciB0aGF0IGVsaW1pbmF0ZXMgdGhlIHJhY2UgY29uZGl0aW9uLg0KSSdt IG5vdCBzdXJlIHdoYXQgcHVycG9zZSAjMyAoSFRUUCBjb250cm9sIGZyYW1lIHdpdGggdGhlIGhp Z2hlc3QgbnVtYmVyIG9mIHJlc291cmNlKSBzZXJ2ZXMuIENvdWxkbid0IHdlIGp1c3Qgc2F5IHRo ZSBjbGllbnQgbXVzdCBub3Qgc2VuZCBuZXcgcmVxdWVzdHMgYWZ0ZXIgcmVjZWl2aW5nIENlcnRp ZmljYXRlUmVxdWVzdCBhbmQgdW50aWwgc2VuZGluZyBDZXJ0aWZpY2F0ZVZlcmlmeT8NCg0KPiBU aGlzIGlzIGEgc29tZXdoYXQgY29udHJpdmVkIGV4YW1wbGUsIGJ1dCBjb25zaWRlciBhbiBvYmpl Y3QgaW4gdGhlIHdlYiBwYWdlIHRoYXQgc2F5cyDigJxIZWxsbywgZ3Vlc3TigJ0gd2hlbiBubyBj cmVkZW50aWFsIGlzIGF2YWlsYWJsZSwgYW5kIOKAnEhlbGxvLCBBbmRyZWnigJ0gd2hlbiBhIGNy ZWRlbnRpYWwgaXMgYXZhaWxhYmxlLiAgSWYgdGhlIHBhZ2UgaGFzIG9wdGlvbmFsIGF1dGhlbnRp Y2F0aW9uIGFuZCB5b3UgaGF2ZSBwcmVzZW50ZWQgdGhlIGNlcnRpZmljYXRlLCB0aGVuIGRlcGVu ZGluZyBvbiB0aW1pbmcgeW91IG1pZ2h0IHN0aWxsIHNlZSDigJxIZWxsbywgZ3Vlc3TigJ0gb24g dGhlIHBhZ2UuDQpUaGlzIGp1c3QgbWVhbnMgdGhhdCBhIHJlcXVlc3Qgd2FzIGFuc3dlcmVkIGF0 IHRoZSB0aW1lIHRoZXJlIHdhcyBubyBjbGllbnQgY3JlZGVudGlhbC4gVGhpcyBwYWdlIHByb2Jh Ymx5IG5lZWRzIHRvIGJlIGEgcmVzb3VyY2UgdGhhdCByZXF1aXJlcyBjbGllbnQgYXV0aC4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFlvYXYgTmlyIFttYWlsdG86eW5pci5p ZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMCwgMjAxNSAxMjo1MyBQTQ0K VG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogSWxhcmkg TGl1c3ZhYXJhIDxpbGFyaS5saXVzdmFhcmFAZWxpc2FuZXQuZmk+OyB0bHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbVExTXSBDb21tZW50YXJ5IG9uIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24g cHJlc2VudGF0aW9uIHNsaWRlcw0KDQoNCj4gT24gQXVnIDEwLCAyMDE1LCBhdCAxMDowNCBQTSwg QW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IA0KPj4g SWRlYWxseSBhIHNvbHV0aW9uIHdvdWxkIHdvcmsgd2l0aCBIVFRQLzEgb3ZlciBUTFMgMS4zLCBI VFRQLzIgb3ZlciBUTFMgMS4zLCBIVFRQLzIgb3ZlciBUTFMgMS4yLCBhbmQgZm9yIGNvbXBsZXRl bmVzcyBIVFRQLzEgb3ZlciBUTFMgMS4yLg0KPiBDb3JyZWN0LCBhbnl0aGluZyBsZXNzIHRoYW4g dGhpcyB3aWxsIGNyZWF0ZSBkZXBsb3ltZW50IHByb2JsZW1zLg0KPiANCj4+IEnigJlkIGxpa2Ug dG8gcG9pbnQgb3V0IHRoYXQgSSBhbSB2ZXJ5IGludGVyZXN0ZWQgaW4gdGhpcyB1c2UgY2FzZSwg YnV0IEnigJltIG5vdCBzdXJlIHRoYXQgdGhpcyBpcyB0aGUgc29sdXRpb24uDQo+IEknbSBvcGVu IHRvIGFsdGVybmF0aXZlcyB0aGF0IGZpeCB0aGUgYnJva2VuIHVzZSBjYXNlLiANCg0KT25lIHNv bHV0aW9uIHdvdWxkIGJlIHRvIG1vdmUgdGhlIGF1dGhlbnRpY2F0aW9uIGZvciB0aGlzIHVzZSBj YXNlIChhbmQgcGVyaGFwcyBmb3IgSFRUUFMgaW4gZ2VuZXJhbCkgZnJvbSB0aGUgdHJhbnNwb3J0 IGxheWVyIHRvIGVpdGhlciBIVFRQIGFzIGFuIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBvciB0byB0 aGUgYXBwbGljYXRpb24gKHRocm91Z2ggc29tZSBzdGFuZGFyZGl6ZWQgZXhjaGFuZ2Ugb2YgSlNP TiBvYmplY3RzKS4NCg0KQW5vdGhlciBvcHRpb24gaXMgdG8gYWxsb3cgcmVuZWdvdGlhdGlvbiBh bmQgeW91ciBtZWNoYW5pc20gaW4gSFRUUC8yIHdpdGggc29tZSBjaGFuZ2Ugb2YgYmVoYXZpb3Ig dGhhdCBlbGltaW5hdGVzIHRoZSByYWNlIGNvbmRpdGlvbi4gRm9yIGV4YW1wbGU6DQogMS4gVGhl IHNlcnZlciByZWNlaXZlcyBhIHJlcXVlc3QgZm9yIGEgcmVzb3VyY2UgdGhhdCByZXF1aXJlcyBh IGNsaWVudCBjZXJ0aWZpY2F0ZSAgMi4gVGhlIHNlcnZlciBzZW5kcyBhIG5ldyBIVFRQIG1lc3Nh Z2UgKG9yIGNvZGUpIHRoYXQgc2F5cyB0aGF0IGNsaWVudCBjZXJ0aWZpY2F0ZSBhdXRoZW50aWNh dGlvbiBpcyByZXF1aXJlZC4NCiAzLiBUaGUgY2xpZW50IHNlbmRzIGEgbmV3IEhUVFAgY29udHJv bCBmcmFtZSB3aXRoIHRoZSBoaWdoZXN0IG51bWJlciBvZiByZXNvdXJjZSB0aGF0IGl0IGhhcyBy ZXF1ZXN0ZWQuDQogNC4gVGhlIHNlcnZlciBmaW5pc2hlcyBzZXJ2aW5nIGFsbCByZXNvdXJjZXMg dGhhdCBkb27igJl0IG5lZWQgYXV0aGVudGljYXRpb24gd2l0aCBhIG51bWJlciBiZWxvdyB3aGF0 IHRoZSBjbGllbnQgc2VudCAgNS4gVGhlIGNsaWVudCBkb2VzIG5vdCBpbml0aWF0ZSBhbnkgbmV3 IHJlcXVlc3RzLg0KIDYuIFdoZW4gdGhlIHNlcnZlciBpcyBkb25lLCBpdCBpbml0aWF0ZXMgcmVu ZWdvdGlhdGlvbiBvciB0aGUgbmV3IG1lY2hhbmlzbSAgNy4gQWZ0ZXIgcmVuZWdvdGlhdGlvbiwg dGhlIGNsaWVudCBjYW4gcmVzdW1lIHNlbmRpbmcgcmVxdWVzdHMsIGFsbCBvZiB3aGljaCBhcmUg YXV0aGVudGljYXRlZC4NCg0KVGhlIGRldGFpbHMgbWF5IGJlIGRpZmZlcmVudCwgYnV0IHNvbWV0 aGluZyBsaWtlIHRoaXMgY2FuIGJyaW5nIGRldGVybWluaXNtIHRvIHRoZSBwcm9jZXNzLg0KDQo+ PiBXZSBzdGlsbCBnZXQgYSByYWNlIGNvbmRpdGlvbiB3aGVyZSBzZXZlcmFsIHJlcXVlc3RzIG1p Z2h0IGJlIGFuc3dlcmVkIGJlZm9yZSwgYWZ0ZXIgb3IgZHVyaW5nIGF1dGhlbnRpY2F0aW9uIGRl cGVuZGluZyBvbiB0aGUgdGltaW5nIG9mIHRoZSBUTFMgaGFuZHNoYWtlIG1lc3NhZ2UgdnMgdGhl IEhUVFAgbWVzc2FnZXMuDQo+IFRoZSBpZGVhIGlzIHRoYXQgYmVmb3JlIGFuc3dlcmluZyBhIHJl cXVlc3QgdGhhdCByZXF1aXJlcyBjbGllbnQgYXV0aCwgdGhlIHNlcnZlciBjaGVja3MgaWYgYSBj bGllbnQgY3JlZCBpcyBhdmFpbGFibGUuIElmIHRoZXJlIGlzIG5vIHN1aXRhYmxlIGNsaWVudCBj cmVkIGF2YWlsYWJsZSwgdGhlIHJlcXVlc3QgaXMgYmxvY2tlZCB1bnRpbCB0aGUgY2xpZW50IGF1 dGhlbnRpY2F0ZXMuIFRoaXMgZG9lcyBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBibG9jayBvdGhl ciByZXF1ZXN0cyB0aGF0IGRvIG5vdCByZXF1aXJlIGNsaWVudCBhdXRoLg0KDQpUaGlzIGlzIGEg c29tZXdoYXQgY29udHJpdmVkIGV4YW1wbGUsIGJ1dCBjb25zaWRlciBhbiBvYmplY3QgaW4gdGhl IHdlYiBwYWdlIHRoYXQgc2F5cyDigJxIZWxsbywgZ3Vlc3TigJ0gd2hlbiBubyBjcmVkZW50aWFs IGlzIGF2YWlsYWJsZSwgYW5kIOKAnEhlbGxvLCBBbmRyZWnigJ0gd2hlbiBhIGNyZWRlbnRpYWwg aXMgYXZhaWxhYmxlLiAgSWYgdGhlIHBhZ2UgaGFzIG9wdGlvbmFsIGF1dGhlbnRpY2F0aW9uIGFu ZCB5b3UgaGF2ZSBwcmVzZW50ZWQgdGhlIGNlcnRpZmljYXRlLCB0aGVuIGRlcGVuZGluZyBvbiB0 aW1pbmcgeW91IG1pZ2h0IHN0aWxsIHNlZSDigJxIZWxsbywgZ3Vlc3TigJ0gb24gdGhlIHBhZ2Uu DQoNCllvYXYNCg0K From nobody Mon Aug 10 16:31:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0A61A1AC6; Mon, 10 Aug 2015 16:31: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 PQtnrz3OaQqR; Mon, 10 Aug 2015 16:31:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5F71A1B21; Mon, 10 Aug 2015 16:31:34 -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: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150810233134.24890.55273.idtracker@ietfa.amsl.com> Date: Mon, 10 Aug 2015 16:31:34 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] Last Call: (A TLS ClientHello padding extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 23:31:45 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'A TLS ClientHello padding extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Aug 10 22:00:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F81A00A7 for ; Mon, 10 Aug 2015 22:00:47 -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 gExjmYtWuBJv for ; Mon, 10 Aug 2015 22:00:45 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DF01A009B for ; Mon, 10 Aug 2015 22:00:44 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 21D301A26D3; Tue, 11 Aug 2015 08:00:40 +0300 (EEST) Date: Tue, 11 Aug 2015 08:00:40 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20150811050040.GA4729@LK-Perkele-VII> References: <20150801084849.GA7162@LK-Perkele-VII> <20150802182908.GA29836@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 05:00:47 -0000 On Mon, Aug 10, 2015 at 07:33:53PM +0000, David Benjamin wrote: > > Why not do this using HTTP's own auth framework? Have the client sign > something which includes a channel binding, placing it and the certificate > chain in an Authorization header. You could even transition to it in TLS > 1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not > negotiated, fall back to the legacy thing. Yeah, that would be much cleaner (and indeed was one[1] of the two ways I think HTTP/2 client auth can be done without gross hacks). Except that because for clean operation HTTP needs request-level authentication, one would have to transmit the authentication on each request (fortunately, on subsequent retransmits, it can be compressed very well[2]). [1] The other would be signaling via HTTP 401 and using that to trigger new connection with client-driven client auth. [2] Unless the payload needs internal nonces (and I don't think it does), one can assume the same certificate on the same connection always generates the same cert+signature block (if using deterministic signatures, that happens even if one tries to sign again). -Ilari From nobody Mon Aug 10 23:06:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB11A024E for ; Mon, 10 Aug 2015 23:06: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 S2Me98D2hbGL for ; Mon, 10 Aug 2015 23:06:01 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFD51A0248 for ; Mon, 10 Aug 2015 23:06:01 -0700 (PDT) Received: by qkcs67 with SMTP id s67so43742907qkc.1 for ; Mon, 10 Aug 2015 23:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=KIsaZdeesHQjZFHnCZj+Nx0BXVx26G8cumk3Im9GSNY=; b=kTkEy00J3vyZTUwUj6H/zlBfpx2JwGbQLQ4/WwAaVOS8di64tbqiX7jLzaXOSjaTA+ HCDr3mjmz4Fk8ez9A39SJnkf1/4QeZbrOGW4eHc0PCgOntNjb4ZUwnyVoQix+0cSrOEs mIMNlSpyRsSP5KUG+AGc69cSwvCtd/FnTPmc9r0PavRHnldSNloiAYO+YPd/7XJAtTvr CPeyEKwgtiMXlTnNqL4/09tFTqqtODslkTGlgAVCm+Md9okHpdT0EqmNDe9Q6MCtM0vj Ggt0ulagz8rXLAPEVzaaiR02LwJasmHDTRtSXGbTYLiz+x/IflOipgHIBZeQQ1NWBV2r WC/Q== X-Received: by 10.55.25.87 with SMTP id k84mr11664904qkh.15.1439273160560; Mon, 10 Aug 2015 23:06:00 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by smtp.gmail.com with ESMTPSA id 65sm582478qks.30.2015.08.10.23.05.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Aug 2015 23:06:00 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 11 Aug 2015 02:05:58 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508110205.58799.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 06:06:02 -0000 On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: > > What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource triggers client authentication within an existing TLS connection. > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there is no renegotiation, so we need an alternative solution if we want to support these existing sites over TLS1.3. This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this: 1) client connects to server and fetches public resources 2) client requests restricted resource; server sends auth required response (TLS alert or HTTP code) 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert. There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open. This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start. It's a very rough idea, but I'm wondering if it sounds like something worth discussing. Dave From nobody Tue Aug 11 09:39:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA91AC3E5 for ; Tue, 11 Aug 2015 09:39: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 COpBUQJLExfG for ; Tue, 11 Aug 2015 09:39:21 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1210C1A8AF7 for ; Tue, 11 Aug 2015 09:39:21 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so22157982lbc.2 for ; Tue, 11 Aug 2015 09:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=liV9z4iQJGyJlzptVrWTt6pp+1kM+MSrVwoaks5H+DM=; b=G6yiW00st5ZxzUTVACUvT+EtjkBi8vEWyb74xE2TjXnOglYaproNrw/t79Nsu/VAv4 jlCk/YZ7703UBD+e8i0fwsWlVNWlZWVFkYMjLE+Js60QB8l/YBn3VIHjVJJD9Cnc0OGr BfWTUwcifF1YGrR/R0N9R6x/7o4f8NdpAOJlHjZ+HEcG0ShAEbYJr4mWjPoqI+zK4zqK YNTgJtg2J1GxtvRtK1e0Y6u1cZoNNQtNuvOrNjy+nYOXTls2d156r63yJezqGT8dOgUQ Qs6wnqE6xm2Hohosuk+cNqAAXxIL2MwjhSWUsd6EspTK8q8e0lPRhZNdh+JEU2PjRKAd T+qQ== MIME-Version: 1.0 X-Received: by 10.152.7.37 with SMTP id g5mr27440245laa.101.1439311159493; Tue, 11 Aug 2015 09:39:19 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 09:39:19 -0700 (PDT) In-Reply-To: <201508110205.58799.davemgarrett@gmail.com> References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <201508110205.58799.davemgarrett@gmail.com> Date: Tue, 11 Aug 2015 09:39:19 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 16:39:23 -0000 Before people get too far down that road, here: https://tools.ietf.org/html/draft-thomson-httpbis-cant-01 https://tools.ietf.org/html/draft-thomson-tls-care-00 Andrei has made it clear that these do not work for his use case (I'm not yet convinced that they are inadequate, but I am convinced of the fact that Andrei thinks that they are inadequate ;). Also: https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9 This is well-trodden ground. On 10 August 2015 at 23:05, Dave Garrett wrote: > On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: >> > What sort of usecase you have in mind for this? >> >> This is to support a fairly common website design where the landing page= does not require client auth, but subsequent request to a protected resour= ce triggers client authentication within an existing TLS connection. >> In TLS<=3D1.2, this was accomplished via renegotiation. In TLS1.3, there= is no renegotiation, so we need an alternative solution if we want to supp= ort these existing sites over TLS1.3. > > This is just an idea, but what about just allowing a renegotiation-like m= echanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HT= TP response code? The rough idea would be like this: > > 1) client connects to server and fetches public resources > 2) client requests restricted resource; server sends auth required respon= se (TLS alert or HTTP code) > 3) client creates a replacement connection using PSK-based resumption and= early data in the first flight for the request along with the client cert. > > There's a 1 roundtrip cost in there for a new TCP connection, which could= possibly be optimized away by using TCP fast open. > > This general concept is relatively simple in comparison to doing somethin= g mid-connection. Instead of attempting to renegotiate on an existing conne= ction, just make creation of resumed connections cheap enough to start over= with client auth in the handshake from the start. > > It's a very rough idea, but I'm wondering if it sounds like something wor= th discussing. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From henry.story@co-operating.systems Tue Aug 4 01:31:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA71A8794 for ; Tue, 4 Aug 2015 01:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0RtN31W0guRk for ; Tue, 4 Aug 2015 01:31:02 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id 524541A0061 for ; Tue, 4 Aug 2015 01:31:02 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id D956347E5AA for ; Tue, 4 Aug 2015 10:03:15 +0200 (CEST) Received: from mfilter49-d.gandi.net (mfilter49-d.gandi.net [217.70.178.180]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B2E27A80B1 for ; Tue, 4 Aug 2015 10:02:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id cfmDZh-GDIPT for ; Tue, 4 Aug 2015 10:02:34 +0200 (CEST) X-Originating-IP: 85.199.50.190 Received: from [192.168.1.100] (unknown [85.199.50.190]) (Authenticated sender: henry.story@co-operating.systems) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id F1E21A80C6 for ; Tue, 4 Aug 2015 10:02:33 +0200 (CEST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <04FCDF88-350E-4B05-9A32-FC96B2B33F55@co-operating.systems> Date: Tue, 4 Aug 2015 10:02:31 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Subject: [TLS] blink intends to drop keygen and application/x-x509* handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 09:56:25 -0000 I just thought this group would be interested in following the thread on = the blink user group=20 "(Pre-)Intent to Deprecate: element and = application/x-x509-*-cert MIME handling" = https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xa= ck dropping those two features of the web without a good replacement would = make TLS client certificate use in browsers immediately a lot more = problematic.=20 Whether the replacements are there is part of the debate. I am not sure yet how TLS 3.0 and HTTP2.0 are progressing for client = authentication. Henry= From nobody Tue Aug 11 10:49:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FAA1B2D50; Wed, 5 Aug 2015 01:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_lZoqoYJGOs; Wed, 5 Aug 2015 01:12:38 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A5F1B2D8E; Wed, 5 Aug 2015 01:12:37 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-55-55c1c5730748 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.40.12828.375C1C55; Wed, 5 Aug 2015 10:12:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 10:12:34 +0200 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1VVWzrNLwNmjUSvQIGN1uVQpZ39Df+g Date: Wed, 5 Aug 2015 08:12:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rrf46MFQg32zhCz+tP5itFj7r53d 4tP5LkYHZo/WZ3tZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHk9yTWgnmXGSvOHT/C1MB45Sxj FyMnh4SAicT8dV/YIWwxiQv31rN1MXJxCAkcZZRY3bWYFcJZxCjxaO0DoCoODjYBC4nuf9og DSIChRKPG7+DDWIWMJD4e+I6mC0sUCVxcN59VoiaaokHp66zQ9hGEp3PP4LFWQRUJJb9uscC YvMK+Eo0/2pngdh1glmic/88sCJOgViJp7/PMYPYjEDXfT+1hglimbjErSfzmSCuFpBYsuc8 M4QtKvHy8T9WCFtRYufZdmaI+nyJSxOeMEEsE5Q4OfMJywRG0VlIRs1CUjYLSdksoJeZBTQl 1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwOg7 uOW37g7G1a8dDzEKcDAq8fAq5B0MFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxu62y4XrW0u56ub0XHxxhfk17zH7T+u2zN5bYW5n+zDwwxNLP4mpyVwn Poe2Ve0tEjv/yvzzj3VL/AWt5hue9flqnLOqUFzzevvbH4oKDfNEY052fj51bfN5rgmSP+K2 Klm7nBKY+PNZxaRdO0/dEHjF9HnpjNMxztJnbMWv7ezPKtu8jLtK4LASS3FGoqEWc1FxIgA8 UH6XnwIAAA== Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:12:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBSVENX RUIgc3BlY3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCkNClNlbnQ6IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQNClRvOiA8cnRjd2Vi QGlldGYub3JnPg0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3JnKQ0KU3ViamVjdDogW3J0 Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQg dGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpSb21hbiwg QmVybmFyZCwNCnJpZ2h0LCBSRkMgNTc2NCBpcyB0b28gdmFndWUgb24gdGhhdCBhc3BlY3QuIFRo YW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMsIHdoaWNoIGlz IGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5kaW5nLg0KV291bGQgYXBwcmVjaWF0ZSBpZiB0aGlz IGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBhbiBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25p ZmljYW50IHNpZGUgZWZmZWN0cy4NClRoaXMgdG9waWMgaXMgYWxzbyBhbiBvbmdvaW5nIEZBUS4N Cg0KVGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdl IG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGlu ZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLCB3aGlj aCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS4NCg0KQm90aCBjYXBh YmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAgdXNhZ2UgZHJhZnQ6DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rpb24t NC40DQo9PiBidW5kbGluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt cnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNQ0KPT4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11 bHRpcGxleGluZw0KDQpOb3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1c2VkIE9SIFJUUC9SVENQIHRy YW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0aGVyZSB3aWxsIGJlIG1vcmUg dGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAoZWl0aGVyIDIgb3IgNCBpbiBj YXNlIG9mIGF1ZGlvICYgdmlkZW8pLg0KUmFpc2luZyB0aGUgcXVlc3Rpb24gd2hpY2ggRFRMUyBj b25uZWN0aW9uIGlzIHVzZWQgZm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEgdHJhZmZpYz8gLSBC ZWNhdXNlDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KaW5kaWNhdGVzIHRoZSBzaGFyaW5nIG9wdGlvbi4NCldv dWxkIHRoZW4gYmUgYSAzcmQgKG9yIDV0aCkgc2VsZi1jb250YWluZWQgRFRMUyBzZXNzaW9uL0RU TFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz8NCg0KUHJvcG9zYWw6DQpBZGQg ZXhwbGljaXQgdGV4dCB0byBjbGF1c2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUNCmFib3V0IChpbiByZWQpLCBz b21ldGhpbmcgbGlrZToNCg0KICAgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQg bXVsdGlwbGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyDQogICB0aGUgc2FtZSBwb3J0IHBhaXIs IGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb24NCiAgIFtSRkM1NzY0 XSwgc2VjdGlvbiA1LjEuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NCNzZWN0 aW9uLTUuMS4yPi4gIEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2Fkcw0KICAg b3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNrZXRzLg0KDQoNCg0KICAgTm90 ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnMgd2hl biBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCBhcHBsaWVkLiBXZWJSVEMg ZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBvZiB0aGVzZSBEVExTIGNvbm5lY3Rp b25zIOKApiAo4oCcd2hpY2ggb25lP+KAnSkg4oCmIG9yIFRoZXJlIHNob3VsZCBiZSB0aGVuIGEg c2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gZXN0 YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBkYXRhLg0KDQoNCg0KICAgTm90ZSAyOiBU aGVyZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1bmRsaW5nLg0KDQog ICBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBhcnQgb2YgdGhl IERUTFMNCiAgIGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItYWxw bjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4+XS4NCg0KQ29tbWVudHM/DQpSZWdhcmRzLA0K QWxicmVjaHQNCg0KUFMNClVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2NvcmRpbmcgdG8gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9sb2d5LTAxLnR4 dA0KDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNv bV0NClNlbnQ6IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNA0KVG86IFJvbWFuIFNocG91 bnQNCkNjOiBBc3ZlcmVuLCBUb2xnYTsgQ2hyaXN0ZXIgSG9sbWJlcmc7IEVyaWMgUmVzY29ybGE7 IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFJhdXNjaGVuYmFjaCwgVXdlIChOb2tpYSAt IERFL011bmljaCk7IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gV2hhdCB0aGUgZ2F0ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFi b3V0IG11eC9ub24tbXV4DQoNCk9uIEF1ZyA0LCAyMDE1LCBhdCAxNjozMywgUm9tYW4gU2hwb3Vu dCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQoN Ck1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3cm9uZywgc2luY2UgeW91IG5lZWQg dG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9yIFJUUCBhbmQgYW5vdGhlciBmb3Ig UlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9yIHBvc3NpYmx5IGV2ZW4gZW5jcnlw dGlvbiBwcm9maWxlcyBmb3IgUlRQIGFuZCBSVENQLiBJIGNvbW1vbmx5IHNlZSBvbmUgc2Vzc2lv biBmb3IgUlRQIGFuZCBrZXlzIG5lZ290aWF0ZWQgdGhlcmUgdXNlZCBmb3IgYm90aCBSVFAgYW5k IFJUQ1AsIHdoaWNoIGlzIHdyb25nLg0KDQpbQkFdIFllcywgdGhhdCBpcyBvbmx5IG9uZSBvZiBz ZXZlcmFsIGNvbW1vbiBtaXN0YWtlcy4gIFVuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90 IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90 IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFy ZGVyIHRvIG1lc3MgdXAgUlRQL1JUQ1AgbXV4LiAgR2l2ZW4gd2hhdCBJJ3ZlIHNlZW4gc28gZmFy LCBub24tbXV4IGNvdWxkIGJlY29tZSBhIHN1cHBvcnQgbmlnaHRtYXJlLg0K --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaGFsbCBub3QgbWFrZSBSRkMg NTc2NCBjb3JyZWN0aW9ucyBpbiB0aGUgUlRDV0VCIHNwZWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTxicj4NCjxiPlNlbnQ6PC9iPiA1LiBl bG9rdXV0YSAyMDE1IDExOjA0PGJyPg0KPGI+VG86PC9iPiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0 Ozxicj4NCjxiPkNjOjwvYj4gVExTQGlldGYub3JnICh0bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtydGN3ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlv bnM7IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1t dXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+Um9tYW4sIEJlcm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPnJpZ2h0LCBSRkMgNTc2NCBp cyB0b28gdmFndWUgb24gdGhhdCBhc3BlY3QuIFRoYW5rcyBmb3IgY29uZmlybWluZyB0aGUgbnVt YmVyIG9mIERUTFMgc2Vzc2lvbnMsIHdoaWNoIGlzIGlubGluZSB3aXRoIG91ciB1bmRlcnN0YW5k aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5Xb3VsZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdoZXJl IGZpeGVkIGluIGFuIHJ0Y3dlYiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZlY3Rz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5UaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5UaGUgbW9zdCBzaW1wbGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlv IHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQg bXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEgc2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24sDQogd2hpY2ggY291bGQgYmUgdGhlbiBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Cb3RoIGNhcGFiaWxpdGllcyBhcmUgbWFuZGF0ZWQg aW4gdGhlIHJ0cCB1c2FnZSBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNCI+ PHNwYW4gbGFuZz0iREUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQ8L3NwYW4+PC9hPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj48YnI+DQo9Jmd0OyBidW5kbGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rp b24tNC41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRw LXVzYWdlLTI1I3NlY3Rpb24tNC41PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPj0mZ3Q7IFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPk5vdywgSUYgYnVuZGxp bmcgaXMgbm90IHVzZWQgT1IgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGluZyBpcyBub3Qg dXNlZCBUSEVOIHRoZXJlIHdpbGwgYmUgbW9yZSB0aGFuIG9uZSBEVExTIHNlc3Npb24vRFRMUyBj b25uZWN0aW9uIChlaXRoZXIgMiBvciA0IGluIGNhc2UNCiBvZiBhdWRpbyAmYW1wOyB2aWRlbyku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPlJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1 c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ aW5kaWNhdGVzIHRoZSBzaGFyaW5nIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+V291bGQgdGhlbiBiZSBhIDM8 c3VwPnJkPC9zdXA+IChvciA1PHN1cD50aDwvc3VwPikgc2VsZi1jb250YWluZWQgRFRMUyBzZXNz aW9uL0RUTFMgY29ubmVjdGlvbiBmb3IgV2ViUlRDIGRhdGEgdHJhZmZpYz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMxRjQ5N0QiPlByb3Bvc2FsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BZGQgZXhwbGljaXQgdGV4dCB0byBjbGF1 c2UNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41PC9hPiA8bzpwPg0K PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0 OTdEIj5hYm91dCAoaW4gcmVkKSwgc29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11 bHRpcGxleGluZyBvZiBEVExTIGFuZCBSVFAgb3ZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRo ZSBzYW1lIHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGluIHRoZSBEVExTLVNSVFAgc3BlY2lmaWNh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNTc2NCNzZWN0aW9uLTUuMS4yIj5bUkZDNTc2NF0sIHNlY3Rpb24mbmJzcDs1 LjEuMjwvYT4uJm5ic3A7IEFsbCBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbCBwYXlsb2Fkczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG92ZXIgdGhpcyBEVExTIGNvbm5lY3Rpb24gYXJlIFNDVFAg cGFja2V0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBOb3RlIDE6IFRoZXJlIHdpbGwgYmUgdHdvIERU TFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9ucyB3aGVuIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcgaXMgbm90IGFwcGxpZWQuIFdlYlJUQyBkYXRhIHRyYWZmaWMgY291bGQgc3RpbGwg c2hhcmUgb25lIG9mIHRoZXNlIERUTFMgY29ubmVjdGlvbnMg4oCmIDxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+KOKAnHdoaWNoIG9uZT/igJ0pPC9z cGFuPiDigKYgb3IgVGhlcmUgc2hvdWxkIGJlIHRoZW4gYSBzZXBhcmF0ZSwgc2VsZi1jb250YWlu ZWQgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZCBleGNsdXNpdmVseSBm b3IgV2ViUlRDIGRhdGEuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6cmVkIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBO b3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFyIGNvbnNpZGVyYXRpb25zIGluIGNhc2Ugb2YgYnVuZGxp bmcuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgUHJvdG9jb2wgaWRlbnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBh cyBwYXJ0IG9mIHRoZSBEVExTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaGFuZHNoYWtlLCBhcyBz cGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0Zi1ydGN3ZWItYWxwbiI+SS1ELmll dGYtcnRjd2ViLWFscG48L2E+XS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbGJyZWNodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+UFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+VXNpbmcgKEQpVExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0bw0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRlcm1pbm9s b2d5LTAxLnR4dCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWd1YmFsbGEtdGxzLXRl cm1pbm9sb2d5LTAxLnR4dDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEJlcm5hcmQgQWJvYmEgWzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWls LmNvbSI+bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNaXR0d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQ8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFu IFNocG91bnQ8YnI+DQo8Yj5DYzo8L2I+IEFzdmVyZW4sIFRvbGdhOyBDaHJpc3RlciBIb2xtYmVy ZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5i YWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbcnRjd2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25v bi1tdXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gQXVnIDQs IDIwMTUsIGF0IDE2OjMzLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPk1vc3Qgb2YgdGhlIHBlb3BsZSBpbXBsZW1lbnQgdGhpcyB3 cm9uZywgc2luY2UgeW91IG5lZWQgdG8gY3JlYXRlIHR3byBEVExTIHNlc3Npb25zOiBvbmUgZm9y IFJUUCBhbmQgYW5vdGhlciBmb3IgUlRDUC4gQW5kIHRoZW4gdXNlIGRpZmZlcmVudCBrZXlzIG9y IHBvc3NpYmx5IGV2ZW4NCiBlbmNyeXB0aW9uIHByb2ZpbGVzIGZvciBSVFAgYW5kIFJUQ1AuIEkg Y29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZvciBSVFAgYW5kIGtleXMgbmVnb3RpYXRlZCB0aGVy ZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRDUCwgd2hpY2ggaXMgd3JvbmcuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltCQV0gWWVzLCB0aGF0IGlzIG9ubHkgb25l IG9mIHNldmVyYWwgY29tbW9uIG1pc3Rha2VzLiAmbmJzcDtVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2 NCBkb2VzIG5vdCBydWxlIG91dCBhbGwgb2YgdGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVu dHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFyIG9uIGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBp cyBtdWNoIGhhcmRlciB0byBtZXNzIHVwDQogUlRQL1JUQ1AgbXV4LiAmbmJzcDtHaXZlbiB3aGF0 IEkndmUgc2VlbiBzbyBmYXIsIG5vbi1tdXggY291bGQgYmVjb21lIGEgc3VwcG9ydCBuaWdodG1h cmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_-- From nobody Tue Aug 11 10:49:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693C61A8A60; Wed, 5 Aug 2015 05:27:38 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C048BG8RQSZ; Wed, 5 Aug 2015 05:27:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0689.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::689]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B431B2B5B; Wed, 5 Aug 2015 05:27:34 -0700 (PDT) Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 12:27:17 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0225.018; Wed, 5 Aug 2015 12:27:17 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1aJ68xKiZ7z/U6fhCvknvfFMp39Ujzg Date: Wed, 5 Aug 2015 12:27:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [50.182.164.80] x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:WO9Y3l6qmC64JGgcHULo66c8SZOc264bWfnYxXJVtgRd5pm7tfcyZvO5QsFtGtrRhUwyNz3lBhhnNrF8CCUe6mrIsAGDy0kRxwEW9nNiCPXynG2swy207yqJhjQSmSuef3umCTUqaidGmzZE6OQnfQ==; 24:hS1oorcdN/+xA/UzI1egH0kT0sRzj2MJja8xdzLraUjznHu6P+wUEPX2ONlzg5CJJgB6EMd+2NCehNWov/7HKaHWrOZpIYN4pB8YjKn28wk=; 20:6QnentSRke1Fi5Qgg+K+COePM35kObiV8b8QAHw6cBzuNNLmWqG4JPmdQaIA8OkUMzAvlTuV4UYTt7Sh57T9OA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(52604005)(501624003)(24454002)(164054003)(4001540100001)(19617315012)(76176999)(19300405004)(64706001)(561944003)(66066001)(54356999)(19580405001)(50986999)(16236675004)(74316001)(10400500002)(101416001)(33656002)(19609705001)(46102003)(2656002)(87936001)(19625215002)(19580395003)(5001860100001)(5002640100001)(5001830100001)(97736004)(86362001)(189998001)(81156007)(5001770100001)(62966003)(99286002)(93886004)(77156002)(105586002)(5003600100002)(106356001)(40100003)(76576001)(122556002)(92566002)(77096005)(5001960100002)(68736005)(106116001)(102836002)(2900100001)(15975445007)(2950100001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2015 12:27:17.5751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:27:38 -0000 --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBjb21wbGV0ZWx5IGFncmVlLg0KDQpBbmQgSSB0aGluayB3aGF0IEFsYnJlY2h0IHByb3Bv c2VzIGJlbG93IGlzIHRoZSByaWdodCB3YXkgb2YgYWRkcmVzc2luZyB0aGUg4oCcbm8tcnRjcC1t dXggaW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz4oCdIHByb2JsZW06IEFkZGluZyBjbGFyaWZp Y2F0aW9ucy9hbWVuZG1lbnRzIGluIHRoZSByZXNwZWN0aXZlIG5vcm1hdGl2ZSBzcGVjaWZpY2F0 aW9uIHJhdGhlciB0aGFuIGRpc2FsbG93aW5nIGEgY29tYmluYXRpb24gaW4gYSBwcm9maWxlIGJl Y2F1c2UgaXQgaXMg4oCcY29uZnVzaW5n4oCdLg0KSG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJl ciBvZiBEVExTIGNvbm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90 IHVzZWQsIGlzIG5vdCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9k eSB3aG8gYWN0dWFsbHkgdW5kZXJzdGFuZHMgdGhlIHdob2xlIHN0b3J5KSBidXQgb2J2aW91c2x5 IG5vIGhhcm0gb2YgYWRkaW5nIHNvbWUgY2xhcmlmaWNhdGlvbnMuIERhdGFDaGFubmVsIGFzcGVj dHMgbmVlZCB0byBiZSBjcmlzcGx5IHNwZWNpZmllZCB0aG91Z2guIFdoYXQgaXMgdGhlIG1haW4g YWR2YW50YWdlIG9mIGxldHRpbmcgRGF0YUNoYW5uZWwgcG90ZW50aWFsbHkgdXNlIG9uZSBvZiB0 aGUgZXhzaXRpbmcgRFRMUyBjb25uZWN0aW9ucz8gSnVzdCB0byBzYXZlIHNvbWUgdGltZSBvbiBu ZWdvdGlhdGlvbj8NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMDUsIDIwMTUgNDoxMyBBTQ0KVG86IFNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCkgPGFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPjsgPHJ0 Y3dlYkBpZXRmLm9yZz4gPHJ0Y3dlYkBpZXRmLm9yZz4NCkNjOiBUTFNAaWV0Zi5vcmcgKHRsc0Bp ZXRmLm9yZykgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNCkhpLA0KDQpXZSBzaGFsbCBub3QgbWFr ZSBSRkMgNTc2NCBjb3JyZWN0aW9ucyBpbiB0aGUgUlRDV0VCIHNwZWNzLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpDQpTZW50OiA1 LiBlbG9rdXV0YSAyMDE1IDExOjA0DQpUbzogPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPj4NCkNjOiBUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4gKHRsc0Bp ZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPikNClN1YmplY3Q6IFtydGN3ZWJdIE51bWJlciBv ZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7IFJFOiBXaGF0IHRoZSBnYXRld2F5IGRy YWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgNCg0KUm9tYW4sIEJlcm5hcmQsDQpyaWdo dCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3VlIG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZp cm1pbmcgdGhlIG51bWJlciBvZiBEVExTIHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBv dXIgdW5kZXJzdGFuZGluZy4NCldvdWxkIGFwcHJlY2lhdGUgaWYgdGhpcyBjb3VsZCBiZSBzb21l d2hlcmUgZml4ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0byBzaWduaWZpY2FudCBzaWRlIGVm ZmVjdHMuDQpUaGlzIHRvcGljIGlzIGFsc28gYW4gb25nb2luZyBGQVEuDQoNClRoZSBtb3N0IHNp bXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0aCB1c2FnZSBvZiBidW5kbGluZyBw bHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcsIGxlYWRpbmcgdG8g YSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiwgd2hpY2ggY291bGQgYmUgdGhl biBhbHNvIHNoYXJlZCBmb3IgV2ViUlRDIGRhdGEuDQoNCkJvdGggY2FwYWJpbGl0aWVzIGFyZSBt YW5kYXRlZCBpbiB0aGUgcnRwIHVzYWdlIGRyYWZ0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNA0KPT4gYnVuZGxp bmcNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNh Z2UtMjUjc2VjdGlvbi00LjUNCj0+IFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcNCg0K Tm93LCBJRiBidW5kbGluZyBpcyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlw bGV4aW5nIGlzIG5vdCB1c2VkIFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4gb25lIERUTFMg c2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZSBvZiBhdWRpbyAm IHZpZGVvKS4NClJhaXNpbmcgdGhlIHF1ZXN0aW9uIHdoaWNoIERUTFMgY29ubmVjdGlvbiBpcyB1 c2VkIGZvciBhZGRpdGlvbmFsIFdlYlJUQyBkYXRhIHRyYWZmaWM/IC0gQmVjYXVzZQ0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2Vj dGlvbi0zLjUNCmluZGljYXRlcyB0aGUgc2hhcmluZyBvcHRpb24uDQpXb3VsZCB0aGVuIGJlIGEg M3JkIChvciA1dGgpIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24g Zm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/DQoNClByb3Bvc2FsOg0KQWRkIGV4cGxpY2l0IHRleHQg dG8gY2xhdXNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10 cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41DQphYm91dCAoaW4gcmVkKSwgc29tZXRoaW5nIGxpa2U6 DQoNCiAgIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IG11bHRpcGxleGluZyBv ZiBEVExTIGFuZCBSVFAgb3Zlcg0KICAgdGhlIHNhbWUgcG9ydCBwYWlyLCBhcyBkZXNjcmliZWQg aW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9uDQogICBbUkZDNTc2NF0sIHNlY3Rpb24gNS4x LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjQjc2VjdGlvbi01LjEuMj4uICBB bGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9hZHMNCiAgIG92ZXIgdGhpcyBEVExT IGNvbm5lY3Rpb24gYXJlIFNDVFAgcGFja2V0cy4NCg0KDQoNCiAgIE5vdGUgMTogVGhlcmUgd2ls bCBiZSB0d28gRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJh bnNwb3J0IG11bHRpcGxleGluZyBpcyBub3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBj b3VsZCBzdGlsbCBzaGFyZSBvbmUgb2YgdGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgKOKAnHdo aWNoIG9uZT/igJ0pIOKApiBvciBUaGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxm LWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1 c2l2ZWx5IGZvciBXZWJSVEMgZGF0YS4NCg0KDQoNCiAgIE5vdGUgMjogVGhlcmUgYXJlIHNpbWls YXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGluZy4NCg0KICAgUHJvdG9jb2wgaWRl bnRpZmljYXRpb24gTVVTVCBiZSBzdXBwbGllZCBhcyBwYXJ0IG9mIHRoZSBEVExTDQogICBoYW5k c2hha2UsIGFzIHNwZWNpZmllZCBpbiBbSS1ELmlldGYtcnRjd2ViLWFscG48aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjcmVmLUktRC5p ZXRmLXJ0Y3dlYi1hbHBuPl0uDQoNCkNvbW1lbnRzPw0KUmVnYXJkcywNCkFsYnJlY2h0DQoNClBT DQpVc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5nIHRvIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0wMS50eHQNCg0KDQpGcm9tOiBC ZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb21dDQpTZW50OiBNaXR0 d29jaCwgNS4gQXVndXN0IDIwMTUgMDQ6MDQNClRvOiBSb21hbiBTaHBvdW50DQpDYzogQXN2ZXJl biwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBFcmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJy ZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gsIFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyA8 cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eA0KDQpPbiBBdWcgNCwgMjAxNSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpNb3N0IG9mIHRoZSBw ZW9wbGUgaW1wbGVtZW50IHRoaXMgd3JvbmcsIHNpbmNlIHlvdSBuZWVkIHRvIGNyZWF0ZSB0d28g RFRMUyBzZXNzaW9uczogb25lIGZvciBSVFAgYW5kIGFub3RoZXIgZm9yIFJUQ1AuIEFuZCB0aGVu IHVzZSBkaWZmZXJlbnQga2V5cyBvciBwb3NzaWJseSBldmVuIGVuY3J5cHRpb24gcHJvZmlsZXMg Zm9yIFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQg a2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBp cyB3cm9uZy4NCg0KW0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21tb24g bWlzdGFrZXMuICBVbmZvcnR1bmF0ZWx5LCBSRkMgNTc2NCBkb2VzIG5vdCBydWxlIG91dCBhbGwg b2YgdGhlc2UgYW5kIHRoZSBzZWN1cml0eSBkb2N1bWVudHMgYXJlIG5vdCBjcnlzdGFsIGNsZWFy IG9uIGhvdyB0aGluZ3MgbXVzdCBiZSBkb25lLiBJdCBpcyBtdWNoIGhhcmRlciB0byBtZXNzIHVw IFJUUC9SVENQIG11eC4gIEdpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3Vs ZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4NCg== --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIGNvbXBsZXRlbHkg YWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmQgSSB0 aGluayB3aGF0IEFsYnJlY2h0IHByb3Bvc2VzIGJlbG93IGlzIHRoZSByaWdodCB3YXkgb2YgYWRk cmVzc2luZyB0aGUg4oCcbm8tcnRjcC1tdXggaW1wbGVtZW50YXRpb24gZGlmZmljdWx0aWVz4oCd IHByb2JsZW06IEFkZGluZyBjbGFyaWZpY2F0aW9ucy9hbWVuZG1lbnRzDQogaW4gdGhlIHJlc3Bl Y3RpdmUgbm9ybWF0aXZlIHNwZWNpZmljYXRpb24gcmF0aGVyIHRoYW4gZGlzYWxsb3dpbmcgYSBj b21iaW5hdGlvbiBpbiBhIHByb2ZpbGUgYmVjYXVzZSBpdCBpcyDigJxjb25mdXNpbmfigJ0uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJlciBvZiBEVExTIGNv bm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90IHVzZWQsIGlzIG5v dCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9keSB3aG8gYWN0dWFs bHkgdW5kZXJzdGFuZHMNCiB0aGUgd2hvbGUgc3RvcnkpIGJ1dCBvYnZpb3VzbHkgbm8gaGFybSBv ZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0YUNoYW5uZWwgYXNwZWN0cyBuZWVkIHRv IGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hhdCBpcyB0aGUgbWFpbiBhZHZhbnRhZ2Ug b2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxseSB1c2Ugb25lIG9mIHRoZSBleHNpdGlu ZyBEVExTIGNvbm5lY3Rpb25zPyBKdXN0IHRvIHNhdmUgc29tZSB0aW1lIG9uDQogbmVnb3RpYXRp b24/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNPGJyPg0K PGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpICZsdDthbGJyZWNodC5zY2h3 YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs7ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7ICZsdDty dGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUTFNAaWV0Zi5vcmcgKHRsc0BpZXRm Lm9yZykgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIE51bWJlciBvZiBEVExTIHNlc3Npb25zL0RUTFMgY29ubmVjdGlvbnM7IFJFOiBXaGF0IHRo ZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPldlIHNoYWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25z IGluIHRoZSBSVENXRUIgc3BlY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TY2h3YXJ6LCBBbGJyZWNodCAo QWxicmVjaHQpPGJyPg0KPGI+U2VudDo8L2I+IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQ8YnI+DQo8 Yj5Ubzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyI+VExTQGlldGYub3JnPC9hPiAoPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGll dGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMg c2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hv dWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlJvbWFuLCBCZXJuYXJkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5yaWdodCwgUkZDIDU3NjQgaXMgdG9vIHZhZ3Vl IG9uIHRoYXQgYXNwZWN0LiBUaGFua3MgZm9yIGNvbmZpcm1pbmcgdGhlIG51bWJlciBvZiBEVExT IHNlc3Npb25zLCB3aGljaCBpcyBpbmxpbmUgd2l0aCBvdXIgdW5kZXJzdGFuZGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+V291bGQgYXBwcmVjaWF0ZSBpZiB0aGlzIGNvdWxkIGJlIHNvbWV3aGVyZSBmaXhlZCBpbiBh biBydGN3ZWIgZHJhZnQgZHVlIHRvIHNpZ25pZmljYW50IHNpZGUgZWZmZWN0cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ VGhpcyB0b3BpYyBpcyBhbHNvIGFuIG9uZ29pbmcgRkFRLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3 RCI+VGhlIG1vc3Qgc2ltcGxlIGNhc2UgaXMgZ2l2ZW4gYnkgYSBzY2VuYXJpbyB3aXRoIHVzYWdl IG9mIGJ1bmRsaW5nIHBsdXMgdXNhZ2Ugb2YgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxleGlu ZywgbGVhZGluZyB0byBhIHNpbmdsZSBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uLA0KIHdo aWNoIGNvdWxkIGJlIHRoZW4gYWxzbyBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+Qm90aCBjYXBhYmlsaXRpZXMgYXJlIG1hbmRhdGVkIGluIHRoZSBydHAg dXNhZ2UgZHJhZnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQiPjxzcGFuIGxhbmc9 IkRFIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVz YWdlLTI1I3NlY3Rpb24tNC40PC9zcGFuPjwvYT4NCjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+ PGJyPg0KPSZndDsgYnVuZGxpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0yNSNz ZWN0aW9uLTQuNTwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj49Jmd0OyBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlw bGV4aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Ob3csIElGIGJ1bmRsaW5nIGlzIG5vdCB1 c2VkIE9SIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IHVzZWQgVEhFTiB0 aGVyZSB3aWxsIGJlIG1vcmUgdGhhbiBvbmUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiAo ZWl0aGVyIDIgb3IgNCBpbiBjYXNlDQogb2YgYXVkaW8gJmFtcDsgdmlkZW8pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5S YWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5lY3Rpb24gaXMgdXNlZCBmb3IgYWRk aXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1c2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMt MDkjc2VjdGlvbi0zLjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rpb24tMy41PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPmluZGljYXRlcyB0 aGUgc2hhcmluZyBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPldvdWxkIHRoZW4gYmUgYSAzPHN1cD5yZDwvc3Vw PiAob3IgNTxzdXA+dGg8L3N1cD4pIHNlbGYtY29udGFpbmVkIERUTFMgc2Vzc2lvbi9EVExTIGNv bm5lY3Rpb24gZm9yIFdlYlJUQyBkYXRhIHRyYWZmaWM/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdE Ij5Qcm9wb3NhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+QWRkIGV4cGxpY2l0IHRleHQgdG8gY2xhdXNlDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0 cy0wOSNzZWN0aW9uLTMuNSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4gPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+YWJvdXQg KGluIHJlZCksIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBtdWx0aXBsZXhpbmcg b2YgRFRMUyBhbmQgUlRQIG92ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgc2FtZSBwb3J0 IHBhaXIsIGFzIGRlc2NyaWJlZCBpbiB0aGUgRFRMUy1TUlRQIHNwZWNpZmljYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU3NjQjc2VjdGlvbi01LjEuMiI+W1JGQzU3NjRdLCBzZWN0aW9uJm5ic3A7NS4xLjI8L2E+LiZu YnNwOyBBbGwgYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgcGF5bG9hZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBvdmVyIHRoaXMgRFRMUyBjb25uZWN0aW9uIGFyZSBTQ1RQIHBhY2tldHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6 cmVkIj4mbmJzcDsmbmJzcDsgTm90ZSAxOiBUaGVyZSB3aWxsIGJlIHR3byBEVExTIHNlc3Npb25z L0RUTFMgY29ubmVjdGlvbnMgd2hlbiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlz IG5vdCBhcHBsaWVkLiBXZWJSVEMgZGF0YSB0cmFmZmljIGNvdWxkIHN0aWxsIHNoYXJlIG9uZSBv ZiB0aGVzZSBEVExTIGNvbm5lY3Rpb25zIOKApiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxs b3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPijigJx3aGljaCBvbmU/4oCdKTwvc3Bhbj4g4oCmIG9y IFRoZXJlIHNob3VsZCBiZSB0aGVuIGEgc2VwYXJhdGUsIHNlbGYtY29udGFpbmVkIERUTFMgc2Vz c2lvbi9EVExTIGNvbm5lY3Rpb24gZXN0YWJsaXNoZWQgZXhjbHVzaXZlbHkgZm9yIFdlYlJUQyBk YXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsgTm90ZSAyOiBUaGVy ZSBhcmUgc2ltaWxhciBjb25zaWRlcmF0aW9ucyBpbiBjYXNlIG9mIGJ1bmRsaW5nLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IFByb3RvY29sIGlkZW50aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxpZWQgYXMgcGFydCBvZiB0 aGUgRFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGhhbmRzaGFrZSwgYXMgc3BlY2lmaWVkIGlu IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dHJhbnNwb3J0cy0wOSNyZWYtSS1ELmlldGYtcnRjd2ViLWFscG4iPkktRC5pZXRmLXJ0Y3dlYi1h bHBuPC9hPl0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Db21tZW50cz88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+QWxicmVjaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlBTPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlVzaW5nIChEKVRMUyB0ZXJtaW5vbG9neSBhY2NvcmRpbmcgdG8NCjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0wMS50eHQi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1ndWJhbGxhLXRscy10ZXJtaW5vbG9neS0w MS50eHQ8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij4gQmVybmFyZCBBYm9iYSBbPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t Ij5tYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNDxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hw b3VudDxicj4NCjxiPkNjOjwvYj4gQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBF cmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBBdWcgNCwgMjAx NSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+TW9zdCBvZiB0aGUgcGVvcGxlIGltcGxlbWVudCB0aGlzIHdyb25nLCBzaW5jZSB5b3Ug bmVlZCB0byBjcmVhdGUgdHdvIERUTFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQIGFuZCBhbm90aGVy IGZvciBSVENQLiBBbmQgdGhlbiB1c2UgZGlmZmVyZW50IGtleXMgb3IgcG9zc2libHkgZXZlbg0K IGVuY3J5cHRpb24gcHJvZmlsZXMgZm9yIFJUUCBhbmQgUlRDUC4gSSBjb21tb25seSBzZWUgb25l IHNlc3Npb24gZm9yIFJUUCBhbmQga2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVzZWQgZm9yIGJvdGgg UlRQIGFuZCBSVENQLCB3aGljaCBpcyB3cm9uZy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Ygc2V2ZXJhbCBjb21t b24gbWlzdGFrZXMuICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRvZXMgbm90IHJ1bGUg b3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBhcmUgbm90IGNyeXN0 YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11Y2ggaGFyZGVyIHRv IG1lc3MgdXANCiBSVFAvUlRDUCBtdXguICZuYnNwO0dpdmVuIHdoYXQgSSd2ZSBzZWVuIHNvIGZh ciwgbm9uLW11eCBjb3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_SN1PR0301MB15511B00C3FE2072E861B044B2750SN1PR0301MB1551_-- From nobody Tue Aug 11 10:49:40 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23571B2E41; Wed, 5 Aug 2015 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6fmQIGrG47I; Wed, 5 Aug 2015 05:39:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998001A89C5; Wed, 5 Aug 2015 05:39:14 -0700 (PDT) X-AuditID: c1b4fb3a-f79356d000006281-96-55c203f0936d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.E4.25217.0F302C55; Wed, 5 Aug 2015 14:39:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 14:39:12 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "Schwarz, Albrecht (Albrecht)" , "" Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Thread-Index: AQHQz1VVWzrNLwNmjUSvQIGN1uVQpZ39Df+ggAAl8YCAACS3wA== Date: Wed, 5 Aug 2015 12:39:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B348E9576@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje4H5kOhBhsuaFn8af3FaLH2Xzu7 xezO90wWn853MTqweLQ+28vqsWTJTyaPS5//swcwR3HZpKTmZJalFunbJXBl9C9eyFTwaAlT xbxTG9kaGHvmMnUxcnJICJhI9P39zghhi0lcuLeeDcQWEjjKKLHmUngXIxeQvYhR4tbSJ0AN HBxsAhYS3f+0QeIiArMZJVZ/OAU2iFnAQOLvietgg4QFqiQOzrvPCmKLCFRLPDh1nR3CdpL4 0jGZGWQOi4CKxM5zfiBhXgFfiXOrVrBA7HrMIvF4zx+wIzgFEiUe71sANp8R6Ljvp9ZA7RKX uPVkPtQDAhJL9pxnhrBFJV4+/scKYStK7DzbzgxRny/x8tdSVohlghInZz5hmcAoOgvJqFlI ymYhKZsFdCqzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGI8Ht/y22sF48LnjIUYBDkYlHl6FvIOhQqyJZcWVuYcYpTlYlMR5Z2zOCxUS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6La67PucjdlxH3fM/fHyV0nCv4smShcOqNZfenls 5gchzist1ZZBVxfFZx25krZnpV/EttxHpve5jKRPvc7UizEXntRy7UnIkxnRe63imUNv7A7J bCh8oXH1s9zUg9uVhZ6JxpxaEMzW2s0vkB7Go6gdtITfyCP/X9CVBeUl/Jd16vhfLTc+pMRS nJFoqMVcVJwIAISUnwSoAgAA Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:39:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZ3Vlc3Mgd2UgY291bGQgYWRkIHNvbWUgY2xhcmlmaWNhdGlvbiB0ZXh0IHRvIHRo ZSBTRFAtRFRMUyBkcmFmdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQXN2ZXJl biwgVG9sZ2EgW21haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb21dDQpTZW50OiA1LiBlbG9rdXV0 YSAyMDE1IDE1OjI3DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFNjaHdhcnosIEFsYnJlY2h0IChB bGJyZWNodCk7IDxydGN3ZWJAaWV0Zi5vcmc+DQpDYzogVExTQGlldGYub3JnICh0bHNAaWV0Zi5v cmcpDQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBj b25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBt dXgvbm9uLW11eA0KDQpZZXMsIGNvbXBsZXRlbHkgYWdyZWUuDQoNCkFuZCBJIHRoaW5rIHdoYXQg QWxicmVjaHQgcHJvcG9zZXMgYmVsb3cgaXMgdGhlIHJpZ2h0IHdheSBvZiBhZGRyZXNzaW5nIHRo ZSDigJxuby1ydGNwLW11eCBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHRpZXPigJ0gcHJvYmxlbTog QWRkaW5nIGNsYXJpZmljYXRpb25zL2FtZW5kbWVudHMgaW4gdGhlIHJlc3BlY3RpdmUgbm9ybWF0 aXZlIHNwZWNpZmljYXRpb24gcmF0aGVyIHRoYW4gZGlzYWxsb3dpbmcgYSBjb21iaW5hdGlvbiBp biBhIHByb2ZpbGUgYmVjYXVzZSBpdCBpcyDigJxjb25mdXNpbmfigJ0uDQpIb25lc3RseSwgSSB0 aGluayB0aGUgbnVtYmVyIG9mIERUTFMgY29ubmVjdGlvbnMgdG8gdXNlLCB3aGVuIGJ1bmRsaW5n L211eGluZyBpcyBub3QgdXNlZCwgaXMgbm90IHJlYWxseSB0aGF0IGhhcmQgdG8gZmlndXJlIG91 dCAoZm9yIHNvbWVib2R5IHdobyBhY3R1YWxseSB1bmRlcnN0YW5kcyB0aGUgd2hvbGUgc3Rvcnkp IGJ1dCBvYnZpb3VzbHkgbm8gaGFybSBvZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0 YUNoYW5uZWwgYXNwZWN0cyBuZWVkIHRvIGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hh dCBpcyB0aGUgbWFpbiBhZHZhbnRhZ2Ugb2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxs eSB1c2Ugb25lIG9mIHRoZSBleHNpdGluZyBEVExTIGNvbm5lY3Rpb25zPyBKdXN0IHRvIHNhdmUg c29tZSB0aW1lIG9uIG5lZ290aWF0aW9uPw0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVy IEhvbG1iZXJnDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNDQpUbzog U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KSA8YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1 Y2VudC5jb208bWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPj47IDxy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+IDxydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpDYzogVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0 Zi5vcmc+ICh0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4pIDx0bHNAaWV0Zi5vcmc8 bWFpbHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gTnVtYmVyIG9mIERU TFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQg c2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eA0KDQpIaSwNCg0KV2Ugc2hhbGwgbm90IG1ha2Ug UkZDIDU3NjQgY29ycmVjdGlvbnMgaW4gdGhlIFJUQ1dFQiBzcGVjcy4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KQ0KU2VudDogNS4g ZWxva3V1dGEgMjAxNSAxMTowNA0KVG86IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4+DQpDYzogVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+ICh0bHNAaWV0 Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4pDQpTdWJqZWN0OiBbcnRjd2ViXSBOdW1iZXIgb2Yg RFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0ZXdheSBkcmFm dCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4DQoNClJvbWFuLCBCZXJuYXJkLA0KcmlnaHQs IFJGQyA1NzY0IGlzIHRvbyB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZvciBjb25maXJt aW5nIHRoZSBudW1iZXIgb2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5lIHdpdGggb3Vy IHVuZGVyc3RhbmRpbmcuDQpXb3VsZCBhcHByZWNpYXRlIGlmIHRoaXMgY291bGQgYmUgc29tZXdo ZXJlIGZpeGVkIGluIGFuIHJ0Y3dlYiBkcmFmdCBkdWUgdG8gc2lnbmlmaWNhbnQgc2lkZSBlZmZl Y3RzLg0KVGhpcyB0b3BpYyBpcyBhbHNvIGFuIG9uZ29pbmcgRkFRLg0KDQpUaGUgbW9zdCBzaW1w bGUgY2FzZSBpcyBnaXZlbiBieSBhIHNjZW5hcmlvIHdpdGggdXNhZ2Ugb2YgYnVuZGxpbmcgcGx1 cyB1c2FnZSBvZiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nLCBsZWFkaW5nIHRvIGEg c2luZ2xlIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5lY3Rpb24sIHdoaWNoIGNvdWxkIGJlIHRoZW4g YWxzbyBzaGFyZWQgZm9yIFdlYlJUQyBkYXRhLg0KDQpCb3RoIGNhcGFiaWxpdGllcyBhcmUgbWFu ZGF0ZWQgaW4gdGhlIHJ0cCB1c2FnZSBkcmFmdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00LjQNCj0+IGJ1bmRsaW5n DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdl LTI1I3NlY3Rpb24tNC41DQo9PiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nDQoNCk5v dywgSUYgYnVuZGxpbmcgaXMgbm90IHVzZWQgT1IgUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxl eGluZyBpcyBub3QgdXNlZCBUSEVOIHRoZXJlIHdpbGwgYmUgbW9yZSB0aGFuIG9uZSBEVExTIHNl c3Npb24vRFRMUyBjb25uZWN0aW9uIChlaXRoZXIgMiBvciA0IGluIGNhc2Ugb2YgYXVkaW8gJiB2 aWRlbykuDQpSYWlzaW5nIHRoZSBxdWVzdGlvbiB3aGljaCBEVExTIGNvbm5lY3Rpb24gaXMgdXNl ZCBmb3IgYWRkaXRpb25hbCBXZWJSVEMgZGF0YSB0cmFmZmljPyAtIEJlY2F1c2UNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3NlY3Rp b24tMy41DQppbmRpY2F0ZXMgdGhlIHNoYXJpbmcgb3B0aW9uLg0KV291bGQgdGhlbiBiZSBhIDNy ZCAob3IgNXRoKSBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGZv ciBXZWJSVEMgZGF0YSB0cmFmZmljPw0KDQpQcm9wb3NhbDoNCkFkZCBleHBsaWNpdCB0ZXh0IHRv IGNsYXVzZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cy0wOSNzZWN0aW9uLTMuNQ0KYWJvdXQgKGluIHJlZCksIHNvbWV0aGluZyBsaWtlOg0K DQogICBXZWJSVEMgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBtdWx0aXBsZXhpbmcgb2Yg RFRMUyBhbmQgUlRQIG92ZXINCiAgIHRoZSBzYW1lIHBvcnQgcGFpciwgYXMgZGVzY3JpYmVkIGlu IHRoZSBEVExTLVNSVFAgc3BlY2lmaWNhdGlvbg0KICAgW1JGQzU3NjRdLCBzZWN0aW9uIDUuMS4y PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY0I3NlY3Rpb24tNS4xLjI+LiAgQWxs IGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHBheWxvYWRzDQogICBvdmVyIHRoaXMgRFRMUyBj b25uZWN0aW9uIGFyZSBTQ1RQIHBhY2tldHMuDQoNCg0KDQogICBOb3RlIDE6IFRoZXJlIHdpbGwg YmUgdHdvIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9ucyB3aGVuIFJUUC9SVENQIHRyYW5z cG9ydCBtdWx0aXBsZXhpbmcgaXMgbm90IGFwcGxpZWQuIFdlYlJUQyBkYXRhIHRyYWZmaWMgY291 bGQgc3RpbGwgc2hhcmUgb25lIG9mIHRoZXNlIERUTFMgY29ubmVjdGlvbnMg4oCmICjigJx3aGlj aCBvbmU/4oCdKSDigKYgb3IgVGhlcmUgc2hvdWxkIGJlIHRoZW4gYSBzZXBhcmF0ZSwgc2VsZi1j b250YWluZWQgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlvbiBlc3RhYmxpc2hlZCBleGNsdXNp dmVseSBmb3IgV2ViUlRDIGRhdGEuDQoNCg0KDQogICBOb3RlIDI6IFRoZXJlIGFyZSBzaW1pbGFy IGNvbnNpZGVyYXRpb25zIGluIGNhc2Ugb2YgYnVuZGxpbmcuDQoNCiAgIFByb3RvY29sIGlkZW50 aWZpY2F0aW9uIE1VU1QgYmUgc3VwcGxpZWQgYXMgcGFydCBvZiB0aGUgRFRMUw0KICAgaGFuZHNo YWtlLCBhcyBzcGVjaWZpZWQgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1hbHBuPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLTA5I3JlZi1JLUQuaWV0 Zi1ydGN3ZWItYWxwbj5dLg0KDQpDb21tZW50cz8NClJlZ2FyZHMsDQpBbGJyZWNodA0KDQpQUw0K VXNpbmcgKEQpVExTIHRlcm1pbm9sb2d5IGFjY29yZGluZyB0byBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlub2xvZ3ktMDEudHh0DQoNCg0KRnJvbTogQmVy bmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tXQ0KU2VudDogTWl0dHdv Y2gsIDUuIEF1Z3VzdCAyMDE1IDA0OjA0DQpUbzogUm9tYW4gU2hwb3VudA0KQ2M6IEFzdmVyZW4s IFRvbGdhOyBDaHJpc3RlciBIb2xtYmVyZzsgRXJpYyBSZXNjb3JsYTsgU2Nod2FyeiwgQWxicmVj aHQgKEFsYnJlY2h0KTsgUmF1c2NoZW5iYWNoLCBVd2UgKE5va2lhIC0gREUvTXVuaWNoKTsgPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXaGF0IHRoZSBnYXRld2F5IGRyYWZ0IHNob3VsZCBzYXkgYWJvdXQgbXV4L25vbi1tdXgN Cg0KT24gQXVnIDQsIDIwMTUsIGF0IDE2OjMzLCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCg0KTW9zdCBvZiB0aGUgcGVv cGxlIGltcGxlbWVudCB0aGlzIHdyb25nLCBzaW5jZSB5b3UgbmVlZCB0byBjcmVhdGUgdHdvIERU TFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQIGFuZCBhbm90aGVyIGZvciBSVENQLiBBbmQgdGhlbiB1 c2UgZGlmZmVyZW50IGtleXMgb3IgcG9zc2libHkgZXZlbiBlbmNyeXB0aW9uIHByb2ZpbGVzIGZv ciBSVFAgYW5kIFJUQ1AuIEkgY29tbW9ubHkgc2VlIG9uZSBzZXNzaW9uIGZvciBSVFAgYW5kIGtl eXMgbmVnb3RpYXRlZCB0aGVyZSB1c2VkIGZvciBib3RoIFJUUCBhbmQgUlRDUCwgd2hpY2ggaXMg d3JvbmcuDQoNCltCQV0gWWVzLCB0aGF0IGlzIG9ubHkgb25lIG9mIHNldmVyYWwgY29tbW9uIG1p c3Rha2VzLiAgVW5mb3J0dW5hdGVseSwgUkZDIDU3NjQgZG9lcyBub3QgcnVsZSBvdXQgYWxsIG9m IHRoZXNlIGFuZCB0aGUgc2VjdXJpdHkgZG9jdW1lbnRzIGFyZSBub3QgY3J5c3RhbCBjbGVhciBv biBob3cgdGhpbmdzIG11c3QgYmUgZG9uZS4gSXQgaXMgbXVjaCBoYXJkZXIgdG8gbWVzcyB1cCBS VFAvUlRDUCBtdXguICBHaXZlbiB3aGF0IEkndmUgc2VlbiBzbyBmYXIsIG5vbi1tdXggY291bGQg YmVjb21lIGEgc3VwcG9ydCBuaWdodG1hcmUuDQo= --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2lu LWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB3ZSBjb3VsZCBh ZGQgc29tZSBjbGFyaWZpY2F0aW9uIHRleHQgdG8gdGhlIFNEUC1EVExTIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFzdmVyZW4sIFRvbGdhIFttYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDUuIGVsb2t1dXRhIDIwMTUgMTU6 Mjc8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAo QWxicmVjaHQpOyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gVExTQGll dGYub3JnICh0bHNAaWV0Zi5vcmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBO dW1iZXIgb2YgRFRMUyBzZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zOyBSRTogV2hhdCB0aGUgZ2F0 ZXdheSBkcmFmdCBzaG91bGQgc2F5IGFib3V0IG11eC9ub24tbXV4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIGNvbXBsZXRlbHkgYWdyZWUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBJIHRoaW5rIHdoYXQgQWxicmVjaHQg cHJvcG9zZXMgYmVsb3cgaXMgdGhlIHJpZ2h0IHdheSBvZiBhZGRyZXNzaW5nIHRoZSDigJxuby1y dGNwLW11eCBpbXBsZW1lbnRhdGlvbiBkaWZmaWN1bHRpZXPigJ0gcHJvYmxlbTogQWRkaW5nIGNs YXJpZmljYXRpb25zL2FtZW5kbWVudHMNCiBpbiB0aGUgcmVzcGVjdGl2ZSBub3JtYXRpdmUgc3Bl Y2lmaWNhdGlvbiByYXRoZXIgdGhhbiBkaXNhbGxvd2luZyBhIGNvbWJpbmF0aW9uIGluIGEgcHJv ZmlsZSBiZWNhdXNlIGl0IGlzIOKAnGNvbmZ1c2luZ+KAnS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9uZXN0bHksIEkgdGhpbmsgdGhlIG51bWJlciBvZiBE VExTIGNvbm5lY3Rpb25zIHRvIHVzZSwgd2hlbiBidW5kbGluZy9tdXhpbmcgaXMgbm90IHVzZWQs IGlzIG5vdCByZWFsbHkgdGhhdCBoYXJkIHRvIGZpZ3VyZSBvdXQgKGZvciBzb21lYm9keQ0KIHdo byBhY3R1YWxseSB1bmRlcnN0YW5kcyB0aGUgd2hvbGUgc3RvcnkpIGJ1dCBvYnZpb3VzbHkgbm8g aGFybSBvZiBhZGRpbmcgc29tZSBjbGFyaWZpY2F0aW9ucy4gRGF0YUNoYW5uZWwgYXNwZWN0cyBu ZWVkIHRvIGJlIGNyaXNwbHkgc3BlY2lmaWVkIHRob3VnaC4gV2hhdCBpcyB0aGUgbWFpbiBhZHZh bnRhZ2Ugb2YgbGV0dGluZyBEYXRhQ2hhbm5lbCBwb3RlbnRpYWxseSB1c2Ugb25lIG9mIHRoZSBl eHNpdGluZyBEVExTIGNvbm5lY3Rpb25zPw0KIEp1c3QgdG8gc2F2ZSBzb21lIHRpbWUgb24gbmVn b3RpYXRpb24/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEF1Z3VzdCAwNSwgMjAxNSA0OjEzIEFNPGJyPg0KPGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNo dCAoQWxicmVjaHQpICZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb20iPmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs7 ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM U0BpZXRmLm9yZzwvYT4gKDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9y ZzwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vz c2lvbnMvRFRMUyBjb25uZWN0aW9uczsgUkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxk IHNheSBhYm91dCBtdXgvbm9uLW11eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHNo YWxsIG5vdCBtYWtlIFJGQyA1NzY0IGNvcnJlY3Rpb25zIGluIHRoZSBSVENXRUIgc3BlY3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5TY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpPGJyPg0KPGI+U2VudDo8L2I+ IDUuIGVsb2t1dXRhIDIwMTUgMTE6MDQ8YnI+DQo8Yj5Ubzo8L2I+ICZsdDs8YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPiAoPGEgaHJl Zj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gW3J0Y3dlYl0gTnVtYmVyIG9mIERUTFMgc2Vzc2lvbnMvRFRMUyBjb25uZWN0aW9uczsg UkU6IFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11eDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Sb21hbiwgQmVybmFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+cmlnaHQsIFJGQyA1NzY0IGlzIHRv byB2YWd1ZSBvbiB0aGF0IGFzcGVjdC4gVGhhbmtzIGZvciBjb25maXJtaW5nIHRoZSBudW1iZXIg b2YgRFRMUyBzZXNzaW9ucywgd2hpY2ggaXMgaW5saW5lIHdpdGggb3VyIHVuZGVyc3RhbmRpbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPldvdWxkIGFwcHJlY2lhdGUgaWYgdGhpcyBjb3VsZCBiZSBzb21ld2hlcmUgZml4 ZWQgaW4gYW4gcnRjd2ViIGRyYWZ0IGR1ZSB0byBzaWduaWZpY2FudCBzaWRlIGVmZmVjdHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPlRoaXMgdG9waWMgaXMgYWxzbyBhbiBvbmdvaW5nIEZBUS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPlRoZSBtb3N0IHNpbXBsZSBjYXNlIGlzIGdpdmVuIGJ5IGEgc2NlbmFyaW8gd2l0 aCB1c2FnZSBvZiBidW5kbGluZyBwbHVzIHVzYWdlIG9mIFJUUC9SVENQIHRyYW5zcG9ydCBtdWx0 aXBsZXhpbmcsIGxlYWRpbmcgdG8gYSBzaW5nbGUgRFRMUyBzZXNzaW9uL0RUTFMgY29ubmVjdGlv biwNCiB3aGljaCBjb3VsZCBiZSB0aGVuIGFsc28gc2hhcmVkIGZvciBXZWJSVEMgZGF0YS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkJvdGggY2FwYWJpbGl0aWVzIGFyZSBtYW5kYXRlZCBpbiB0 aGUgcnRwIHVzYWdlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItcnRwLXVzYWdlLTI1I3NlY3Rpb24tNC40Ij48c3Bh biBsYW5nPSJERSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXJ0cC11c2FnZS0yNSNzZWN0aW9uLTQuNDwvc3Bhbj48L2E+DQo8L3NwYW4+PHNwYW4gbGFuZz0i REUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMx RjQ5N0QiPjxicj4NCj0mZ3Q7IGJ1bmRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UtMjUjc2VjdGlvbi00 LjUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNh Z2UtMjUjc2VjdGlvbi00LjU8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PSZndDsgUlRQL1JUQ1AgdHJhbnNwb3J0 IG11bHRpcGxleGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Tm93LCBJRiBidW5kbGluZyBp cyBub3QgdXNlZCBPUiBSVFAvUlRDUCB0cmFuc3BvcnQgbXVsdGlwbGV4aW5nIGlzIG5vdCB1c2Vk IFRIRU4gdGhlcmUgd2lsbCBiZSBtb3JlIHRoYW4gb25lIERUTFMgc2Vzc2lvbi9EVExTIGNvbm5l Y3Rpb24gKGVpdGhlciAyIG9yIDQgaW4gY2FzZQ0KIG9mIGF1ZGlvICZhbXA7IHZpZGVvKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+UmFpc2luZyB0aGUgcXVlc3Rpb24gd2hpY2ggRFRMUyBjb25uZWN0aW9uIGlzIHVzZWQg Zm9yIGFkZGl0aW9uYWwgV2ViUlRDIGRhdGEgdHJhZmZpYz8gLSBCZWNhdXNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFu c3BvcnRzLTA5I3NlY3Rpb24tMy41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0wOSNzZWN0aW9uLTMuNTwvYT4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5pbmRp Y2F0ZXMgdGhlIHNoYXJpbmcgb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Xb3VsZCB0aGVuIGJlIGEgMzxzdXA+ cmQ8L3N1cD4gKG9yIDU8c3VwPnRoPC9zdXA+KSBzZWxmLWNvbnRhaW5lZCBEVExTIHNlc3Npb24v RFRMUyBjb25uZWN0aW9uIGZvciBXZWJSVEMgZGF0YSB0cmFmZmljPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+UHJvcG9zYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFkZCBleHBsaWNpdCB0ZXh0IHRvIGNsYXVzZQ0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRy YW5zcG9ydHMtMDkjc2VjdGlvbi0zLjUiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDkjc2VjdGlvbi0zLjU8L2E+IDxvOnA+DQo8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0Qi PmFib3V0IChpbiByZWQpLCBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgbXVsdGlw bGV4aW5nIG9mIERUTFMgYW5kIFJUUCBvdmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIHNh bWUgcG9ydCBwYWlyLCBhcyBkZXNjcmliZWQgaW4gdGhlIERUTFMtU1JUUCBzcGVjaWZpY2F0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NzY0I3NlY3Rpb24tNS4xLjIiPltSRkM1NzY0XSwgc2VjdGlvbiZuYnNwOzUuMS4y PC9hPi4mbmJzcDsgQWxsIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHBheWxvYWRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgb3ZlciB0aGlzIERUTFMgY29ubmVjdGlvbiBhcmUgU0NUUCBwYWNr ZXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5vdGUgMTogVGhlcmUgd2lsbCBiZSB0d28gRFRMUyBz ZXNzaW9ucy9EVExTIGNvbm5lY3Rpb25zIHdoZW4gUlRQL1JUQ1AgdHJhbnNwb3J0IG11bHRpcGxl eGluZyBpcyBub3QgYXBwbGllZC4gV2ViUlRDIGRhdGEgdHJhZmZpYyBjb3VsZCBzdGlsbCBzaGFy ZSBvbmUgb2YgdGhlc2UgRFRMUyBjb25uZWN0aW9ucyDigKYgPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4o4oCcd2hpY2ggb25lP+KAnSk8L3NwYW4+ IOKApiBvciBUaGVyZSBzaG91bGQgYmUgdGhlbiBhIHNlcGFyYXRlLCBzZWxmLWNvbnRhaW5lZCBE VExTIHNlc3Npb24vRFRMUyBjb25uZWN0aW9uIGVzdGFibGlzaGVkIGV4Y2x1c2l2ZWx5IGZvciBX ZWJSVEMgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IE5vdGUg MjogVGhlcmUgYXJlIHNpbWlsYXIgY29uc2lkZXJhdGlvbnMgaW4gY2FzZSBvZiBidW5kbGluZy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBQcm90b2NvbCBpZGVudGlmaWNhdGlvbiBNVVNUIGJlIHN1cHBsaWVkIGFzIHBh cnQgb2YgdGhlIERUTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBoYW5kc2hha2UsIGFzIHNwZWNp ZmllZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt cnRjd2ViLXRyYW5zcG9ydHMtMDkjcmVmLUktRC5pZXRmLXJ0Y3dlYi1hbHBuIj5JLUQuaWV0Zi1y dGN3ZWItYWxwbjwvYT5dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5Q UzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5Vc2luZyAoRClUTFMgdGVybWlub2xvZ3kgYWNjb3JkaW5nIHRvDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlub2xvZ3kt MDEudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZ3ViYWxsYS10bHMtdGVybWlu b2xvZ3ktMDEudHh0PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gQmVybmFyZCBBYm9iYSBbPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29t Ij5tYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1pdHR3b2NoLCA1LiBBdWd1c3QgMjAxNSAwNDowNDxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hw b3VudDxicj4NCjxiPkNjOjwvYj4gQXN2ZXJlbiwgVG9sZ2E7IENocmlzdGVyIEhvbG1iZXJnOyBF cmljIFJlc2NvcmxhOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBSYXVzY2hlbmJhY2gs IFV3ZSAoTm9raWEgLSBERS9NdW5pY2gpOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIFdoYXQgdGhlIGdhdGV3YXkgZHJhZnQgc2hvdWxkIHNheSBhYm91dCBtdXgvbm9uLW11 eDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBBdWcgNCwgMjAx NSwgYXQgMTY6MzMsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+TW9zdCBvZiB0aGUgcGVvcGxlIGltcGxlbWVudCB0aGlzIHdyb25n LCBzaW5jZSB5b3UgbmVlZCB0byBjcmVhdGUgdHdvIERUTFMgc2Vzc2lvbnM6IG9uZSBmb3IgUlRQ IGFuZCBhbm90aGVyIGZvciBSVENQLiBBbmQgdGhlbiB1c2UgZGlmZmVyZW50IGtleXMgb3IgcG9z c2libHkgZXZlbg0KIGVuY3J5cHRpb24gcHJvZmlsZXMgZm9yIFJUUCBhbmQgUlRDUC4gSSBjb21t b25seSBzZWUgb25lIHNlc3Npb24gZm9yIFJUUCBhbmQga2V5cyBuZWdvdGlhdGVkIHRoZXJlIHVz ZWQgZm9yIGJvdGggUlRQIGFuZCBSVENQLCB3aGljaCBpcyB3cm9uZy48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+W0JBXSBZZXMsIHRoYXQgaXMgb25seSBvbmUgb2Yg c2V2ZXJhbCBjb21tb24gbWlzdGFrZXMuICZuYnNwO1VuZm9ydHVuYXRlbHksIFJGQyA1NzY0IGRv ZXMgbm90IHJ1bGUgb3V0IGFsbCBvZiB0aGVzZSBhbmQgdGhlIHNlY3VyaXR5IGRvY3VtZW50cyBh cmUgbm90IGNyeXN0YWwgY2xlYXIgb24gaG93IHRoaW5ncyBtdXN0IGJlIGRvbmUuIEl0IGlzIG11 Y2ggaGFyZGVyIHRvIG1lc3MgdXANCiBSVFAvUlRDUCBtdXguICZuYnNwO0dpdmVuIHdoYXQgSSd2 ZSBzZWVuIHNvIGZhciwgbm9uLW11eCBjb3VsZCBiZWNvbWUgYSBzdXBwb3J0IG5pZ2h0bWFyZS4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_-- From dottomi@gmail.com Sun Aug 9 07:41:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9A1A874F for ; Sun, 9 Aug 2015 07:41: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 4JSJ3AbbjVg7 for ; Sun, 9 Aug 2015 07:41:22 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9901A874B for ; Sun, 9 Aug 2015 07:41:21 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so83105852lbb.0 for ; Sun, 09 Aug 2015 07:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=QDc/82UVFuThlzadO2P/2fH4S6nvz0tdrrx3oTHAoF0=; b=uBqctTNpEW7p7vyPo+KE61/BHydnFNuJmFAh8mN+A11zfztia8FKpLmJZKbvjkbAvR uZED5aPYqLJ0nEL6j5r2BIeJ1dheostHGX5P69++rsp2izFCd7ofPZjNmToAxRQ5j//s xxyH7CF0mkERNW7OqToxp+BiPqmj/OTxlxgzBHyKN3ezrG2wo5va00Njb9KpDqQiAMqy S+usYTXMsmhEGqFzw7bT/zQUyQwp5t7y1gS+Z90Y3Y/UjMQFYuvqGKMTSXLZmXhwea+m lAauzEHxSCVx7E0CUWNQSJB8rQC9sogHIFBEtSuJBcieF9kEI6q2NMqJo1V/rjeLi/bc nzgA== X-Received: by 10.152.30.100 with SMTP id r4mr16293515lah.92.1439131280479; Sun, 09 Aug 2015 07:41:20 -0700 (PDT) Received: from kagomeko.moe (89-72-17-33.dynamic.chello.pl. [89.72.17.33]) by smtp.googlemail.com with ESMTPSA id xf5sm3537817lbb.38.2015.08.09.07.41.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2015 07:41:20 -0700 (PDT) To: tls@ietf.org From: "dottomi@gmail.com" Message-ID: <55C7668F.1040105@gmail.com> Date: Sun, 9 Aug 2015 16:41:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Subject: [TLS] TLS Handshake message length too long X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 14:42:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I have a question regarding the handshake message length. The 'decode_error' alert in TLS 1.2 is defined as: decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. (...) It says that the message "could not be decoded". What should happen if the specified message length is longer than needed? I.e. the message was successfully decoded, but the length of the message was incorrect: there is still some unknown data after the defined structure. For example, a Finished message has a length of 40 bytes, but the 'verify_data' array has 32 bytes and there are 8 unknown bytes remaining in the received message. The 40 bytes I talk about here is the length specified in the Handshake message header. Is this also a fatal error? Should the implementation just drop those bytes and proceed? On the other hand, there is the 'illegal_parameter' alert: illegal_parameter A field in the handshake was out of range or inconsistent with other fields. This message is always fatal. Is this alert suitable for the described scenario? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVx2aPAAoJEDRBz9VZHKuWFOMP/iUyc0+sdyV24EAwCLxSE7+i pv8cA/TIodpH828p0wgrg+hCWCEB39gH3WMJsw9T4ItRKZZ8B8dFTnrtAWQa3smL Z+YNCH1wcl03IuF67W0YjMUTPCIFiY0WwYBOI+GIcYzwse7vW+it5hOfILjM1705 1P2DqILZ8mJtrR5GoVKZAor+ynjTUfkrQl7yrR7dz2wpNK4vdgY/UHXupSNLt2QS lirkzKsUazfZQLzDggNfmUfCugFle3PFatqQShPeSI9QBEO+7rlAgGzPV5FiKPxI +YxJcQIHvEv47caUp9uv8B/3N2L6RhHSHYNjMaBHGzI+BWGfBq0cjv07HIyvtgzg fEZJ+5g9hfWjeDSCQ6wYT6G5io5RxydKKkP+Gunbz9FvLNoz7wdK6b7t/pdQXzqh kp0xXXZfF/psulxIOHmzF3xlGsHz+8iudulNm2OavXBUKXOZFr4QPO6l8wU1KWZ2 6tS2s6c0Hhfyd+lI5w2cP6zFbavmxUzRVd2hkKakIpr18KGEZfIE0eZW9bOvmB32 3nSD1+KLVZDHFAcS2lGH5ubSKbnJl7979j0XZVloi5zfgTCNWES2lffwXABdyvQ5 S5HWnUsPoQCJ98ypp+SEShqFbb0GRjTvZIRpxeb8j2w0onNg2QQCQs6tENaQzYEL tvDaK+aq+empNxAVbMBP =3KMw -----END PGP SIGNATURE----- From clemens.hlauschek@rise-world.com Mon Aug 10 09:12:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE701B37FE for ; Mon, 10 Aug 2015 09:12:56 -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_20=-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 DkwvYQY5xooh for ; Mon, 10 Aug 2015 09:12:54 -0700 (PDT) Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C571B1B37F6 for ; Mon, 10 Aug 2015 09:12:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id 49D8F40E406; Mon, 10 Aug 2015 18:12:45 +0200 (CEST) Received: from [192.168.249.71] (71.4.208.241.ptr.us.xo.net [71.4.208.241]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id 7A7E540E056 for ; Mon, 10 Aug 2015 18:12:44 +0200 (CEST) Message-ID: <55C8CD7A.7030309@rise-world.com> Date: Mon, 10 Aug 2015 12:12:42 -0400 From: Clemens Hlauschek User-Agent: mutt 1.5.23 (Plan 9) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700 Subject: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 16:13:56 -0000 Hi, I published a paper today on KCI-attacks in TLS. This might be of interest to the TLS WG. https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek Regards, Clemens From nobody Tue Aug 11 11:05:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2A11ACE62 for ; Tue, 11 Aug 2015 11:05:41 -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 baDn5UOSiMP3 for ; Tue, 11 Aug 2015 11:05:40 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBA11ACDD3 for ; Tue, 11 Aug 2015 11:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439316340; x=1470852340; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2EwucnoV7L+GzZR+RUhBj/+DxbFwCXwFVi9oUiokE98=; b=tqAPyB/CDRZd4RZLLWW9IplmjX72EbQp/eY/u0KbVCPFruT1fV6lAOdf CItgu96l6qq0ngo/nrEAWYBo+4i5JFv4vtSEkrq9rnANS3w7nrZq72Bim 6WIMN1mFhnolXOvi4mlwFrmUQ7ERbaqeDimbcYT4W3mdj1pcdlKf/tJJ9 /DzvR/q+F0O7N2LXzgIXL5NWPN3UpbYf7zMMP7skLFfbFFyQpi1Wg+B7+ G+tx2rDWusI8i6ANyaLqsS/gB53dkXtoQ59RJlwSfOHNkbCxi2NjA9slX GyflWccXok6ILeN97o0PgW00xrtALDIBQIJw2FqG8qQJek5tkYCTijHDP w==; X-IronPort-AV: E=Sophos;i="5.15,654,1432555200"; d="scan'208";a="34437547" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 06:05:38 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 06:05:37 +1200 From: Peter Gutmann To: Clemens Hlauschek , "tls@ietf.org" Thread-Topic: [TLS] TLS and KCI vulnerable handshakes Thread-Index: AQHQ1F5LrI8QBmnw8E6Q+G9ikduiz54HF7RI Date: Tue, 11 Aug 2015 18:05:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> References: <55C8CD7A.7030309@rise-world.com> In-Reply-To: <55C8CD7A.7030309@rise-world.com> 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: Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 18:05:42 -0000 Clemens Hlauschek writes:=0A= =0A= >I published a paper today on KCI-attacks in TLS. This might be of interest= to=0A= >the TLS WG.=0A= >=0A= >https://www.usenix.org/conference/woot15/workshop-program/presentation/hla= uschek=0A= =0A= Some comments on this, it looks like it requires a "cert with static (EC)DH= =0A= key" in order to work, which would mean an X9.42 cert. Since no (public) C= A=0A= that I know of can handle or issue such certs, this probably provides a=0A= reasonable amount of defence against this attack...=0A= =0A= In terms of the suggested countermeasures:=0A= =0A= >Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, a= nd=0A= >disable specifically the KeyAgreement flag=0A= =0A= Since the keyUsage flags are widely ignored by implementations, this won't= =0A= provide the protection that the text implies.=0A= =0A= Peter.= From nobody Tue Aug 11 11:11:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9E01ACE31 for ; Tue, 11 Aug 2015 11:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AzUH7UgC0iB for ; Tue, 11 Aug 2015 11:11:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888101ACE3E for ; Tue, 11 Aug 2015 11:11:14 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 11 Aug 2015 18:10:53 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0225.018; Tue, 11 Aug 2015 18:10:53 +0000 From: Andrei Popov To: Martin Thomson , Dave Garrett Thread-Topic: [TLS] Commentary on the client authentication presentation slides Thread-Index: AQHQ1FRNSiLWIyLp306JLFOxlCsn654HDhfw Date: Tue, 11 Aug 2015 18:10:53 +0000 Message-ID: References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <201508110205.58799.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:2::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:LXE7F30EgLyOV8X5P1tG1zPKwUEp2Ua6Vgmt3LkvHtW1vfHWkBX7GeYRO/a1gRORVWlkfwnGit/31NWIGMq/8vgYQXQrWMNGF2nRbzhdWY8+YVGCoAkHgdBPcV2fhlMKEoHXGCDAZwPRMNlHGXEIyg==; 24:EfJhHcF3rThmg5WgRfkMUt0DMUdtMrht2Qtq5BgP81/Eqsy0Yh38WAB8BcxX1Erg/A9k6r9a+3FSKpalvM6uMr9I0x7ncG+/1dlxvEhUEDM=; 20:33blxaCAC+U7tEMEtxYXmCUCguqjf8nNR/ILB97XGepGormHSG+HEx/vuv2cDopy5Z9K+cF9WDkh39NDXQcnxQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 066517B35B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(13464003)(377454003)(24454002)(46102003)(92566002)(5001770100001)(5001960100002)(5002640100001)(97736004)(4001540100001)(189998001)(5001830100001)(5001860100001)(81156007)(64706001)(19580405001)(50986999)(76176999)(76576001)(54356999)(33656002)(77096005)(2900100001)(15975445007)(5003600100002)(122556002)(68736005)(102836002)(86362001)(77156002)(62966003)(2950100001)(10090500001)(40100003)(5005710100001)(87936001)(99286002)(8990500004)(19580395003)(2656002)(10290500002)(10400500002)(105586002)(106356001)(93886004)(86612001)(101416001)(74316001)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2015 18:10:53.5307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 18:11:18 -0000 Indeed, I think cant-care has a number of disadvantages: 1. Introduces round-trips to establish a new TCP connection; 2. Requires a new TLS handshake, with associated costs. 3. Uses two CertificateRequests: one at the HTTP layer, and another at the = TLS layer. Somehow we would need to figure out how to make them match, or h= ave the client ignore TLS-level cert filtering parameters? 4. Pushes the problem to the application layer: any application protocol th= at uses mid-stream client auth will require an update. (I know, some will s= ay we are only aware of HTTPS scenarios right now.) At the cost of all of the above, cant-care allows the client to determine e= xactly which HTTP request has resulted in the client auth request. I think = there may be a compromise where we can identify this HTTP request without r= equiring a reconnect. E.g. what about CertificateRequest at the HTTP layer = + TLS client sending Certificate/CertificateVerify after the handshake in t= he middle of the existing TLS connection? Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, August 11, 2015 9:39 AM To: Dave Garrett Cc: tls@ietf.org Subject: Re: [TLS] Commentary on the client authentication presentation sli= des Before people get too far down that road, here: https://tools.ietf.org/html/draft-thomson-httpbis-cant-01 https://tools.ietf.org/html/draft-thomson-tls-care-00 Andrei has made it clear that these do not work for his use case (I'm not y= et convinced that they are inadequate, but I am convinced of the fact that = Andrei thinks that they are inadequate ;). Also: https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9 This is well-trodden ground. On 10 August 2015 at 23:05, Dave Garrett wrote: > On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote: >> > What sort of usecase you have in mind for this? >> >> This is to support a fairly common website design where the landing page= does not require client auth, but subsequent request to a protected resour= ce triggers client authentication within an existing TLS connection. >> In TLS<=3D1.2, this was accomplished via renegotiation. In TLS1.3, there= is no renegotiation, so we need an alternative solution if we want to supp= ort these existing sites over TLS1.3. > > This is just an idea, but what about just allowing a renegotiation-like m= echanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HT= TP response code? The rough idea would be like this: > > 1) client connects to server and fetches public resources > 2) client requests restricted resource; server sends auth required=20 > response (TLS alert or HTTP code) > 3) client creates a replacement connection using PSK-based resumption and= early data in the first flight for the request along with the client cert. > > There's a 1 roundtrip cost in there for a new TCP connection, which could= possibly be optimized away by using TCP fast open. > > This general concept is relatively simple in comparison to doing somethin= g mid-connection. Instead of attempting to renegotiate on an existing conne= ction, just make creation of resumed connections cheap enough to start over= with client auth in the handshake from the start. > > It's a very rough idea, but I'm wondering if it sounds like something wor= th discussing. > > > Dave > > _______________________________________________ > 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 Aug 11 11:25:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E001AD06F for ; Tue, 11 Aug 2015 11:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHl3zf39i0Qj for ; Tue, 11 Aug 2015 11:25:47 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724D91AD06E for ; Tue, 11 Aug 2015 11:25:47 -0700 (PDT) Received: by qkfj126 with SMTP id j126so20867131qkf.0 for ; Tue, 11 Aug 2015 11:25:46 -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=AhoWC2c4sBryWfWLKUkE8sUA90Ic6s3hvKa51rT0t6A=; b=R1C2SVb+UAiH8OQ6UaQVVvB2kM91JgNh//ATD+Ylz6Hr6Xh0/RkHIvxYDWOeYwpYG3 o16acKmSl5EjY5O3Ets3ziYiSDvG/s8VittagzjRr7xq/zCCRl7g3dvl50NKmS23yTCI egr74EItq+YORy3wskm0f+OMnLq5KE7jCAfJj0keWWkkmJ83N7V8HcguA7ht2fLrG6r3 kTS683cRPuiByG/zqzDLYRXfzJArKbISwUBNHdwBN3b9IqHDHf7/O3YT+ffrb3PA0Bhh RxlSGHPuEpuklHFVmaGdNP8Le9irOQHUBoGXaGrf8myo1HlKHBropFuebADou1R54VBK H1HA== X-Received: by 10.55.31.225 with SMTP id n94mr51703924qkh.17.1439317546766; Tue, 11 Aug 2015 11:25:46 -0700 (PDT) Received: from [10.59.3.68] ([65.205.30.226]) by smtp.gmail.com with ESMTPSA id f101sm1666993qkf.22.2015.08.11.11.25.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Aug 2015 11:25:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 11 Aug 2015 14:25:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Clemens Hlauschek , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 18:25:49 -0000 >> = https://www.usenix.org/conference/woot15/workshop-program/presentation/hla= uschek >=20 > Some comments on this, it looks like it requires a "cert with static = (EC)DH > key" in order to work, which would mean an X9.42 cert. Since no = (public) CA > that I know of can handle or issue such certs, this probably provides = a > reasonable amount of defence against this attack=E2=80=A6 No, a regular ECDSA certificate would do. That is, the attack would work as long as=20 - a client has an ECDSA certificate, and - it enables any static TLS_ECDH_* cipher suite, and - its ECDSA private key has been stolen (or chosen) by an attacker. Best, Karthik >=20 > In terms of the suggested countermeasures: >=20 >> Set appropriate X509 Key Usage extension for ECDSA and DSS = certificates, and >> disable specifically the KeyAgreement flag >=20 > Since the keyUsage flags are widely ignored by implementations, this = won't > provide the protection that the text implies. >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Aug 11 11:29:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3121ACEA2 for ; Tue, 11 Aug 2015 11:29: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 Rxp0qGbDRMkc for ; Tue, 11 Aug 2015 11:29:15 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012B41ACD5B for ; Tue, 11 Aug 2015 11:29:14 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so34848086lbb.0 for ; Tue, 11 Aug 2015 11:29: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=h0+p3rFeQ1zp07B4rmpeJp6usjJcrVOvOMAeuBnTWMM=; b=Sglq3pDIlEy21a4kaMto8NsNxTLDXaIL3k+0NzTcSH9NlPN6F8tgyBYxhhnytS3m08 LwwZi8fOu30jLdVDsKnxKF+4lSeZcR8a1GIaMWvJt6hb6xYVvvBHvZhH16l3C341g7Y0 EqwANKUifWlwekoonWexqusmp1rlDa1A1wLOXINbSvUcmajwQqMtmeu+jVYko89ekmrr jbheobWEK66Fj6M8vZcYzmp/kE1N3XCJFwIs8VCx72VOgrsyf9Z7GPe+/hj2tGKOH2cO fOTRUS9O5OfF0wmXWxKj5vR+0Q2K82nvoZSAImZp/dO0/A+fYnvhiKf3Zx+5NN1fTe/t drhw== MIME-Version: 1.0 X-Received: by 10.112.42.172 with SMTP id p12mr27636943lbl.52.1439317752387; Tue, 11 Aug 2015 11:29:12 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 11:29:12 -0700 (PDT) In-Reply-To: <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> Date: Tue, 11 Aug 2015 11:29:12 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Clemens Hlauschek , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 18:29:16 -0000 On 11 August 2015 at 11:25, Karthikeyan Bhargavan wrote: > No, a regular ECDSA certificate would do. > That is, the attack would work as long as > - a client has an ECDSA certificate, and > - it enables any static TLS_ECDH_* cipher suite, and > - its ECDSA private key has been stolen (or chosen) by an attacker. I don't see how that would work. A client that understands the cert to be ECDSA won't pair the key with the server's ECDH share, they will sign the session transcript with it. From nobody Tue Aug 11 12:05:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D51AD10A for ; Tue, 11 Aug 2015 12:05:50 -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 QfPTCpwxViAx for ; Tue, 11 Aug 2015 12:05:49 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23131AD0EA for ; Tue, 11 Aug 2015 12:05:47 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 8FADB900D4; Tue, 11 Aug 2015 22:05:44 +0300 (EEST) Date: Tue, 11 Aug 2015 22:05:44 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150811190544.GA13734@LK-Perkele-VII> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> 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: Cc: Karthikeyan Bhargavan , Clemens Hlauschek , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 19:05:51 -0000 On Tue, Aug 11, 2015 at 11:29:12AM -0700, Martin Thomson wrote: > On 11 August 2015 at 11:25, Karthikeyan Bhargavan > wrote: > > No, a regular ECDSA certificate would do. > > That is, the attack would work as long as > > - a client has an ECDSA certificate, and > > - it enables any static TLS_ECDH_* cipher suite, and > > - its ECDSA private key has been stolen (or chosen) by an attacker. > > I don't see how that would work. A client that understands the cert > to be ECDSA won't pair the key with the server's ECDH share, they will > sign the session transcript with it. a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no ECDSA-specific keytype in X.509. b) SSL v3.0 server PoP (still there in TLS v1.2) does not sign transcript but only the public key (only TLS 1.3 fixes this). Logjam, anyone? c) Non-signature client certs (like ECDH) don't have transcript signatures either. Attacker can just replay randoms and SKE, and then compute client- side PMS. Game Over, EMS will not save you. -Ilari From nobody Tue Aug 11 14:06:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC71B2AB0 for ; Tue, 11 Aug 2015 14:06: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 OGeKMxY-R8Xr for ; Tue, 11 Aug 2015 14:06:34 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57E71B2AAE for ; Tue, 11 Aug 2015 14:06:33 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so26163387lbc.2 for ; Tue, 11 Aug 2015 14:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o6C1K1UHmcxFOAAp3S8eb+8BJcIkUtd/aGcHu2Eismo=; b=B1Yk7P65mCQfTPYphdUbla452397Vcbukvu+3uE1xu8IxEveRPqzTPNsYnGgKTYU1v faZX56hDx7nc2ZD/aZSJIiMqADjM4sxhjUcJ6/yQR/XK216YIAQ2Hs2ae26+WCzfmJnk 3vEHDnrz3EqmFW1jTABQhUYDYV0UUjrz4I5ZohltrCy7Oyks/UsL+I1JvsUKZQdaupyz bcfP5IDqRDPCZ2ZFyeD7HvW5nU4vXfk+0gqBN0Oqa1BeL3pWk69JnPlb7We0XcB3kpr4 ZFt9p8n3B5Rpi517cMJhMq/HIVhpl7iLd5qtZvagx4t+p9wau+lc5b9GkiW9nUQh6fs7 HUrg== MIME-Version: 1.0 X-Received: by 10.152.7.37 with SMTP id g5mr28997606laa.101.1439327192008; Tue, 11 Aug 2015 14:06:32 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 14:06:31 -0700 (PDT) In-Reply-To: <20150811190544.GA13734@LK-Perkele-VII> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <20150811190544.GA13734@LK-Perkele-VII> Date: Tue, 11 Aug 2015 14:06:31 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , Clemens Hlauschek , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 21:06:35 -0000 On 11 August 2015 at 12:05, Ilari Liusvaara wrote: >> I don't see how that would work. A client that understands the cert >> to be ECDSA won't pair the key with the server's ECDH share, they will >> sign the session transcript with it. > > a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is > no ECDSA-specific keytype in X.509. Maybe I should have been clearer. The certificate might not include a (strong) signal that allows the client to distinguish between ECDSA and fixed ECDH, but the client might be configured with that knowledge. I checked NSS and there doesn't seem to be any way that it could be coerced into using the (EC)DH pair from a client certificate in a key exchange. Even though it supports some fixed (EC)DH suites. NSS (incorrectly) adopts the posture that _ECDH_ suites are half-static: the server share is in the certificate, but the client side is fully ephemeral. This is clearly in violation of RFC 5246, Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about that right now :) From nobody Tue Aug 11 16:38:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EA91A00F9 for ; Tue, 11 Aug 2015 16:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajr3mSM1FkZD for ; Tue, 11 Aug 2015 16:38:49 -0700 (PDT) Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC68F1A00C3 for ; Tue, 11 Aug 2015 16:38:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id 44FE440E43C; Wed, 12 Aug 2015 01:38:48 +0200 (CEST) Received: from [192.168.43.233] (unknown [172.56.2.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id 61E8C40E431; Wed, 12 Aug 2015 01:38:46 +0200 (CEST) Message-ID: <55CA8783.8060201@rise-world.com> Date: Tue, 11 Aug 2015 19:38:43 -0400 From: Clemens Hlauschek User-Agent: mutt 1.5.23 (Plan 9) MIME-Version: 1.0 To: Martin Thomson , Ilari Liusvaara References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <20150811190544.GA13734@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 23:38:51 -0000 On 08/11/2015 05:06 PM, Martin Thomson wrote: > On 11 August 2015 at 12:05, Ilari Liusvaara wrote: >>> I don't see how that would work. A client that understands the cert >>> to be ECDSA won't pair the key with the server's ECDH share, they will >>> sign the session transcript with it. >> >> a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is >> no ECDSA-specific keytype in X.509. > > Maybe I should have been clearer. The certificate might not include a > (strong) signal that allows the client to distinguish between ECDSA > and fixed ECDH, but the client might be configured with that > knowledge. There is no difference between an ECDH and an ECDSA, apart from (possibly) the KeyUsage Extension. > > I checked NSS and there doesn't seem to be any way that it could be > coerced into using the (EC)DH pair from a client certificate in a key > exchange. Even though it supports some fixed (EC)DH suites. To the best of our knowledge, NSS does not support fixed ECDH client authentication. I checked the code manually. Prof Matt Green also verified with EKR at Mozilla during the pre-public disclosure phase that NSS is not vulnerable. > > NSS (incorrectly) adopts the posture that _ECDH_ suites are > half-static: the server share is in the certificate, but the client > side is fully ephemeral. This is clearly in violation of RFC 5246, > Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about > that right now :) > Please elaborate. I do not see how this half-static behaviour constitutes any violations of the mentioned RFCs. I would say half-static ECDH handshake is not only fully spec conforming, but *the* way to do an ECDH handshake when client authentication (*_fixed_(ec)dh) is not requested by the server. OpenSSL, as well as other implementations, do the same. Clemens From nobody Tue Aug 11 16:59:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B261A01A8 for ; Tue, 11 Aug 2015 16:59: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 DjeikaDumRnm for ; Tue, 11 Aug 2015 16:59:37 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFA11A0120 for ; Tue, 11 Aug 2015 16:59:37 -0700 (PDT) Received: by lahi9 with SMTP id i9so563135lah.2 for ; Tue, 11 Aug 2015 16:59: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=OmoMWActkM0vV2KlgYjgtxbGf1hgf9gA7WeldD4YhG8=; b=DYv/iP2flGws8l9OB0j6CnmKbgC5YUQEzpn+ha1eCkd2V8q5BjOd5jWm7bDuPAV/TI wLTGiKlJXJ+j8mGAxLaij2NId1gsr07hRHYdY7bXabIy5zr3nQqcIU+iKScDHeM7kFI7 INbvdUnp/7x+skPK0eY5mZ8G6AhTUjlm42B05iHitfvCMIFlzt4Y3D2Lnd8tQwm0Yi+i WN1+jysauYKk4SRi+KnmZlChnjv+e8PvjH9eTt8RSLeDdU/4jLqcEnGjUSDHUJgr9rs+ d5+Z3VuWikI7Z8vonGia/vqYUHAFFUnbU43CJlhuhtXjdTtnjYooL9ZJ9CvEDWUSl7G5 iIgQ== MIME-Version: 1.0 X-Received: by 10.112.24.163 with SMTP id v3mr25107682lbf.101.1439337575413; Tue, 11 Aug 2015 16:59:35 -0700 (PDT) Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 16:59:35 -0700 (PDT) In-Reply-To: <55CA8783.8060201@rise-world.com> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <20150811190544.GA13734@LK-Perkele-VII> <55CA8783.8060201@rise-world.com> Date: Tue, 11 Aug 2015 16:59:35 -0700 Message-ID: From: Martin Thomson To: Clemens Hlauschek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 23:59:38 -0000 On 11 August 2015 at 16:38, Clemens Hlauschek wrote: >> Maybe I should have been clearer. The certificate might not include a >> (strong) signal that allows the client to distinguish between ECDSA >> and fixed ECDH, but the client might be configured with that >> knowledge. > > There is no difference between an ECDH and an ECDSA, apart from > (possibly) the KeyUsage Extension. I'l try again. Even if the certificate does not include that signal, the software that accepts that signal might make assumptions or have configuration that cause it to only be used in one way or another. See NSS. >> NSS (incorrectly) adopts the posture that _ECDH_ suites are >> half-static: the server share is in the certificate, but the client >> side is fully ephemeral. This is clearly in violation of RFC 5246, >> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >> that right now :) > > Please elaborate. I do not see how this half-static behaviour > constitutes any violations of the mentioned RFCs. Both the above cited sections say very clearly that for fixed (EC)DH cipher suites the client where the client has a fixed (EC)DH certificate, the client MUST send an empty ClientKeyExchange. Of course, you might say that this is simply a consequence of not supporting fixed (EC)DH for client authentication, and then it's not technically in violation. The value of the ClientCertificateType from the CertificateRequest is likely important here, but that field is systematically ignored in practice (NSS ignores it). From nobody Tue Aug 11 17:19:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B81A03E1 for ; Tue, 11 Aug 2015 17:19:44 -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 MQ6YthwuXJ_N for ; Tue, 11 Aug 2015 17:19:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2013C1A03A6 for ; Tue, 11 Aug 2015 17:19:43 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id D86C7F984; Tue, 11 Aug 2015 20:19:40 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CFADE201D4; Wed, 12 Aug 2015 02:19:30 +0200 (CEST) From: Daniel Kahn Gillmor To: Martin Thomson , Clemens Hlauschek In-Reply-To: References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <20150811190544.GA13734@LK-Perkele-VII> <55CA8783.8060201@rise-world.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 11 Aug 2015 20:19:30 -0400 Message-ID: <874mk5nyst.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:19:44 -0000 On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote: > On 11 August 2015 at 16:38, Clemens Hlauschek wrote: [ MT wrote: ] >>> NSS (incorrectly) adopts the posture that _ECDH_ suites are >>> half-static: the server share is in the certificate, but the client >>> side is fully ephemeral. This is clearly in violation of RFC 5246, >>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >>> that right now :) >> >> Please elaborate. I do not see how this half-static behaviour >> constitutes any violations of the mentioned RFCs. > > Both the above cited sections say very clearly that for fixed (EC)DH > cipher suites the client where the client has a fixed (EC)DH > certificate, the client MUST send an empty ClientKeyExchange. that's not how i'm reading 5246 §7.4.7 -- i see it as saying if the client has decided to send a fixed (EC)DH cert, then it MUST send an empty ClientKey Exchange. I see no requirement that a client MUST send a certificate if it has one that satisfies the server's CertificateRequest (and i would be strongly opposed to adding such a requirement -- clients should not be forced to reveal identity to a server just because of CertificateRequest message in the handshake). so i think NSS is doing the Right Thing here too. --dkg From nobody Tue Aug 11 17:25:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AAA1A0A85 for ; Tue, 11 Aug 2015 17:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UV1pj3BPKT3R for ; Tue, 11 Aug 2015 17:25:18 -0700 (PDT) Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C391A070E for ; Tue, 11 Aug 2015 17:25:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id 1254040E431; Wed, 12 Aug 2015 02:25:16 +0200 (CEST) Received: from [192.168.43.233] (unknown [172.56.2.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id 3234240E062; Wed, 12 Aug 2015 02:25:13 +0200 (CEST) Message-ID: <55CA9264.7040606@rise-world.com> Date: Tue, 11 Aug 2015 20:25:08 -0400 From: Clemens Hlauschek User-Agent: mutt 1.5.23 (Plan 9) MIME-Version: 1.0 To: Martin Thomson References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <20150811190544.GA13734@LK-Perkele-VII> <55CA8783.8060201@rise-world.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:25:20 -0000 On 08/11/2015 07:59 PM, Martin Thomson wrote: > On 11 August 2015 at 16:38, Clemens Hlauschek > wrote: >>> Maybe I should have been clearer. The certificate might not include a >>> (strong) signal that allows the client to distinguish between ECDSA >>> and fixed ECDH, but the client might be configured with that >>> knowledge. >> >> There is no difference between an ECDH and an ECDSA, apart from >> (possibly) the KeyUsage Extension. > > I'l try again. Even if the certificate does not include that signal, > the software that accepts that signal might make assumptions or have > configuration that cause it to only be used in one way or another. > See NSS. NSS does not support rsa_fixed_ecdh ecdsa_fixed_ecdh rsa_fixed_dh dh_fixed_dh, although it supports ECDH_ECDSA and ECDH_RSA (if I remember correctly) so your point is moot. Anyway, the only client implementations we found that were actually vulnerable to the attack (Safari/Mac OS X -- supporting (EC)DH_* key exchange and *fixed_(ec)dh client authentication) did not make these assumption you are talking about, and I can not see why they should. We are currently working on a video showcasing an actual attack (Safari -- Facebook). > >>> NSS (incorrectly) adopts the posture that _ECDH_ suites are >>> half-static: the server share is in the certificate, but the client >>> side is fully ephemeral. This is clearly in violation of RFC 5246, >>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >>> that right now :) >> >> Please elaborate. I do not see how this half-static behaviour >> constitutes any violations of the mentioned RFCs. > > Both the above cited sections say very clearly that for fixed (EC)DH > cipher suites the client where the client has a fixed (EC)DH > certificate, the client MUST send an empty ClientKeyExchange. Yes, that is correct. But for fixed (EC)DH client authentication. > > Of course, you might say that this is simply a consequence of not > supporting fixed (EC)DH for client authentication, and then it's not > technically in violation. The value of the ClientCertificateType from > the CertificateRequest is likely important here, but that field is > systematically ignored in practice (NSS ignores it). I could find nowhere in the spec that a (non-ephemeral) (EC)DH key agreement necessary implies fixed (EC)DH client authentication to be used. The other direction (fixed (EC)DH client authentication requires a (EC)DH key agreement, is insinuated by the spec, but still left ambiguous (a conclusion I came to after discussing exactly that with the OpenSSL developers). Regards, Clemens From nobody Tue Aug 11 17:39:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079141A1A3B for ; Tue, 11 Aug 2015 17:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuy4cR9xxrxQ for ; Tue, 11 Aug 2015 17:38:59 -0700 (PDT) Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BFA1A1A33 for ; Tue, 11 Aug 2015 17:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id D955840E431; Wed, 12 Aug 2015 02:38:57 +0200 (CEST) Received: from [192.168.43.233] (unknown [172.56.2.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id 66DF740E062 for ; Wed, 12 Aug 2015 02:38:56 +0200 (CEST) Message-ID: <55CA959C.6020806@rise-world.com> Date: Tue, 11 Aug 2015 20:38:52 -0400 From: Clemens Hlauschek User-Agent: mutt 1.5.23 (Plan 9) MIME-Version: 1.0 To: "tls@ietf.org" References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:39:01 -0000 On 08/11/2015 02:05 PM, Peter Gutmann wrote: > Clemens Hlauschek writes: > >> I published a paper today on KCI-attacks in TLS. This might be of interest to >> the TLS WG. >> >> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek > > Some comments on this, it looks like it requires a "cert with static (EC)DH > key" in order to work, which would mean an X9.42 cert. Since no (public) CA > that I know of can handle or issue such certs, this probably provides a > reasonable amount of defence against this attack... Thanks for the critical reading. Actually, your point is touched upon in the paper. Instead of an ECDH certificate, an ECDSA certificate can be used by the attacker. The case for DH/DSS is different, and your point is valid for this latter case. I am working on a video showcasing the attack (Safari <-> Facebook), but if you decide that you still would not trust our claims made in the paper, it would be trivial to reproduce the attack: our MitM proof-of-concept implementation was realized with less than 10 patched lines of the openssl/stunnel codebase. See also RFC 4492: "Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations" > > In terms of the suggested countermeasures: > >> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and >> disable specifically the KeyAgreement flag > > Since the keyUsage flags are widely ignored by implementations, this won't > provide the protection that the text implies. > In case of the vulnerable Safari / SecureTransport / Mac OS X clients, it does make a difference, so having correct X509 KeyUsage settings is the best (and only sensible for servers supporting ECDSA) recommendation for server-side mitigation, from our perspective. The facebook.com security teams very quickly implemented that change. While it is certainly true that keyUsage flags are ignored by many implementations (this is also mentioned in the paper), checking (it is ambiguous according to the TLS specs whether it is mandatory for ECDH, but it is mandatory for DH if the KeyUsage extension is present) seems to have become more widespread recently. Best, Clemens From nobody Tue Aug 11 18:50:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B371A1BE7 for ; Tue, 11 Aug 2015 18:50:30 -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 bLf9SavuFHoZ for ; Tue, 11 Aug 2015 18:50:26 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E3B1A1BE6 for ; Tue, 11 Aug 2015 18:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439344226; x=1470880226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i6z5Hq3AYHjCl7v8g8kdIT4oDHlKRU6bAP023keeqZ4=; b=tN/owL5o8dC8OIVnzb7iLHx4oxe0It6DFT4L05vKly0kpclunWsGHeyT JK0ZaF5VlLsI3+rHCBbxUDHAUKFxlbXlGs0yeKWPbpdO8ZlvSj98XJoVG WJ+98Autd/Q/oaLmPVkGv0N1+UFs4zts9a6gqhXzsxouDdPJIyVtc/VR7 aY1oR66gZHIQ1rrnmHJN89wkYeWsJDRuoZpSi/Q9jtRNgxGr6vzfVox2Z jD2/SuAxnUMp9kHzvfYHRlswCR9mXZYCMsZf0IxZRY4wzPgvV01x7u1eG RBoLXQQCUt10reDUkEtPYKggoilLZGv3hnNZ6qqOhpnHdWeJmm7VLfqwk w==; X-IronPort-AV: E=Sophos;i="5.15,657,1432555200"; d="scan'208";a="34532295" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Aug 2015 13:50:24 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Wed, 12 Aug 2015 13:50:23 +1200 From: Peter Gutmann To: Ilari Liusvaara , Martin Thomson Thread-Topic: [TLS] TLS and KCI vulnerable handshakes Thread-Index: AQHQ1F5LrI8QBmnw8E6Q+G9ikduiz54HF7RI//88pwCAAAD7AIAACjUAgAE6A7A= Date: Wed, 12 Aug 2015 01:50:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AD858F@uxcn10-5.UoA.auckland.ac.nz> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> , <20150811190544.GA13734@LK-Perkele-VII> In-Reply-To: <20150811190544.GA13734@LK-Perkele-VII> 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: Cc: Karthikeyan Bhargavan , Clemens Hlauschek , "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 01:50:31 -0000 Ilari Liusvaara writes:=0A= =0A= >a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is no= =0A= >ECDSA-specific keytype in X.509.=0A= =0A= That's always concerned me about ECC certs, all you can say about a key is= =0A= "ECC", not "signing key" or "key agreement key" (I'm sure this was seen as = a=0A= great feature when the key format was designed, "ECC is so much more flexib= le=0A= than RSA, you can use it for anything!"). My code explicitly ACLs ECC keys= =0A= coming from certs to be signing-only in order to deal with this problem.=0A= =0A= Peter.= From nobody Wed Aug 12 14:26:30 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CF1ACE0B for ; Wed, 12 Aug 2015 14:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3kD3sLf4h_EQ for ; Wed, 12 Aug 2015 14:26:26 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA841ACE08 for ; Wed, 12 Aug 2015 14:26:25 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t7CLQ151018292 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Aug 2015 23:26:02 +0200 From: Simon Josefsson To: Ilari Liusvaara References: <20150807053956.GA5394@LK-Perkele-VII> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150812:tls@ietf.org::aYgCInCKhRC9llyE:3SHi X-Hashcash: 1:22:150812:ilari.liusvaara@elisanet.fi::521OvvIwO30l6OT/:5YtN Date: Wed, 12 Aug 2015 23:26:00 +0200 In-Reply-To: <20150807053956.GA5394@LK-Perkele-VII> (Ilari Liusvaara's message of "Fri, 7 Aug 2015 08:39:56 +0300") Message-ID: <8737zob3mf.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Adding a new signature scheme X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:26:28 -0000 --=-=-= Content-Type: text/plain Ilari Liusvaara writes: > This is about adding a new signature primitive (such as the > (eventual) CFRG scheme). I believe these aspects were already discussed in the EdDSA threads. It would be useful to establish consensus around these topics. > There are basically two issues: > > 1) Do we allocate new ciphersuite codepoints or not? So far > each certificate algorithm in ciphersuite has corresponded > to only one signature algorithm. > > Implications of new codepoints: > - More ciphersuites (about 11). > - Needs TLS 1.2+ anyway, because the ciphers are presumably > AEAD mode and those need TLS 1.2+. > - Keep existing semantics. > > Implication of reusing ECDSA codepoints. > - No new ciphersuites > - Needs TLS 1.2+ > - Redefines existing semantics a bit. The feedback I got on draft-josefsson-tls-eddsa from several people was to reuse the ECDSA codepoints instead of defining new ciphersuites. I am currently (mildly) in favor of that, as it appears to imply less work for everyone. I have since published draft-josefsson-tls-eddsa2 that adopts that approach. I decided to fork the draft so both are available and can be evaluated on its own. They are available here: https://tools.ietf.org/html/draft-josefsson-tls-eddsa https://tools.ietf.org/html/draft-josefsson-tls-eddsa2 > 2) What does the SignatureAndHashAlgorithm.hash mean exactly? The > TLS 1.2 RFC isn't specific enough. I believe the document introducing a new signature primitive must be clear about this. I don't believe TLS 1.2 mandates any particular interpretation here, so it is up to the new primitive to define semantics. I believe the choice is not particular interesting, as long as the specification is clear about what is intended. For example, draft-josefsson-tls-eddsa uses "none", and draft-josefsson-tls-eddsa2 uses "sha512", and both are in their own way a bit redundant. > I see two choices: > a) The field sets hash (prehash) to perform before passing the > hash to be signed (the description of "none" and description of > Certificate Verify message hints at this interpretation). > b) The field parameterizes the signature scheme in some scheme- > specific way (but what would "none" mean in context of this, > the scheme having no hash parameters?). > > All the existing schemes are compatible with interpratation a). > > But for proposals for CFRG scheme: All proposed schemes have a > hash parameter (the only one or one of two) that is incompatible > with interpretation a): > > 1) Only one hash that does not prehash the message. > 2) Two hash functions, one prehash (can be identity) and > one internal hash. Prehash can be chosen per-signature. > 3) Two hash functions, one prehash (can be identity) and > one internal hash. Prehash is not indicated, so one > has to be careful changing it. > > So if interpretation a) is the correct one, one presumably has to > fix the internal hash in signature scheme codepoint (E.g. to > SHA-512 for signature scheme #4). I don't think we can come any closer to my discussion above until we know what the CFRG outcome is. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVy7noAAoJEIYLf7sy+BGdZA4H/1BueJqwuEeHFGpGXIvs2/nl fjpbEvjL9o1QiByDLpd6QQuLltEE4h84gDFfzQOIp1JkTbIRrspwCQANI6p1wbtX CMHlUQIEVSA1kiSCxoikIbN4jMP9Azj36y9HVMOOp38zHLcy4VP1ObHwbnIwqiUz HnpCPgU24hVKzLDNIb8kVuRVjpXPuFpVoUAHGQApuHT3+Yac4RD1xVV18cgDu2ci pefEAHXLnBhnOSQBI02t5XfaWKHt+4J4lg+EvS4LImPgZ5gBl5k6odaugG1Bi0X2 IjY4MYhNzHPNTt8AvyFbvZKaqqdnUn7tULnwQ/0k/s3MwznmYYFYEVcAQLzP4/I= =c2w4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 17 03:22:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD81A9034 for ; Mon, 17 Aug 2015 03:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 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, MIME_HTML_ONLY=0.723, 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 a2Y0IPf7r7Dh for ; Mon, 17 Aug 2015 03:22:07 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52481A9031 for ; Mon, 17 Aug 2015 03:22:06 -0700 (PDT) Received: by qged69 with SMTP id d69so89842246qge.0 for ; Mon, 17 Aug 2015 03:22:06 -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 :content-type:content-transfer-encoding; bh=hl7oUZh0qtFW1ZHC/BTFczljUm9f+GbXz87hbaMM5PE=; b=kaI5q5/SM4UgNfDixbX9xo44AO1UvhUQoNKlsE3CsLNkc2I6ZFXvwgwDKAWBSGFnEs 4FfDgRaQG56Vv0bGRJbM7XFneSQrsgHpT630pMK4fZgkh2fGcY//w3C9q4NqGBGFdWvN YCBlcrt/g90Fb5gFxHvdqGCJfRMWWCcW2BgH7D174Fsz4/xWfLYKF06IeSeeaG3t+wRv yD+JPcN4Nw9fzagsQ6w+l7o8ubUSGQygRZyAaqIRYyVaSUHYnSHiZC5x8xdlkepsDTSc FHSU1mqdyEfdTErmWAo5/j7W5anCFimJ9jB0YzeJzbUeGL6oOLKE0GTbq2t+TwSbx+Hz /a0g== X-Received: by 10.140.237.70 with SMTP id i67mr1083886qhc.48.1439806926137; Mon, 17 Aug 2015 03:22:06 -0700 (PDT) Received: from [10.71.63.158] ([12.172.251.105]) by smtp.googlemail.com with ESMTPSA id k89sm7986337qgk.36.2015.08.17.03.22.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 03:22:05 -0700 (PDT) Message-ID: <55D1B5CC.1050005@gmail.com> Date: Mon, 17 Aug 2015 06:22:04 -0400 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 10:22:08 -0000 Below a long list of comments, generally minor. The document is already very good - we're making great progress!
  • The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes".
  • 6: the definition of session contents should also contain identities. The client's identity, if authenticated by cert, or the peers' PSK identity.
  • "Access denied" alert: the description starts with "a valid certificate was received", but it may also apply to PSK.
  • Handshake_failure alert seems to be synonymous with insufficient_security (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate one of them?
  • Typo: "via a certificates".
  • Server Configuration: how does the client know to whom the configuration applies? For example if I connected to "*.example.com" (a wildcard cert) and now I connect to "srv.example.com", should I use the stored configuration?
  • 6.2.2: typo: has complete.
  • 6.3.2.3.2: it's time we specified that the recipient (in this case, the server) MUST verify the received ECDHE public key (see RFC 6989). This is mentioned in Appendix D but only for modular DH.
  • 6.3.2.4: "identifier" should read "identity".
  • 6.3.4: "Perhaps have a whitelist of which extensions can be unencrypted and everything else MUST be encrypted." - this doesn't work, because we might come up in the future with an extension that needs to be unprotected. Maybe we can say "SHOULD" instead.
  • 6.3.7: expiration_date: there's no reason to force/assume time synchronization between client and server. This can just as well be relative time (number of seconds since negotiation), like ticket_lifetime_hint.
  • 6.3.10: "If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication ... Also, if some aspect of the certificate chain was unacceptable ... the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or send a fatal alert." This is strange. There is no way for the client to understand that the server considers it unauthenticated and modify its behavior accordingly. A warning alert would be appropriate here, even if in general we don't like warning alerts.
  • Typo: main-in-the-middle
  • "Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. " This is not precisely true, because the other peer may not know that you're not verifying the exchange, and so it might behave differently.
  • D.1.2: do we really need to worry about version rollback to SSLv2? I suggest to remove this section.
Thanks,
    Yaron
From nobody Mon Aug 17 05:02:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57DF1B2CFB for ; Mon, 17 Aug 2015 05:02:52 -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 j6Px69BpYY-c for ; Mon, 17 Aug 2015 05:02:49 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747421B2CF8 for ; Mon, 17 Aug 2015 05:02:49 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 0D1D6901A0; Mon, 17 Aug 2015 15:02:46 +0300 (EEST) Date: Mon, 17 Aug 2015 15:02:46 +0300 From: Ilari Liusvaara To: Yaron Sheffer Message-ID: <20150817120246.GA32255@LK-Perkele-VII> References: <55D1B5CC.1050005@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55D1B5CC.1050005@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 12:02:52 -0000 On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote: > > Below a long list of comments, generally minor. The document is > already very good - we're making great progress!
> The record length field is limited by encrypted-length+2048. > Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an > expansion of greater than 1024 bytes". Actually, I think both should be 256 (256-byte expansion from AEAD is already quite much). (This was proposed a while back). > 6: the definition of session contents should also contain > identities. The client's identity, if authenticated by cert, or > the peers' PSK identity. There is lots more missing as well, like symmetric crypto keys, TLS-Exporter secret and TLS-Unique value. IIRC the answer when I brought that up was that the whole thing should be removed. > "Access denied" alert: the description starts with "a valid > certificate was received", but it may also apply to PSK. Agreed. Authorization failure. > Handshake_failure alert seems to be synonymous with > insufficient_security (and Sec. 6.2.1 proves it...). Can we > clarify the difference, or deprecate one of them? >From my reading, the difference would be that if some negotiating some required algorithm failed because none of the options is supported at all, it is handshake_failure. If some algorithms would have been supported but are disabled, it is insufficient_security. Not sure if that makes any actual sense. > Server Configuration: how does the client know to whom the > configuration applies? For example if I connected to > "*.example.com" (a wildcard cert) and now I connect to > "srv.example.com", should I use the stored configuration? It actually gets more interesting when one has multiple potentially applicable configurations and needs to tiebreak. If there is only one config known, not much problem in trying that. > 6.3.2.3.2: it's time we specified that the recipient (in this > case, the server) MUST verify the received ECDHE public key (see > RFC 6989). This is mentioned in Appendix D but only for modular > DH. There is actually two kinds of verification: - Validating received point is on curve. - Validating that the received point is high-order. CFRG Curve25519 and Curve448 specify the needed checks here. As for Weierstrass stuff, some ECC libs have surprising presentations for infinity (which is order-1) and allow importing invalid points, so one has to be careful even with h=1. > 6.3.4: "Perhaps have a whitelist of which extensions can be > unencrypted and everything else MUST be encrypted." - this > doesn't work, because we might come up in the future with an > extension that needs to be unprotected. Maybe we can say > "SHOULD" instead. The registration procedure is "IETF consensus", so RFC updates: might not work. Also, it is unclear if extensions that introduce new messages or otherwise modify the handshake after EncrpytedExtensions are to be in ServerHello or EncryptedExtensions. > 6.3.7: expiration_date: there's no reason to force/assume time > synchronization between client and server. This can just as well > be relative time (number of seconds since negotiation), like > ticket_lifetime_hint. IIRC, the reason why it was that was was publishing configurations off-band. Also, I don't like that field being 32-bit if it is absolute time (even if it isn't signed). > D.1.2: do we really need to worry about version rollback to > SSLv2? I suggest to remove this section. Well, it is not possible to even try to negotiate TLS 1.3 using SSLv2 compat. hello, since that can't transmit extensions, but at least one extension is REQUIRED in order to successfully negotiate TLS 1.3. And the second paragraph seems to be about RSA key exchange, which isn't supported anymore in TLS 1.3. Yes, the section looks like it could be removed. But that isn't the only way rollback attacks can occur, also some clients can be coaxed to downgrade by selectively blocking connections. Unfortunately the intolerance to TLS 1.3 is so bad that many clients will likely be willing to perform unauthenticated downgrade to TLS 1.2 (and FALLBACK_SCSV is useless here). -Ilari From nobody Mon Aug 17 05:39:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A166B1B2D46 for ; Mon, 17 Aug 2015 05:39:00 -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 3c1hKm4kiWWO for ; Mon, 17 Aug 2015 05:38:58 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FE81A8034 for ; Mon, 17 Aug 2015 05:38: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=mail; t=1439815138; x=1471351138; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Vtq4k1k5fDfRjHfeuoI1QomO1tcT17JrVvjiQp7M29I=; b=qv3tJjkADtjvCHdLylfEBs4LJ8LPDAeq3AOzmR4PtEufMsADSJQkDDLY 1vjjEUoR/YBArCF2beTSGdSzHG1WkuXzv9mVtc3Agrxpk11itpeeluDz7 WYQ5FyHH5rblvY/FXRjmmn2gLmcGE9d8vpcLZRM/C4gfZzRrANV4rw4yU POywXVvx7h3/0tu13A0j1bWh9rwIsI7Jjabof5J9U8bsTVh+8ytJBYzb0 NCjJkr8knDI6nD/Tvaqiihf6kNw5wUqncQv89IxCPSLFiwqy/vTYek+ND xly97EgRPpbKlr0CVAbpordA8G7ahWHWMWoaqCVpX6nAq8Elny08A696l g==; X-IronPort-AV: E=Sophos;i="5.15,694,1432555200"; d="scan'208";a="35685840" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Aug 2015 00:38:55 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 18 Aug 2015 00:38:55 +1200 From: Peter Gutmann To: Clemens Hlauschek , "tls@ietf.org" Thread-Topic: [TLS] TLS and KCI vulnerable handshakes Thread-Index: AQHQ1F5LrI8QBmnw8E6Q+G9ikduiz54HF7RI//+NqoCACYRrog== Date: Mon, 17 Aug 2015 12:38:54 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz>, <55CA821B.9090101@rise-world.com> In-Reply-To: <55CA821B.9090101@rise-world.com> 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: Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 12:39:00 -0000 So apart from being an interesting paper, it also points out (yet again) th= at=0A= TLS has waaaay too many baggage suites and mechanisms that provide nothing = but=0A= an attack vector (it's not unique in this regard, other protocols also carr= y=0A= around a vast amount of baggage and unnecessary flexibility whose only=0A= apparent use is attack vectors, because certainly no implementation seems t= o=0A= be using it. SSH springs immediately to mind, TLS has all the baggage suit= es=0A= and SSH has the unnecessary flexibility).=0A= =0A= One thing that I'd really like to know is that given the non-PFS (EC)DH sui= tes=0A= were obviously a dumb idea and barely supported by anything (not just in te= rms=0A= of TLS code, no public CA I know of will issue the required X9.42 certs,=0A= although as the paper points out you can get ECDH ones that can be misused)= ,=0A= why did OpenSSL add support for them as late as 1.0.2? Does anyone know wh= y=0A= they were added?=0A= =0A= Peter.=0A= =0A= ________________________________________=0A= From: Clemens Hlauschek [clemens.hlauschek@rise-world.com]=0A= Sent: Wednesday, 12 August 2015 11:15=0A= To: Peter Gutmann; tls@ietf.org=0A= Subject: Re: [TLS] TLS and KCI vulnerable handshakes=0A= =0A= On 08/11/2015 02:05 PM, Peter Gutmann wrote:=0A= > Clemens Hlauschek writes:=0A= >=0A= >> I published a paper today on KCI-attacks in TLS. This might be of intere= st to=0A= >> the TLS WG.=0A= >>=0A= >> https://www.usenix.org/conference/woot15/workshop-program/presentation/h= lauschek=0A= >=0A= > Some comments on this, it looks like it requires a "cert with static (EC)= DH=0A= > key" in order to work, which would mean an X9.42 cert. Since no (public)= CA=0A= > that I know of can handle or issue such certs, this probably provides a= =0A= > reasonable amount of defence against this attack...=0A= =0A= =0A= =0A= Thanks for the critical reading. Actually, your point is touched upon in=0A= the paper. Instead of an ECDH certificate, an ECDSA certificate can be=0A= used by the attacker. The case for DH/DSS is different, and your point=0A= is valid for this latter case. I am working on a video showcasing the=0A= attack (Safari <-> Facebook), but if you decide that you still would not=0A= trust our claims made in the paper, it would be trivial to reproduce the=0A= attack: our MitM proof-of-concept implementation was realized with less=0A= than 10 patched lines of the openssl/stunnel codebase.=0A= =0A= =0A= See also RFC 4492:=0A= "Note that there is no structural difference between ECDH and ECDSA=0A= keys. A certificate issuer may use X.509 v3 keyUsage and=0A= extendedKeyUsage extensions to restrict the use of an ECC public key=0A= to certain computations"=0A= =0A= >=0A= > In terms of the suggested countermeasures:=0A= >=0A= >> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates,= and=0A= >> disable specifically the KeyAgreement flag=0A= >=0A= > Since the keyUsage flags are widely ignored by implementations, this won'= t=0A= > provide the protection that the text implies.=0A= >=0A= =0A= =0A= In case of the vulnerable Safari / SecureTransport / Mac OS X clients,=0A= it does make a difference, so having correct X509 KeyUsage settings is=0A= the best (and only sensible for servers supporting ECDSA) recommendation=0A= for server-side mitigation, from our perspective. The facebook.com=0A= security teams very quickly implemented that change. While it is=0A= certainly true that keyUsage flags are ignored by many implementations=0A= (this is also mentioned in the paper), checking (it is ambiguous=0A= according to the TLS specs whether it is mandatory for ECDH, but it is=0A= mandatory for DH if the KeyUsage extension is present) seems to have=0A= become more widespread recently.=0A= =0A= =0A= Best,=0A= Clemens=0A= From nobody Mon Aug 17 07:20:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13CC1A03E1 for ; Mon, 17 Aug 2015 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 K01T2zeR6N6o for ; Mon, 17 Aug 2015 07:20:20 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB08F1A1A57 for ; Mon, 17 Aug 2015 07:20:19 -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 (Postfix) with ESMTPS id 90CBE19C300; Mon, 17 Aug 2015 14:20:19 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7HEKEf2014641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2015 10:20:18 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Aug 2015 16:20:06 +0200 Message-ID: <1535886.1YJU6XDILK@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.4-200.fc22.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <55C7668F.1040105@gmail.com> References: <55C7668F.1040105@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6131060.RchrRLDOKc"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "dottomi@gmail.com" Subject: Re: [TLS] TLS Handshake message length too long X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:20:21 -0000 --nextPart6131060.RchrRLDOKc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 09 August 2015 16:41:19 dottomi@gmail.com wrote: > I have a question regarding the handshake message length. >=20 > The 'decode_error' alert in TLS 1.2 is defined as: >=20 > decode_error > A message could not be decoded because some field was out of th= e > specified range or the length of the message was incorrect. (..= .) >=20 > It says that the message "could not be decoded". What should happen > if the specified message length is longer than needed? I.e. the messa= ge > was successfully decoded, but the length of the message was incorrect= : > there is still some unknown data after the defined structure. that is definitely error for the case of a "length of a field is longer= than=20 expected" or "there's more data in message than the length specifies" =20 > For example, a Finished message has a length of 40 bytes, > but the 'verify_data' array has 32 bytes and there are 8 unknown byte= s > remaining in the received message. The 40 bytes I talk about here > is the length specified in the Handshake message header. >=20 > Is this also a fatal error? yes, always > Should the implementation just drop those bytes and proceed? definitely not, it should send a fatal alert, close connection and mark= =20 session as non resumable > On the other hand, there is the 'illegal_parameter' alert: >=20 > illegal_parameter > A field in the handshake was out of range or inconsistent with > other fields. This message is always fatal. >=20 > Is this alert suitable for the described scenario? no, it's for values that are explicitly bound to some specific range (e= .g.=20 client_random length tag always needs to be 32) verify_data has no range specified (it's opaque data), the negotiatied=20= ciphersuite defines what length it has =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart6131060.RchrRLDOKc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJV0e2WAAoJEJKo0bgB0vX1D4EP/A4lngdf33m6Zkp6xNrUYCpj liqGzz+MgrgG1vNjqCTBtiOiFX8kwqBL6BlW9lEKCNAHc/uNZJOL2aihZbPTCHS9 Y9ieEGs3+WWq8Yl1wxeB4ppoSWTo93XYFzPUMrWcDU0jHkyZH24hLlP1eapHwxr4 UFucQddLMS534mLenHOMj4wU6KA2HbgGwObZWq3IK+1XEcZBBzme9trHonOXUPOT +FJlWVTZoeiR8QV3Kq3/kJPLkai96+1lyV3+MBcwk18MAL+Nw2w2Vc3B1AQOhu1z 48kFtNcSDqYL/EACsPnSp8e3ywkO2Wdo4pb/vztHfPal70Bs3j/zZ0NBHAb+1N4E pmEbgNtbxHGYYUghJUFB2L+3j2Y7AnLlAefJATypoIXAbG//0oofjcu1oDr8hZnD cn6up3IPdJgz7APSPaygoqwhhE4Ky+srRsHBgLsVzcUnzQbcLMVT2NOWSG2Pq9ul BMcqCsfWyagN7zz9UszmOW2r4j8rNBDxbNq1gWWcnkn2rehgNgSbL4pErd7iVDu5 hN4SisBclhPnLRj/1mYdhd3CtbcYeYdlS9lA0UoBkLfIzkU8g95aF2fhI/jB+lom Ujti6f2M5d3nTBVF2Qw5cjqAb20lVp6K2JgBKumM3/rXYzwv/SWjNanVfDaZgdcA e9JE7orJFYsDP0OYm9Pb =HYcs -----END PGP SIGNATURE----- --nextPart6131060.RchrRLDOKc-- From nobody Mon Aug 17 07:21:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7E21A1A5D for ; Mon, 17 Aug 2015 07:21:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_18lqxGpRI5 for ; Mon, 17 Aug 2015 07:20:58 -0700 (PDT) Received: from 4.mo69.mail-out.ovh.net (4.mo69.mail-out.ovh.net [46.105.42.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC28D1A1A3D for ; Mon, 17 Aug 2015 07:20:57 -0700 (PDT) Received: from mail190.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo69.mail-out.ovh.net (Postfix) with SMTP id 0C4E61000959 for ; Mon, 17 Aug 2015 16:20:55 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 17 Aug 2015 16:20:55 +0200 Received: from 130.163-14-84.ripe.coltfrance.com (HELO ?10.41.51.97?) (contact@simonbernard.eu@84.14.163.130) by ns0.ovh.net with SMTP; 17 Aug 2015 16:20:53 +0200 Message-ID: <55D1EDC5.1010106@simonbernard.eu> Date: Mon, 17 Aug 2015 16:20:53 +0200 From: Simon Bernard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Eric Rescorla , tls@ietf.org References: <55BB88FD.4060901@simonbernard.eu> <55BBA7DA.8000806@simonbernard.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050104010105010402070700" X-Ovh-Tracer-Id: 17133100358165346546 X-Ovh-Remote: 84.14.163.130 (130.163-14-84.ripe.coltfrance.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrgedvucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrgedvucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:21:00 -0000 This is a multi-part message in MIME format. --------------050104010105010402070700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm sorry to insist, but What did you mean by transport level connection ? For me UDP was a connectionless protocol. Simon Le 31/07/2015 18:53, Eric Rescorla a écrit : > > > On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard > > wrote: > > Thx. > What did you mean by connection ? > > > transport level connection. > > A resume handshake is a new connection ? > > > You can also resume when you renegotiate. > > -Ekr > > > Le 31/07/2015 16:54, Eric Rescorla a écrit : > > The epoch is set to 0 at the start of each connection and then > incremented > with each handshake on that connection. > > -Ekr > > On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard > > >> wrote: > > Hi, > > I search in DTLS RFC 6347 if the epoch should be (re)set > to 0 > when we start a resume handshake, or if we keep the last used > value, or the last used value+1 ? I can not any clue of > that in > the spec. > Any idea ? > > Thx > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > --------------050104010105010402070700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'm sorry to insist, but What did you mean by transport level connection ? For me UDP was a connectionless protocol.

Simon

Le 31/07/2015 18:53, Eric Rescorla a écrit :


On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard <contact@simonbernard.eu> wrote:
Thx.
What did you mean by connection ?

transport level connection.

 
A resume handshake is a new connection ?

You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :
The epoch is set to 0 at the start of each connection and then incremented
with each handshake on that connection.

-Ekr

 On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard <contact@simonbernard.eu <mailto:contact@simonbernard.eu>> wrote:

    Hi,

      I search in DTLS RFC 6347 if the epoch should be (re)set to 0
    when we start a resume handshake, or if we keep the last used
    value, or the last used value+1 ? I can not any clue of that in
    the spec.
      Any idea ?

    Thx
    Simon

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





--------------050104010105010402070700-- From nobody Mon Aug 17 07:25:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D5A1A1A8D for ; Mon, 17 Aug 2015 07:25:13 -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 njYorOsq-SNO for ; Mon, 17 Aug 2015 07:25:09 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168761A1A86 for ; Mon, 17 Aug 2015 07:25:09 -0700 (PDT) Received: by iodb91 with SMTP id b91so152388570iod.1 for ; Mon, 17 Aug 2015 07:25: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:from:date :message-id:subject:to:cc:content-type; bh=eaVwe8vKjnM/hQT8syP3TiPmuTuuo+7HzbhNEW5DROc=; b=j+KqzYjvf4aJSV9LbnFXFx6mXaDP4TQm9UGf0dpV/iytC9i+eURK9fGbk+kHjjKYd3 GmgnENyXCrNOqDG2h5j4lNUTMgd78o67ezGBWaA3XZ+aSizGxWUkH91Py6z6R1Wa+3RD iFUSUfJVdrEzOvREkkwI5lJ+1XLr4yq4K6tRCIQMSZYSyLLxRr7An07p/RWujGyvASs8 7Ydeya6aaAEgEm/1eoRSKK830hMv47NTF1WkcUnsrzuShNqDD8J6JCp9O5mMJReCYB8R BFpjkbStAUvO1mZva9SrsxE6iM2c6EIVau5F9bco5N8DkQZWnkv4+3rNq07t2Fe4xJ7q JZUQ== X-Gm-Message-State: ALoCoQmPP8nrRP3NVlYPfEnkfPe97oEIfE5LsCV9TmcFnm07zJM1JJRsoXNu6LADBob6KqmqUXe3 X-Received: by 10.107.153.5 with SMTP id b5mr1900859ioe.143.1439821508518; Mon, 17 Aug 2015 07:25:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.79.79 with HTTP; Mon, 17 Aug 2015 07:24:29 -0700 (PDT) In-Reply-To: <55D1EDC5.1010106@simonbernard.eu> References: <55BB88FD.4060901@simonbernard.eu> <55BBA7DA.8000806@simonbernard.eu> <55D1EDC5.1010106@simonbernard.eu> From: Eric Rescorla Date: Mon, 17 Aug 2015 07:24:29 -0700 Message-ID: To: Simon Bernard Content-Type: multipart/alternative; boundary=001a1140eaaa8ea6d7051d82917b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:25:13 -0000 --001a1140eaaa8ea6d7051d82917b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please see RFC 6347 S 4.2.8 -Ekr On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard wrote: > I'm sorry to insist, but What did you mean by transport level connection = ? > For me UDP was a connectionless protocol. > > Simon > > > Le 31/07/2015 18:53, Eric Rescorla a =C3=A9crit : > > > > On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard > wrote: > >> Thx. >> What did you mean by connection ? >> > > transport level connection. > > > >> A resume handshake is a new connection ? > > > You can also resume when you renegotiate. > > -Ekr > > >> Le 31/07/2015 16:54, Eric Rescorla a =C3=A9crit : >> >>> The epoch is set to 0 at the start of each connection and then >>> incremented >>> with each handshake on that connection. >>> >>> -Ekr >>> >>> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >> > wrote: >>> >>> Hi, >>> >>> I search in DTLS RFC 6347 if the epoch should be (re)set to 0 >>> when we start a resume handshake, or if we keep the last used >>> value, or the last used value+1 ? I can not any clue of that in >>> the spec. >>> Any idea ? >>> >>> Thx >>> Simon >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >>> >> > > --001a1140eaaa8ea6d7051d82917b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please see RFC 6347 S 4.2.8

-Ekr
<= div>

On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard <contact@simonbern= ard.eu> wrote:
=20 =20 =20
I'm sorry to insist, but What did you mean by transport level connection ? For me UDP was a connectionless protocol.

Simon


Le 31/07/2015 18:53, Eric Rescorla a =C3=A9crit=C2=A0:


On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard <contact@simonbernard.eu> wrote:
Thx.
What did you mean by connection ?

transport level connection.

=C2=A0
A resume handshake is a new connection ?

You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a =C3=A9crit :
The epoch is set to 0 at the start of each connection and then incremented
with each handshake on that connection.

-Ekr

 On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard <contact@simonbernard= .eu <mailto:contact@simonbernard.eu>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 I search in DTLS RFC 6347 if the epo= ch should be (re)set to 0
=C2=A0 =C2=A0 when we start a resume handshake, or if we = keep the last used
=C2=A0 =C2=A0 value, or the last used value+1 ? I can not= any clue of that in
=C2=A0 =C2=A0 the spec.
=C2=A0 =C2=A0 =C2=A0 Any idea ?

=C2=A0 =C2=A0 Thx
=C2=A0 =C2=A0 Simon

=C2=A0 =C2=A0 ___________________________________________= ____
=C2=A0 =C2=A0 TLS mailing list
 =C2=A0 =C2=A0 TLS@ietf.org <mailto:TLS@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/tls






--001a1140eaaa8ea6d7051d82917b-- From nobody Mon Aug 17 07:43:57 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1911A3B9F for ; Mon, 17 Aug 2015 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 SU8a_ci9axqG for ; Mon, 17 Aug 2015 07:43:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3F71A219E for ; Mon, 17 Aug 2015 07:43:54 -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 (Postfix) with ESMTPS id 7F1768F298; Mon, 17 Aug 2015 14:43:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-112-27.ams2.redhat.com [10.36.112.27]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7HEhnCx007553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2015 10:43:53 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 17 Aug 2015 16:43:41 +0200 Message-ID: <1486986.OVeGYfMRs9@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.9 (Linux/4.1.4-200.fc22.x86_64; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20150817120246.GA32255@LK-Perkele-VII> References: <55D1B5CC.1050005@gmail.com> <20150817120246.GA32255@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6993592.xhapalaqSf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 14:43:56 -0000 --nextPart6993592.xhapalaqSf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 17 August 2015 15:02:46 Ilari Liusvaara wrote: > On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote: > > Below a long list of comments, generally minor. The document is= > > already very good - we're making great progress!
> > =20 > > The record length field is limited by encrypted-length+2048. > > =20 > > Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce = an > > expansion of greater than 1024 bytes". >=20 > Actually, I think both should be 256 (256-byte expansion from AEAD > is already quite much). >=20 > (This was proposed a while back). I don't think this adds anything while introducing requirement of addin= g=20 additional "if" to implementations that support also TLS1.2 and lower > > D.1.2: do we really need to worry about version rollback to > > =20 > > SSLv2? I suggest to remove this section. >=20 > Well, it is not possible to even try to negotiate TLS 1.3 using SSLv2= > compat. hello, since that can't transmit extensions, but at least one= > extension is REQUIRED in order to successfully negotiate TLS 1.3. >=20 > And the second paragraph seems to be about RSA key exchange, which > isn't supported anymore in TLS 1.3. >=20 > Yes, the section looks like it could be removed. OTOH, TLS1.3 is not a superset of TLS1.2 so we need to think about down= grade=20 to TLS1.2.=20 > But that isn't the only way rollback attacks can occur, also some > clients can be coaxed to downgrade by selectively blocking connection= s. > Unfortunately the intolerance to TLS 1.3 is so bad that many clients > will likely be willing to perform unauthenticated downgrade to TLS > 1.2 (and FALLBACK_SCSV is useless here). how is it useless? A server which support at most TLS1.2 that receives a TLS1.2 client hel= lo with=20 FALLBACK_SCSV MUST continue the connection with TLS1.2 =2D-=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart6993592.xhapalaqSf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJV0fMdAAoJEJKo0bgB0vX10PcP/jqUbbpUOsZ9U+MGRg1S/NWl TSY/N5OTG11ehScGhVImN6OY6ZZC6WUygr0bRmQFjX2FoL2EntqVYPzZ1pzLQssZ gzdehezf158gFrDczO4aPnfVEynEtXMARitzYLq1uCpqquR6OYvYHxTsvEDsV1o/ /TElaPN7tFQhdPVuDy4wpJIIwjDgK5bdEAI732vX0D+5n38rmZ+gB8of8nMQLx1b 0l+wQopBAg5hCydPOQCAZxtsT4micFNuk9ZnGEgEt7CtrwWo07WytTwX6pLRskIi 9nIylqddn/z2zKUt9segfXJE1VByW9OOx424l5WfK0C/o6l9mUZoTrVBTMIvNBw9 +BC7oAlSkuu7ilq8hr5182nTJT+AwbZtXRczxTBnGYvAe10eUI8D+KcV2axfYUpT gldLPe/TaCE7eZH2b0EKzo7bVnizn0bbpHWPGgDTYCg3Yl7JHvnheWYV79kSsoFa 3z3TF+7liWd+xAxee0naQaoQC7f8MBoF7EHSt/ye/6dVQ8r+yGnQuC5aTQEWB5CV HT5wbxKljKQ69xLCQ9OVJTx2vQMHJNdOFilLmgMlr2pOAu0KlaZdgR0bVJ24xvwq PXpJBSPk4e9R5RRwNUBUAn2yBGq/Rxf5u83CkskKYWYeX37Lhqzvvg8Br5seFNgF fvYGe2CpYx+2P9lW7l9L =Dspp -----END PGP SIGNATURE----- --nextPart6993592.xhapalaqSf-- From nobody Mon Aug 17 08:18:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15281AC3D3 for ; Mon, 17 Aug 2015 08:18:23 -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, J_CHICKENPOX_22=0.6, 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 nZI9I-M_OBz6 for ; Mon, 17 Aug 2015 08:18:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97991AC3DF for ; Mon, 17 Aug 2015 08:18:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AED46284D92; Mon, 17 Aug 2015 15:18:14 +0000 (UTC) Date: Mon, 17 Aug 2015 15:18:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150817151814.GE24426@mournblade.imrryr.org> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS and KCI vulnerable handshakes 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, 17 Aug 2015 15:18:24 -0000 On Mon, Aug 17, 2015 at 12:38:54PM +0000, Peter Gutmann wrote: > One thing that I'd really like to know is that given the non-PFS (EC)DH suites > were obviously a dumb idea and barely supported by anything (not just in terms > of TLS code, no public CA I know of will issue the required X9.42 certs, > although as the paper points out you can get ECDH ones that can be misused), > why did OpenSSL add support for them as late as 1.0.2? Does anyone know why > they were added? I can't answer why, but I know what and when: The cipher-suites that were added to 1.0.2 were fixed finite-field DH ciphers, not fixed ECDH. DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(256) Mac=AEAD DH-DSS-AES256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA1 DH-DSS-AES256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA256 DH-DSS-CAMELLIA256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA1 DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1 DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256 DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1 DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(128) Mac=AEAD DH-DSS-AES128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA1 DH-DSS-AES128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA256 DH-DSS-CAMELLIA128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA1 DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1 DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256 DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-DSS-DES-CBC3-SHA SSLv3 Kx=DH/DSS Au=DH Enc=3DES(168) Mac=SHA1 DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1 DH-DSS-DES-CBC-SHA SSLv3 Kx=DH/DSS Au=DH Enc=DES(56) Mac=SHA1 DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 The relevant code was added to the 1.0.2 dev branch in Apr of 2012, backporting said code from the "master" branch where fixed DH support was enabled in January of 2012. On a related note, for what it's worth ECDSA certs are constrained by keyUsage if the extension is present. -- Viktor. From nobody Mon Aug 17 08:36:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF971AC41F for ; Mon, 17 Aug 2015 08:36:48 -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 vvss_wgv9AZW for ; Mon, 17 Aug 2015 08:36:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3A71AC417 for ; Mon, 17 Aug 2015 08:36:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8AF0F284D92; Mon, 17 Aug 2015 15:36:45 +0000 (UTC) Date: Mon, 17 Aug 2015 15:36:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150817153645.GF24426@mournblade.imrryr.org> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> <20150817151814.GE24426@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150817151814.GE24426@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS and KCI vulnerable handshakes 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, 17 Aug 2015 15:36:48 -0000 On Mon, Aug 17, 2015 at 03:18:14PM +0000, Viktor Dukhovni wrote: > The relevant code was added to the 1.0.2 dev branch in Apr of 2012, > backporting said code from the "master" branch where fixed DH > support was enabled in January of 2012. > > On a related note, for what it's worth ECDSA certs are constrained > by keyUsage if the extension is present. My thoughts on these from the openssl-team list (non-public) from May of 2015: * Remove. Frankly, I think all the static DH ciphers (even non-export) are useless bloat. Nobody uses them, and they lead to large client HELLO messages, and interop issues. I'd like to see them all deprecated, that'd be 42 fewer useless ciphersuites. * > Oh - except DH only. I think we need to keep static ECDH. I've been told > there are some servers out there that are configured to do static ECDH > with their ECDSA cert. Whatever for? Why go to all that trouble to defeat forward secrecy? And now there are additional reasons to drop support for these from "master". Making incompatible changes in 1.0.2 patch releases is perhaps not an option (unless removal of DHr/DHd/ECDHr/ECDHe can be reasonably positioned as a bug fix). -- Viktor. From nobody Mon Aug 17 08:54:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB71B2E46 for ; Mon, 17 Aug 2015 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_22=0.6, 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 kNhwp-PK_bxA for ; Mon, 17 Aug 2015 08:54:06 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D001B2E5A for ; Mon, 17 Aug 2015 08:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1439826843; x=1471362843; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IgnYOKCGPOj0Ihmc68/TG5QAUP+9Nqqb2ohyiW5UMHs=; b=wSJyyX4oqr8DFF+jJVhW5l1HB1bCROxDHWpzTEWTPeDhN4uAsk/+itdh xCzKgD++5V8CjZUvWa2lqZgRbgRIF9Rautz4VkmP6qQIIM4nsSaUzg7rg UTsCRkwzsVZwr0jNrG1nO3/fFNhSG1YgGDQfAmGwO6n0AP8wQ96zMkRd2 IsBNOPpz+Q6y9msJ+cqDKrDdDjixgKqlw9RzdBgXLHi1Iucq+TmKibpd0 O9T/aplI0hPWDh99TAK4xrowYrNdaOpxGX/dydhvRvJF1gA5HZCj4EdY8 XcFaI61NAjxkcXrPRodjSftqzFbLzrn8sDMEN5NHpKfJWcQNvAoBHzH8K Q==; X-IronPort-AV: E=Sophos;i="5.15,695,1432555200"; d="scan'208";a="35697675" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Aug 2015 03:54:01 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0174.001; Tue, 18 Aug 2015 03:54:00 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS and KCI vulnerable handshakes Thread-Index: AQHQ1F5LrI8QBmnw8E6Q+G9ikduiz54HF7RI//+NqoCACYRrov//ZC4AgADQc9I= Date: Mon, 17 Aug 2015 15:53:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz>, <20150817151814.GE24426@mournblade.imrryr.org> In-Reply-To: <20150817151814.GE24426@mournblade.imrryr.org> 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: Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 15:54:08 -0000 Viktor Dukhovni writes:=0A= =0A= >I can't answer why, but I know what and when:=0A= =0A= I was trying to avoid finger-pointing so I didn't go through the changelog = to=0A= see whodunnit, I was more interested in the motivation. Same for Apple, wh= y=0A= would you implement something that pretty much no-one else (at the time)=0A= supported, and for good reason?=0A= =0A= Having said that though:=0A= =0A= DH-DSS-CAMELLIA256-SHA SSLv3 Kx=3DDH/DSS Au=3DDH Enc=3DCamellia(256) M= ac=3DSHA1=0A= DH-DSS-CAMELLIA128-SHA SSLv3 Kx=3DDH/DSS Au=3DDH Enc=3DCamellia(128) M= ac=3DSHA1=0A= DH-DSS-SEED-SHA SSLv3 Kx=3DDH/DSS Au=3DDH Enc=3DSEED(128) Mac= =3DSHA1=0A= DH-DSS-DES-CBC-SHA SSLv3 Kx=3DDH/DSS Au=3DDH Enc=3DDES(56) Mac= =3DSHA1=0A= DH-RSA-DES-CBC-SHA SSLv3 Kx=3DDH/RSA Au=3DDH Enc=3DDES(56) Mac= =3DSHA1=0A= =0A= that sort of stuff just compounds the WTF. Static DH + DSA + single DES, a= dded in 2012.=0A= W. T. F.=0A= =0A= Peter.= From nobody Mon Aug 17 09:08:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DD01B2EC3 for ; Mon, 17 Aug 2015 09:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhoxKBicp-tw for ; Mon, 17 Aug 2015 09:08:01 -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 44B211B2EC2 for ; Mon, 17 Aug 2015 09:08:01 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B498F496C53; Mon, 17 Aug 2015 16:08:00 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9E8CE496C4E; Mon, 17 Aug 2015 16:08:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1439827680; bh=VT/dcGfeBUJcF9Jd+yu+p1DwbPwkaXxHkx1NzjvDjt4=; l=292; h=From:To:Date:References:In-Reply-To:From; b=YaC4SHsZeeLXOHi+m9CEBI7yceWzenoRvKxxNbdVElMii88C4sufBp+/oThSrDVQJ maDJT9rYjky2HxBu6jBOW6+fjkjMBtkgbXARyze19+6BwIJlzk3DGimpQQtlB1yQFf mZl7OPQ47xka9Hb/HNq4H8EMKGWkmmbnX8oT1Utw= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 9B6BA1E080; Mon, 17 Aug 2015 16:08:00 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 17 Aug 2015 11:08:00 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Mon, 17 Aug 2015 11:07:59 -0500 From: "Salz, Rich" To: Peter Gutmann , "tls@ietf.org" Thread-Topic: [TLS] TLS and KCI vulnerable handshakes Thread-Index: AQHQ1F5cNCL3+4bQGEym4koOUtml7J4HF7RI//+NqoCACYRrooAAgSoAgAAJ/YD//68oIA== Date: Mon, 17 Aug 2015 16:07:59 +0000 Message-ID: <4f1c28360a0441219cbb21799ecb88be@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz>, <20150817151814.GE24426@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.23] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:08:02 -0000 > I was more interested in the motivation. Same for Apple, > why would you implement something that pretty much no-one else (at the > time) supported, and for good reason? Perhaps because this was a year before Snowden and the mindset was unquesti= oning complete RFC implementation? From nobody Mon Aug 17 09:09:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054821B2E90 for ; Mon, 17 Aug 2015 09:09: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, J_CHICKENPOX_22=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 O5d_mPxKDDdG for ; Mon, 17 Aug 2015 09:09:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376C71B2E76 for ; Mon, 17 Aug 2015 09:09:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8DA6D284D92; Mon, 17 Aug 2015 16:09:40 +0000 (UTC) Date: Mon, 17 Aug 2015 16:09:40 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150817160940.GH24426@mournblade.imrryr.org> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> <20150817151814.GE24426@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS and KCI vulnerable handshakes 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, 17 Aug 2015 16:09:43 -0000 On Mon, Aug 17, 2015 at 03:53:59PM +0000, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >I can't answer why, but I know what and when: > > I was trying to avoid finger-pointing so I didn't go through the changelog to > see whodunnit, I was more interested in the motivation. Same for Apple, why > would you implement something that pretty much no-one else (at the time) > supported, and for good reason? > > Having said that though: > > DH-DSS-CAMELLIA256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA1 > DH-DSS-CAMELLIA128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA1 > DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 > DH-DSS-DES-CBC-SHA SSLv3 Kx=DH/DSS Au=DH Enc=DES(56) Mac=SHA1 > DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 > > that sort of stuff just compounds the WTF. Static DH + DSA + single DES, added in 2012. > W. T. F. The mechanics of how it happened are simple enough. The ciphers were there all along for around a decade or so, but they were all disabled because the key exchage method was not implemented. What happened in 2012 is that the key exchange got implemented, so presto-magic a new single-DES fixed-DH cipher. I'd like to see more attention paid to changes that explicitly or implicitly introduce new ciphers that fall into the WTF category. I hope we'll be able to exercise more discretion going forward. That said, has https://tools.ietf.org/html/rfc5469 been sufficiently well publicized? I've seen a lot of discussion around the deprecation of RC4, but DES and IDEA seem to have lingered on... -- Viktor. From nobody Mon Aug 17 09:20:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF771A890A for ; Mon, 17 Aug 2015 09:20:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qMNQEQGmf7f for ; Mon, 17 Aug 2015 09:20:37 -0700 (PDT) Received: from 9.mo69.mail-out.ovh.net (9.mo69.mail-out.ovh.net [46.105.56.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2451A891B for ; Mon, 17 Aug 2015 09:20:33 -0700 (PDT) Received: from mail190.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo69.mail-out.ovh.net (Postfix) with SMTP id C9DAA1020C82 for ; Mon, 17 Aug 2015 18:20:31 +0200 (CEST) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 17 Aug 2015 18:20:31 +0200 Received: from 130.163-14-84.ripe.coltfrance.com (HELO ?10.41.51.97?) (contact@simonbernard.eu@84.14.163.130) by ns0.ovh.net with SMTP; 17 Aug 2015 18:20:29 +0200 Message-ID: <55D209CC.4080708@simonbernard.eu> Date: Mon, 17 Aug 2015 18:20:28 +0200 From: Simon Bernard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Eric Rescorla References: <55BB88FD.4060901@simonbernard.eu> <55BBA7DA.8000806@simonbernard.eu> <55D1EDC5.1010106@simonbernard.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050203000102030301080000" X-Ovh-Tracer-Id: 706220717259241714 X-Ovh-Remote: 84.14.163.130 (130.163-14-84.ripe.coltfrance.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrgedvucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrgedvucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:20:39 -0000 This is a multi-part message in MIME format. --------------050203000102030301080000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I re-readed this paragraph and it's still not clear, what did you mean by connection at transport layer for UDP. I well understand that if a server receive a clientHello with epoch=0, this means that a new handshake should be done. But I still don't know what happends in a ResumeHandshake use case. In fact, my use case is a client behind a NAT which communicate periodically. at each period, its IP/Port could changed (because of NAT), so we would like to resume handshake each time. 1) Does it make sense ? 2) If yes, should we do the resume handhsake with epoch = 0 or continue with previous epoch ? Le 17/08/2015 16:24, Eric Rescorla a écrit : > Please see RFC 6347 S 4.2.8 > > -Ekr > > > On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard > > wrote: > > I'm sorry to insist, but What did you mean by transport level > connection ? For me UDP was a connectionless protocol. > > Simon > > > Le 31/07/2015 18:53, Eric Rescorla a écrit : >> >> >> On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard >> > wrote: >> >> Thx. >> What did you mean by connection ? >> >> >> transport level connection. >> >> A resume handshake is a new connection ? >> >> >> You can also resume when you renegotiate. >> >> -Ekr >> >> >> Le 31/07/2015 16:54, Eric Rescorla a écrit : >> >> The epoch is set to 0 at the start of each connection and >> then incremented >> with each handshake on that connection. >> >> -Ekr >> >> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >> >> > >> wrote: >> >> Hi, >> >> I search in DTLS RFC 6347 if the epoch should be >> (re)set to 0 >> when we start a resume handshake, or if we keep the >> last used >> value, or the last used value+1 ? I can not any clue >> of that in >> the spec. >> Any idea ? >> >> Thx >> Simon >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> > > --------------050203000102030301080000 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I re-readed this paragraph and it's still not clear, what did you mean by connection at transport layer for UDP.

I well understand that if a server receive a clientHello with epoch=0, this means that a new handshake should be done.

But I still don't know what happends in a ResumeHandshake use case.

In fact, my use case is a client behind a NAT which communicate periodically. at each period, its IP/Port could changed (because of NAT), so we would like to resume handshake each time.
1) Does it make sense ?
2) If yes, should we do the resume handhsake with epoch = 0 or continue with previous epoch ?


Le 17/08/2015 16:24, Eric Rescorla a écrit :
Please see RFC 6347 S 4.2.8

-Ekr


On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard <contact@simonbernard.eu> wrote:
I'm sorry to insist, but What did you mean by transport level connection ? For me UDP was a connectionless protocol.

Simon


Le 31/07/2015 18:53, Eric Rescorla a écrit :


On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard <contact@simonbernard.eu> wrote:
Thx.
What did you mean by connection ?

transport level connection.

 
A resume handshake is a new connection ?

You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a écrit :
The epoch is set to 0 at the start of each connection and then incremented
with each handshake on that connection.

-Ekr

 On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard <contact@simonbernard.eu <mailto:contact@simonbernard.eu>> wrote:

    Hi,

      I search in DTLS RFC 6347 if the epoch should be (re)set to 0
    when we start a resume handshake, or if we keep the last used
    value, or the last used value+1 ? I can not any clue of that in
    the spec.
      Any idea ?

    Thx
    Simon

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







--------------050203000102030301080000-- From nobody Mon Aug 17 09:48:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D591A012D for ; Mon, 17 Aug 2015 09:48:13 -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 26gEa33qE5Fl for ; Mon, 17 Aug 2015 09:48:11 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C901A0126 for ; Mon, 17 Aug 2015 09:48:11 -0700 (PDT) Received: by igfj19 with SMTP id j19so62060442igf.0 for ; Mon, 17 Aug 2015 09:48:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=diVXQbCNpo9ZSL8c9vQj0q0tXMEv2daMP5XeTrhc5pI=; b=OYBPtz3OKtl/V5YyFj7wOPDgKzSQbhXM7cVG9Y5XkdHFDZiqrScdcp9yx35W5ffz/Q 0ppUyqkbK1X1CeKtbYbyNYM5oG08DQeNUNLV0ETjgTBfSP4GQcV7VTFNBT9RziHt76PO GJVL9SiKYH8I/bAgr6NM9Wj+L8EhOHMQnDBCxQGffmcFAH/Ubrv5DmFO4E8P4rTgGuOP Ljegt9v3dA0NiZwS7Vr+NHFm65N7as5PrR6fe+T2Oe0bG2bYwNByfWUwALylEGQqhTI+ DC4kmmfW2aVf35nPm7VBSFNeQcG6sW67PcN3AR01lfUrWX/oAUGGVxhGIH40l9EUQGcC iBsw== X-Gm-Message-State: ALoCoQlDb9B/7CjxD8LwrcOHDnkIkfBVrZRGN27Xhz/agx8Hkx4zKjDdLu18fTD2wnfi7XQyOTGe X-Received: by 10.50.132.70 with SMTP id os6mr16308052igb.27.1439830090608; Mon, 17 Aug 2015 09:48:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.79.79 with HTTP; Mon, 17 Aug 2015 09:47:31 -0700 (PDT) In-Reply-To: <55D209CC.4080708@simonbernard.eu> References: <55BB88FD.4060901@simonbernard.eu> <55BBA7DA.8000806@simonbernard.eu> <55D1EDC5.1010106@simonbernard.eu> <55D209CC.4080708@simonbernard.eu> From: Eric Rescorla Date: Mon, 17 Aug 2015 09:47:31 -0700 Message-ID: To: Simon Bernard Content-Type: multipart/alternative; boundary=047d7b2e42f216ce55051d8491d7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS epoch and resume session/handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:48:13 -0000 --047d7b2e42f216ce55051d8491d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2015 at 9:20 AM, Simon Bernard wrote: > I re-readed this paragraph and it's still not clear, what did you mean by > connection at transport layer for UDP. > > I well understand that if a server receive a clientHello with epoch=3D0, > this means that a new handshake should be done. > > But I still don't know what happends in a ResumeHandshake use case. > > In fact, my use case is a client behind a NAT which communicate > periodically. at each period, its IP/Port could changed (because of NAT), > so we would like to resume handshake each time. > 1) Does it make sense ? > 2) If yes, should we do the resume handhsake with epoch =3D 0 or continue > with previous epoch ? > Resumption isn't relevant here. If you are renegotiating (i.e., the ClientHello will be encrypted under a previous cipher suite) then you have epoch > 0. Otherwise, epoch =3D 0. -Ekr > > Le 17/08/2015 16:24, Eric Rescorla a =C3=A9crit : > > Please see RFC 6347 S 4.2.8 > > -Ekr > > > On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard > wrote: > >> I'm sorry to insist, but What did you mean by transport level connection >> ? For me UDP was a connectionless protocol. >> >> Simon >> >> >> Le 31/07/2015 18:53, Eric Rescorla a =C3=A9crit : >> >> >> >> On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard >> wrote: >> >>> Thx. >>> What did you mean by connection ? >>> >> >> transport level connection. >> >> >> >>> A resume handshake is a new connection ? >> >> >> You can also resume when you renegotiate. >> >> -Ekr >> >> >>> Le 31/07/2015 16:54, Eric Rescorla a =C3=A9crit : >>> >>>> The epoch is set to 0 at the start of each connection and then >>>> incremented >>>> with each handshake on that connection. >>>> >>>> -Ekr >>>> >>>> On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard >>> > wrote: >>>> >>>> Hi, >>>> >>>> I search in DTLS RFC 6347 if the epoch should be (re)set to 0 >>>> when we start a resume handshake, or if we keep the last used >>>> value, or the last used value+1 ? I can not any clue of that in >>>> the spec. >>>> Any idea ? >>>> >>>> Thx >>>> Simon >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>>> >>> >> >> > > --047d7b2e42f216ce55051d8491d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 17, 2015 at 9:20 AM, Simon Bernard <contact@simonber= nard.eu> wrote:
=20 =20 =20
I re-readed this paragraph and it's still not clear, what did you mean by connection at transport layer for UDP.

I well understand that if a server receive a clientHello with epoch=3D0, this means that a new handshake should be done.

But I still don't know what happends in a ResumeHandshake use case.=

In fact, my use case is a client behind a NAT which communicate periodically. at each period, its IP/Port could changed (because of NAT), so we would like to resume handshake each time.
1) Does it make sense ?
2) If yes, should we do the resume handhsake with epoch =3D 0 or continue with previous epoch ?

Re= sumption isn't relevant here.

If you are reneg= otiating (i.e., the ClientHello will be encrypted under a previous cipher
suite) then you have epoch > 0. Otherwise, epoch =3D 0.

-Ekr

<= div bgcolor=3D"#FFFFFF" text=3D"#000000">


Le 17/08/2015 16:24, Eric Rescorla a =C3=A9crit=C2=A0:
Please see RFC 6347 S 4.2.8

-Ekr


On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard <contact@simonbernard.eu> wrote:
I'm sorry to ins= ist, but What did you mean by transport level connection ? For me UDP was a connectionless protocol.

Simon


Le 31/07/2015 18:53, Eric Rescorla a =C3=A9crit=C2= =A0:


On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard <contact@simonberna= rd.eu> wrote:
Thx.
What did you mean by connection ?

transport level connection.

=C2=A0
A resume handshake is a new connection ?

You can also resume when you renegotiate.

-Ekr


Le 31/07/2015 16:54, Eric Rescorla a =C3=A9cr= it :
The epoch is set to 0 at the start of each connection and then incremented
with each handshake on that connection.

-Ekr

 On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard <contact@simonbernard.eu <mailto:contact@simonbernard.eu>> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 I search in DTLS RFC 6= 347 if the epoch should be (re)set to 0
=C2=A0 =C2=A0 when we start a resume handsh= ake, or if we keep the last used
=C2=A0 =C2=A0 value, or the last used value= +1 ? I can not any clue of that in
=C2=A0 =C2=A0 the spec.
=C2=A0 =C2=A0 =C2=A0 Any idea ?

=C2=A0 =C2=A0 Thx
=C2=A0 =C2=A0 Simon

=C2=A0 =C2=A0 ___________________________________________= ____
=C2=A0 =C2=A0 TLS mailing list
 =C2=A0 =C2=A0 TLS@ietf.org <mailto:TLS@ietf.org>
=C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/tls








--047d7b2e42f216ce55051d8491d7-- From nobody Mon Aug 17 10:37:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EE41ACDA8 for ; Mon, 17 Aug 2015 10:37: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 6pQaX0v6sCgo for ; Mon, 17 Aug 2015 10:37:24 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE75E1ACDA4 for ; Mon, 17 Aug 2015 10:37:24 -0700 (PDT) Received: by ykll84 with SMTP id l84so70079045ykl.0 for ; Mon, 17 Aug 2015 10:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cjktlC5IvnpvOU+pt1fzoUlUnWPz2qmnO5I9koO3YCM=; b=0I7FKyWMTnLr+GTCGdZ3UVNGY8uu7TaRmXLgdwkVRh5M5YtWhcotB4DkKoapXdz4sM glRSv18fAWJBJKa/VmDYQaEQG9CKDn7H03P4P4iLLeF4snxePHYqkZ0Y1cg/270U0NRX JUSlr+1bEYoNeXFah13VqdSHO2sJkBpDu3b1yV7IQD2bCbHVZA2Pofpj86qDrxwxV6vV T2fui/MjKlYW9jy6QPyYuNe4x3P6lmKIqc1H1F3fadu6mjHBJG65DQRKLusRpMeL+GN1 KmHtT04hhb08oa+ZhM/PfzTPGUdxV0W8a9j7lLoyoPz/tGP6IKldRmEH+bbQmFOxB/Ru pKEg== MIME-Version: 1.0 X-Received: by 10.13.234.138 with SMTP id t132mr2737082ywe.89.1439833044143; Mon, 17 Aug 2015 10:37:24 -0700 (PDT) Received: by 10.129.22.211 with HTTP; Mon, 17 Aug 2015 10:37:24 -0700 (PDT) In-Reply-To: <20150817120246.GA32255@LK-Perkele-VII> References: <55D1B5CC.1050005@gmail.com> <20150817120246.GA32255@LK-Perkele-VII> Date: Mon, 17 Aug 2015 10:37:24 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:37:27 -0000 On 17 August 2015 at 05:02, Ilari Liusvaara wrote: > > Actually, I think both should be 256 (256-byte expansion from AEAD > is already quite much). Pull request or it didn't happen ;) From nobody Mon Aug 17 12:01:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0151B2F25 for ; Mon, 17 Aug 2015 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aW40UPMCLYj for ; Mon, 17 Aug 2015 12:01:31 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D4B1B2F2C for ; Mon, 17 Aug 2015 12:01:16 -0700 (PDT) Received: by pdbfa8 with SMTP id fa8so58702566pdb.1 for ; Mon, 17 Aug 2015 12:01:16 -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=HUQHGkY8DhLmf/jo2uIO0zHxZH4ZGx6lNL3GD9q5QVo=; b=Sj2mKF/idD6/08pm3njpz92czH4x+CyDkK7i+iOlDGL/y6GvfPwo+AkbWij6UvNNME 1TSLJNhA3KrW9Q4UNBwuoISMOWuE3+m6GtCXc+9NRXafq9zbc9GMPXTTFD7rHYzlHqvh mvG2J0RL4GOdyDqqVXKDXU4lVtu3S2JqRhw62TrMV5jOcCmdpLCZw3rWshDmEZBxXbL+ uR/fS4utGMx+UEPk+8gcWzHEa7qjwdoAY8OMkiRPacdFWb525ovHZMri7uprOy03vF2j /rMO3ki0vN3PbTjrsMg6wD/VfSDJWlroc8qWrLJ0MoEfbZH0mNE/lLBduxqojQBcIIn7 tOAQ== X-Received: by 10.70.88.2 with SMTP id bc2mr5301535pdb.52.1439838076008; Mon, 17 Aug 2015 12:01:16 -0700 (PDT) Received: from [172.20.105.60] (162-249-219-43.static-ip.telepacific.net. [162.249.219.43]) by smtp.googlemail.com with ESMTPSA id a2sm15451453pbu.41.2015.08.17.12.01.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 12:01:15 -0700 (PDT) Message-ID: <55D22F77.5060807@gmail.com> Date: Mon, 17 Aug 2015 12:01:11 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Martin Thomson , Ilari Liusvaara References: <55D1B5CC.1050005@gmail.com> <20150817120246.GA32255@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:01:32 -0000 My original mail had some 15 comments, some trivial, some not. Do you expect 15 PRs? Thanks, Yaron On 08/17/2015 10:37 AM, Martin Thomson wrote: > On 17 August 2015 at 05:02, Ilari Liusvaara wrote: >> >> Actually, I think both should be 256 (256-byte expansion from AEAD >> is already quite much). > > > Pull request or it didn't happen ;) > From nobody Mon Aug 17 12:07:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EFC1B2F36 for ; Mon, 17 Aug 2015 12:07:30 -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 rbsPxheZybTH for ; Mon, 17 Aug 2015 12:07:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF171B2F45 for ; Mon, 17 Aug 2015 12:07:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78A66284D92; Mon, 17 Aug 2015 19:07:16 +0000 (UTC) Date: Mon, 17 Aug 2015 19:07:16 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150817190716.GP24426@mournblade.imrryr.org> References: <55D1B5CC.1050005@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D1B5CC.1050005@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] TLS 1.3 comments 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, 17 Aug 2015 19:07:30 -0000 On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote: > * Server Configuration: how does the client know to whom the > configuration applies? For example if I connected to > "*.example.com" (a wildcard cert) and now I connect to > "srv.example.com", should I use the stored configuration? Clients don't "connect to *.example.com", they connect to a specific server, one of whose "presented identities" might be "*.example.com". Since clients don't a priori know which certificates correspond to which reference identities, they can't apply a configuration to anything other than the exact peer for which it was obtained. Section 6.2.2 speaks of "the server", and I think this needs to be taken literally. Not some set of servers, but "the server". Of course load-balancers might hide multiple servers behind a single transport end-point, in which case the client may not be able to distinguish between them, and it is then up to the server administrators to ensure that any configurations are sufficiently "portable" between the servers in the pool. This is similar to the question of when to reuse cached sessions. Postfix, for example, does not reuse a session established to one IP address for a multi-homed host, to communicate with "the same" host on another IP address (which might not in fact be the same host). [ Even further, Postfix avoids re-using sessions when the SMTP conversation prior to STARTTLS shows a different server name in the EHLO reply. ] So I think the current language is largely fine, with "the server" meaning whatever the client uses to identify a single peer as best it can. -- Viktor. From nobody Mon Aug 17 12:30:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3611B2F60 for ; Mon, 17 Aug 2015 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeKkp5ANURo8 for ; Mon, 17 Aug 2015 12:30:21 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D3D1B2F4F for ; Mon, 17 Aug 2015 12:30:21 -0700 (PDT) Received: by ykbi184 with SMTP id i184so72340487ykb.2 for ; Mon, 17 Aug 2015 12:30: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=7NfYHbkyRlshQMd3zL0TxyVWmJNuI+Bmk3mk7rnYGYs=; b=tGJG/R6EynIFPr3BV7BmOr4roaG0FbeKEebKNW1t44hwOnFGAONOdzHe2S62uMoxwr l/JR4oFz3enJspjhLHp1qjbgaiinO9X7WRnwkQwOEgaFfPhEPdLrEI2hTJ2Gdp50v2R2 YpoQABqjxUgEnDJxySGBRWZmRiW6GjtpKb4N/W0YAwzAI9iJMng/vD+n+jzLMQSmSQSK zCq+E2k8NWleZtP2FrWoxwLuQGkp4jyYHTx0gYKEcpf1DhT4mDxVc1d0rRh2sgAAztBR 82dpX5DILcx1jah7lOu+Sggf2Q+4xPITSdYxwl1KKUDHD3w+sn4H8BTTIiHKV84sDIgl VirA== MIME-Version: 1.0 X-Received: by 10.129.45.194 with SMTP id t185mr3338441ywt.52.1439839820426; Mon, 17 Aug 2015 12:30:20 -0700 (PDT) Received: by 10.129.22.211 with HTTP; Mon, 17 Aug 2015 12:30:20 -0700 (PDT) Received: by 10.129.22.211 with HTTP; Mon, 17 Aug 2015 12:30:20 -0700 (PDT) In-Reply-To: <55D22F77.5060807@gmail.com> References: <55D1B5CC.1050005@gmail.com> <20150817120246.GA32255@LK-Perkele-VII> <55D22F77.5060807@gmail.com> Date: Mon, 17 Aug 2015 12:30:20 -0700 Message-ID: From: Martin Thomson To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a1141453607b636051d86d561 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 19:30:22 -0000 --001a1141453607b636051d86d561 Content-Type: text/plain; charset=UTF-8 Expect? No. That you sent an email is already highly useful. A PR makes feedback even more useful. For truly trivial stuff, rolling them up into a single PR is probably even more so. On Aug 17, 2015 12:01 PM, "Yaron Sheffer" wrote: > My original mail had some 15 comments, some trivial, some not. Do you > expect 15 PRs? > > Thanks, > Yaron > > On 08/17/2015 10:37 AM, Martin Thomson wrote: > >> On 17 August 2015 at 05:02, Ilari Liusvaara >> wrote: >> >>> >>> Actually, I think both should be 256 (256-byte expansion from AEAD >>> is already quite much). >>> >> >> >> Pull request or it didn't happen ;) >> >> --001a1141453607b636051d86d561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Expect? No. That you sent an email is already highly useful.=

A PR makes feedback even more useful.=C2=A0 For truly trivia= l stuff, rolling them up into a single PR is probably even more so.

On Aug 17, 2015 12:01 PM, "Yaron Sheffer&qu= ot; <yaronf.ietf@gmail.com&= gt; wrote:
My origi= nal mail had some 15 comments, some trivial, some not. Do you expect 15 PRs= ?

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 08/17/2015 10:37 AM, Martin Thomson wrote:
On 17 August 2015 at 05:02, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> w= rote:

Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite much).


Pull request or it didn't happen ;)

--001a1141453607b636051d86d561-- From nobody Mon Aug 17 16:37:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90D1B2FD9 for ; Mon, 17 Aug 2015 16:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 vyEYn8ktzBIG for ; Mon, 17 Aug 2015 16:37:17 -0700 (PDT) Received: from worker2.doodle.com (worker2.doodle.com [94.230.219.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9216C1B2FD5 for ; Mon, 17 Aug 2015 16:37:17 -0700 (PDT) Received: from worker2.doodle.com (localhost [127.0.0.1]) by worker2.doodle.com (Postfix) with ESMTP id CDDE092808A for ; Tue, 18 Aug 2015 01:37:15 +0200 (CEST) Date: Tue, 18 Aug 2015 01:37:15 +0200 (CEST) From: "Sean Turner (via Doodle)" To: tls@ietf.org Message-ID: <1233407271.1135045.1439854635841@worker2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1135044_1210181087.1439854635840" Archived-At: Subject: [TLS] Fall '15 TLS Interim X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Sean Turner List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 23:37:20 -0000 ------=_Part_1135044_1210181087.1439854635840 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, Sean Turner (turners@ieca.com) invites you to participate in the Doodle poll "Fall '15 TLS Interim." This is a doodle poll for a 2-day TLS interim meeting. We're currently planning for Seattle, Washington. The exact location in Seattle is still TBD, but we've already got two offers. Please indicate your availability in the poll by 2015-08-21. After reviewing the poll we'll get the more formal announcement out. Participate now https://doodle.com/vwq53h5em9igv35e?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/features?tlink=3DcheckOutLink&tmail=3Dpoll_invitecontac= t_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Sean Turner" has invited you to participate in the Doodle poll "Fall '15 TLS Interim." ---- Doodle is also available for iOS and Android. ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_1135044_1210181087.1439854635840 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =
=09
Sean Turner invites you to = participate in the Doodle poll "Fall '15 TLS Interim."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"Fall '15 TLS= Interim." =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09This is a doodle poll for a 2-day TLS interim meeting.= We're currently planning for Seattle, Washington. The exact location= in Seattle is still TBD, but we've already got two offers. Please ind= icate your availability in the poll by 2015-08-21. After reviewing the pol= l we'll get the more formal announcement out. =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date f= or meeting with a group of people. Learn more about how Doodle works.
=09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09You have received this e-mail because "Sean Turner&qu= ot; has invited you to participate in the Doodle poll "Fall '15 TL= S Interim." =09=09
=09
Doodle is also available for iOS and Android.
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_1135044_1210181087.1439854635840-- From nobody Mon Aug 17 17:00:41 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D691B2FE2 for ; Mon, 17 Aug 2015 17:00: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 L9tdF8CG2HeE for ; Mon, 17 Aug 2015 17:00:38 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470961B2FE5 for ; Mon, 17 Aug 2015 17:00:38 -0700 (PDT) Received: by ykdt205 with SMTP id t205so143005034ykd.1 for ; Mon, 17 Aug 2015 17:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=dL/RU6d4v/gknWo0udLpYT9bCJ9Lc8prVyTLUfDA+ME=; b=MA5HFIrIRWBxLE3tVmWwRADJNVL65fmRbuMbGvkTfn87JCC39H5iwj+hOBJ18pWIa2 DDYvB1XEkyK3EjR9hdkPRV/DJhZQAfxI6Q+YSmaV1zqPgdy/wPg7Hrfk9w1J117FTLgQ jC5n+6zaedC55pSgpVGAU/S6gkwZ33+GnsWoxv7p75BG7hJbejFKt8BGg8OaT6MqC4XK F1bT4+IO3ZB0Cp/XUdCL3uqFQ89erl91bWkp38TZsiCcJEjCvXuyFim8m8u+1dojNEAp iKyVvr5vb//dl+NsgY2zY7LwKj/IHkAbGv8SQsXSD30z+nPUkH2tsP518V+8M1N7REcH SRmQ== X-Received: by 10.170.199.7 with SMTP id q7mr4234772yke.66.1439856037596; Mon, 17 Aug 2015 17:00:37 -0700 (PDT) Received: from dave-laptop.localnet (pool-108-52-139-147.phlapa.fios.verizon.net. [108.52.139.147]) by smtp.gmail.com with ESMTPSA id d23sm14634439ywb.16.2015.08.17.17.00.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 17 Aug 2015 17:00:37 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 17 Aug 2015 20:00:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <55D1B5CC.1050005@gmail.com> In-Reply-To: <55D1B5CC.1050005@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201508172000.35844.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 00:00:39 -0000 On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote: > The record length field is limited by encrypted-length+2048. Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes". See: https://github.com/tlswg/tls13-spec/issues/55 > Handshake_failure alert seems to be synonymous with insufficient_security (and Sec. 6.2.1 proves it...). Can we clarify the difference, or deprecate one of them? See: https://github.com/tlswg/tls13-spec/pull/201/commits A PR for the typos would be appreciated. I'd suggest having the typos in a separate PR from any other proposed changes. Dave PS I recommend against citing sections by number. The numbers can change; the sections can change completely. Cite by draft number & section, or preferably via a link to a section in a page. Also note that there are a few different things that can be considered the "latest" draft, so always specify which one to be clear. (e.g. numbered draft, GitHub current draft, PR drafts, WIP branch drafts, etc.) From nobody Mon Aug 17 17:43:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E4B1B2AAA for ; Tue, 11 Aug 2015 16:15:54 -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 HmsWjmLbC95M for ; Tue, 11 Aug 2015 16:15:51 -0700 (PDT) Received: from mail01.rise-w.com (mail01.rise-w.com [88.116.105.226]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F6C1B2A95 for ; Tue, 11 Aug 2015 16:15:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail01.rise-w.com (Postfix) with ESMTP id E85BF40E43C; Wed, 12 Aug 2015 01:15:48 +0200 (CEST) Received: from [10.199.13.81] (unknown [12.238.56.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id D81AB40E431; Wed, 12 Aug 2015 01:15:43 +0200 (CEST) Message-ID: <55CA821B.9090101@rise-world.com> Date: Tue, 11 Aug 2015 19:15:39 -0400 From: Clemens Hlauschek User-Agent: mutt 1.5.23 (Plan 9) MIME-Version: 1.0 To: Peter Gutmann , "tls@ietf.org" References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 17 Aug 2015 17:43:04 -0700 Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 23:15:54 -0000 On 08/11/2015 02:05 PM, Peter Gutmann wrote: > Clemens Hlauschek writes: > >> I published a paper today on KCI-attacks in TLS. This might be of interest to >> the TLS WG. >> >> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek > > Some comments on this, it looks like it requires a "cert with static (EC)DH > key" in order to work, which would mean an X9.42 cert. Since no (public) CA > that I know of can handle or issue such certs, this probably provides a > reasonable amount of defence against this attack... Thanks for the critical reading. Actually, your point is touched upon in the paper. Instead of an ECDH certificate, an ECDSA certificate can be used by the attacker. The case for DH/DSS is different, and your point is valid for this latter case. I am working on a video showcasing the attack (Safari <-> Facebook), but if you decide that you still would not trust our claims made in the paper, it would be trivial to reproduce the attack: our MitM proof-of-concept implementation was realized with less than 10 patched lines of the openssl/stunnel codebase. See also RFC 4492: "Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations" > > In terms of the suggested countermeasures: > >> Set appropriate X509 Key Usage extension for ECDSA and DSS certificates, and >> disable specifically the KeyAgreement flag > > Since the keyUsage flags are widely ignored by implementations, this won't > provide the protection that the text implies. > In case of the vulnerable Safari / SecureTransport / Mac OS X clients, it does make a difference, so having correct X509 KeyUsage settings is the best (and only sensible for servers supporting ECDSA) recommendation for server-side mitigation, from our perspective. The facebook.com security teams very quickly implemented that change. While it is certainly true that keyUsage flags are ignored by many implementations (this is also mentioned in the paper), checking (it is ambiguous according to the TLS specs whether it is mandatory for ECDH, but it is mandatory for DH if the KeyUsage extension is present) seems to have become more widespread recently. Best, Clemens From nobody Wed Aug 19 08:56:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645631B2AA0 for ; Wed, 19 Aug 2015 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvMLPVPC4Wl0 for ; Wed, 19 Aug 2015 08:56:56 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D021B2A8D for ; Wed, 19 Aug 2015 08:56:56 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 272F32AA00; Wed, 19 Aug 2015 17:56:54 +0200 (CEST) X-purgate-ID: 152705::1439999814-00000CCB-9C7BB5DA/0/0 X-purgate-size: 739 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 18B2240422; Wed, 19 Aug 2015 17:56:54 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 0ECBA1A247; Wed, 19 Aug 2015 17:56:54 +0200 (CEST) In-Reply-To: To: Andrei Popov Date: Wed, 19 Aug 2015 17:56: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: <20150819155654.0ECBA1A247@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Commentary on the client authentication presentation slides 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, 19 Aug 2015 15:56:58 -0000 Andrei Popov wrote: > Hi Ilari, > >> >> What sort of usecase you have in mind for this? > > This is to support a fairly common website design where the landing > page does not require client auth, but subsequent request to a > protected resource triggers client authentication within an existing > TLS connection. > > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, > there is no renegotiation, so we need an alternative solution if we > want to support these existing sites over TLS1.3. While this might have been the structure of a few legacy sites, this will meet the axe longe before TLSv1.3 is done, because HTTP/2 prohibits renegotiation with TLSv1.2 as well. R.I.P. renegotiation. -Martin From nobody Fri Aug 21 12:44:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207C11ACD92 for ; Fri, 21 Aug 2015 12:44:24 -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_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqYqwuJlFt3B for ; Fri, 21 Aug 2015 12:44:22 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88771ACD8C for ; Fri, 21 Aug 2015 12:44:22 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id 474FFFB861F37; Fri, 21 Aug 2015 14:44:22 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 335AFFB861F15 for ; Fri, 21 Aug 2015 14:44:22 -0500 (CDT) Received: from [96.231.216.201] (port=49624 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZSsEf-0002DW-KR for tls@ietf.org; Fri, 21 Aug 2015 14:44:21 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <1233407271.1135045.1439854635841@worker2> Date: Fri, 21 Aug 2015 15:44:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2ED7FD5D-B5C3-41F9-A466-1F6EEE7A1130@ieca.com> References: <1233407271.1135045.1439854635841@worker2> To: "" X-Mailer: Apple Mail (2.1878.6) 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.216.201 X-Exim-ID: 1ZSsEf-0002DW-KR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:49624 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] Fall '15 TLS Interim X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 19:44:24 -0000 doodle has spoken. The interim is going to be held 21-22 September. = Expect the formal announcement on or before Monday. Notes: 1. The exact location in Seattle is being discussed now and we=92ll let = you know as soon as it=92s decided. 2. For those who can=92t make it, I=92ll make sure to request a WebEx = session so that people can dial-in. spt On Aug 17, 2015, at 19:37, Sean Turner (via Doodle) = wrote: > =09 > Hi there, > =20 > Sean Turner (turners@ieca.com) invites you to participate in the = Doodle poll "Fall '15 TLS Interim." > This is a doodle poll for a 2-day TLS interim meeting. We're currently = planning for Seattle, Washington. The exact location in Seattle is still = TBD, but we've already got two offers. Please indicate your availability = in the poll by 2015-08-21. After reviewing the poll we'll get the more = formal announcement out. > Participate now =09 > =09 > What is Doodle? Doodle is a web service that helps Sean Turner to find = a suitable date for meeting with a group of people. Learn more about how = Doodle works. > You have received this e-mail because "Sean Turner" has invited you to = participate in the Doodle poll "Fall '15 TLS Interim." > Doodle is also available for iOS and Android. > =20 > Doodle AG, Werdstrasse 21, 8021 Z=FCrich >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Aug 21 15:32:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EA91ACEA0 for ; Fri, 21 Aug 2015 15:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofi4P9wqslNs for ; Fri, 21 Aug 2015 15:32:16 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73BFB1ACE99 for ; Fri, 21 Aug 2015 15:32:16 -0700 (PDT) Received: by ykll84 with SMTP id l84so84872900ykl.0 for ; Fri, 21 Aug 2015 15:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=YrjCusNZdgLr6GawV+U+6iz3d1S07Z+XFYfq770HIMc=; b=NNZfhVn+Hs3EL/SH8Xf9qo5ZY6uNiZ/iobvwE6UoAh4d/WRiZsbA98wwLK5nNkg/as HlS1Cn5IVd06EGM3+eqRt1/Z+NgA1EjyFQJk6dPm9lEJs7x/Dpi8LiJ78gBXfGT6oPKk lrW6UtAEUrtjs+z+RmRpzOWn7SvavCiFeJDwDI3Hj3vSRqbPQTaXHwWQ1k68N/8EJkOz B4miVwPWr55Zj9paoqQJuh87u6H531NMEuEX5ytD+Fw3rdXQGaPXlrucR2oqK0Lzqh74 JXDm3BHFr7Juy30gS0Ljzo43puqvD3yA9OH+QKKCaZzGVeqW2EfrF96HYo1T6N/bHhA6 eQbA== X-Received: by 10.129.135.71 with SMTP id x68mr15406509ywf.124.1440196335849; Fri, 21 Aug 2015 15:32:15 -0700 (PDT) Received: from dave-laptop.localnet (pool-108-52-139-147.phlapa.fios.verizon.net. [108.52.139.147]) by smtp.gmail.com with ESMTPSA id l68sm8868830ywd.49.2015.08.21.15.32.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 21 Aug 2015 15:32:15 -0700 (PDT) From: Dave Garrett To: Tom Ritter Date: Fri, 21 Aug 2015 18:32:13 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201505171532.31109.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508211832.14227.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [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: Fri, 21 Aug 2015 22:32:18 -0000 On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: > On 17 May 2015 at 14:32, Dave Garrett wrote: > > Is it really necessary to have a separate application_data_padded content type? It'd be simpler to just keep using existing types but amend it with a padding field and require it always be used at minimum to pad up to the nearest multiple of N-bytes. (something low for the default) Additional padding would be optional, but all data would get some minimum. > > That was the first proposal, but the extra bytes on every message for > people who weren't using padding were deemed to be prohibitive. Wouldn't it be simpler to just have an optional padding vector that exists only if padding is negotiated? (we already have one optional field with extensions in the hello messages) A simple method to negotiate would be to add a new HandshakeType with a couple flags, one to indicate that the endpoint will be sending padded messages and another to indicate that it's willing to receive padded messages. Endpoints could declare padding with this message and use it until its peer sends a message requesting otherwise. This sort of scenario would have the additional benefit of not stating the existence of padding in the clear. Dave From nobody Sat Aug 22 12:37:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762561B2C9F for ; Sat, 22 Aug 2015 12:37:05 -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 C8_svWrOVaoI for ; Sat, 22 Aug 2015 12:37:04 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 04B311ACD47 for ; Sat, 22 Aug 2015 12:37:04 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id E7AA5F24129; Sat, 22 Aug 2015 15:36:52 -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 3lCssatQ7xkE; Sat, 22 Aug 2015 15:35:35 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 323C4F24128; Sat, 22 Aug 2015 15:36:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <201508211832.14227.davemgarrett@gmail.com> Date: Sat, 22 Aug 2015 15:36:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201505171532.31109.davemgarrett@gmail.com> <201508211832.14227.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF TLS Subject: Re: [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, 22 Aug 2015 19:37:05 -0000 Dave: > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: >> On 17 May 2015 at 14:32, Dave Garrett wrote: >>> Is it really necessary to have a separate application_data_padded = content type? It'd be simpler to just keep using existing types but = amend it with a padding field and require it always be used at minimum = to pad up to the nearest multiple of N-bytes. (something low for the = default) Additional padding would be optional, but all data would get = some minimum. >>=20 >> That was the first proposal, but the extra bytes on every message for >> people who weren't using padding were deemed to be prohibitive. >=20 > Wouldn't it be simpler to just have an optional padding vector that = exists only if padding is negotiated? (we already have one optional = field with extensions in the hello messages) >=20 > A simple method to negotiate would be to add a new HandshakeType with = a couple flags, one to indicate that the endpoint will be sending padded = messages and another to indicate that it's willing to receive padded = messages. Endpoints could declare padding with this message and use it = until its peer sends a message requesting otherwise. This sort of = scenario would have the additional benefit of not stating the existence = of padding in the clear. I like the idea that the presence or absence of padding in the = ciphertext is hidden in your proposal. Is there really an need to = toggle it on and off? Russ From nobody Sat Aug 22 17:28:53 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B31A701A for ; Sat, 22 Aug 2015 17:28:50 -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 Yx4r7ahG0OcB for ; Sat, 22 Aug 2015 17:28:48 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B8C1A7017 for ; Sat, 22 Aug 2015 17:28:48 -0700 (PDT) Received: by ykll84 with SMTP id l84so103935812ykl.0 for ; Sat, 22 Aug 2015 17:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=aAULMqjmU/5LjEZL1QzcP7OF8BeNA+Q2IGCaMAmntWk=; b=E8Y2/+0hPue2ZpFC24jU995pf7ykCNCZVKSg0TURw2ZJsKUXwN0M8LRvhu8hy00C/q lUWfLKZvmd0SrRXjSam8DhBXCk/6sZPM0+ChK1TWYpRsbtuTrzXfm/UBOy6Fw5V2ETE6 SvITZiYH2Hf7fmP5+1U2BXI+MDwVDJOoyCYvY00N1bQtGlu7VKKcjQnk7Ksyo9erDZzZ ldrz8faUseX6djclhrYskFrnT9Fg8AAUajDWKngyDv/oAIteraRQ6DTpVVoZLjiBr1Ku 6UNqLs2HEEszem5F36I56x+wkjeQa6l/yTuNpGFxJNS4oBqe1PlQRV34aYMv6mBPI/4j jaAA== X-Received: by 10.170.41.2 with SMTP id 2mr22023945ykj.20.1440289728025; Sat, 22 Aug 2015 17:28:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-108-52-139-147.phlapa.fios.verizon.net. [108.52.139.147]) by smtp.gmail.com with ESMTPSA id g197sm12419121ywb.46.2015.08.22.17.28.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 22 Aug 2015 17:28:47 -0700 (PDT) From: Dave Garrett To: Russ Housley Date: Sat, 22 Aug 2015 20:28:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201508211832.14227.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201508222028.46145.davemgarrett@gmail.com> Archived-At: Cc: IETF TLS Subject: Re: [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, 23 Aug 2015 00:28:50 -0000 On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote: > > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote: > >> On 17 May 2015 at 14:32, Dave Garrett wrote: > >>> Is it really necessary to have a separate application_data_padded con= tent type? It'd be simpler to just keep using existing types but amend it w= ith a padding field and require it always be used at minimum to pad up to t= he nearest multiple of N-bytes. (something low for the default) Additional = padding would be optional, but all data would get some minimum. > >>=20 > >> That was the first proposal, but the extra bytes on every message for > >> people who weren't using padding were deemed to be prohibitive. > >=20 > > Wouldn't it be simpler to just have an optional padding vector that exi= sts only if padding is negotiated? (we already have one optional field with= extensions in the hello messages) > >=20 > > A simple method to negotiate would be to add a new HandshakeType with a= couple flags, one to indicate that the endpoint will be sending padded mes= sages and another to indicate that it's willing to receive padded messages.= Endpoints could declare padding with this message and use it until its pee= r sends a message requesting otherwise. This sort of scenario would have th= e additional benefit of not stating the existence of padding in the clear. >=20 > I like the idea that the presence or absence of padding in the ciphertext= is hidden in your proposal. Is there really an need to toggle it on and o= ff? Toggling solves the undesired bandwidth use concern stated by Tom by making= it fully optional on both sides. The even simpler route of just having to = check if there's bytes in the encrypted fragment other than the payload wou= ld avoid a little bit of complexity, but with no way for an endpoint to say= no to increased bandwidth usage that it doesn't want to or can't handle. G= iven this constraint, I'd favor either easily toggleable or always-on, rath= er than a middle-ground where implementations won't know what they're going= to get and can't do anything about it. A footnote: Negotiating via an extension is probably not a good idea becaus= e client extensions will generally be in the clear. That's why I suggest a = simple message instead. (there's no need to pad the cleartext hello, so it'= s fine to wait until record protection is available) Note that I don't thin= k allowing this to be decided after the handshake is a good idea. A more generalized way to handle throttling padding would be to set a low d= efault and require each endpoint to send a message with a different value, = in max bytes per record (or second, or both) of padding permitted, in order= to use a different amount. Each endpoint could easily arbitrarily throttle= its downstream padding bandwidth independently, if need be. I'm curious as to how much of a range would actually be useful, though. For= actually good protection, you'd really want to pick a stable bandwidth and= essentially hold it; keep up/download rates constant or following some con= sistent pattern with a combination of possibly throttled data and padding s= uch that the data length and time is completely protected and the stream is= 100% opaque to an observer. I wouldn't expect this to be all that popular,= though, as it would be a bandwidth hog in many cases. A middle-ground migh= t involve also specifying a max bytes allowed in between data bursts to hid= e the peaks, but now we're getting more complicated than I think we want he= re if we go any further. (and beyond what I know anything about) The curren= t proposal says that padding algorithms are outside of the scope here, but = I think adding this as a built-in feature without coming up with some easil= y usable default (even if not particularly advanced) is a mistake that will= cause this feature to be largely unused. Dave From nobody Sat Aug 22 18:40:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA911A89FC for ; Sat, 22 Aug 2015 18:40:06 -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 HCAgbDB2nKzT for ; Sat, 22 Aug 2015 18:40:03 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B153D1A89FD for ; Sat, 22 Aug 2015 18:40:02 -0700 (PDT) Received: by wicne3 with SMTP id ne3so43150139wic.0 for ; Sat, 22 Aug 2015 18:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fj2WJXMPqB6fSNYoSaklOEhcOty5OLSwEF6DdBcaj9Q=; b=JvTzYmm1DTp946gvK3o/isFffJ8HhHAlf7gOoE9f7XRJjKgBqAgvqAJXFztrd0+y8s IqCqcIS7kO7VM3eg+rF+zS3PYUjs3R76w1rmOlmArHUYb+jAEL8E55kmIdl0xB09lXnK Jv7Lgw6/o12zcb8jlgqW0czeJioFkrgzcapR5mHTraDTNL3Jxz5bGToSYinj7zl/zFNH EST6wlwTXV4GDxrareNC4XRiji75tCuRhrIp6y8EFJbOLc2qpbuhe74UP8lsteYupClE bQUFJYUS6oc7GF/3TbeeJmuTxSIsLXlfxoWvaqeaPFKblhWBrsGCsAp8uiTUbSP8x87J NWBA== MIME-Version: 1.0 X-Received: by 10.180.219.41 with SMTP id pl9mr17849563wic.30.1440294001285; Sat, 22 Aug 2015 18:40:01 -0700 (PDT) Received: by 10.28.132.11 with HTTP; Sat, 22 Aug 2015 18:40:01 -0700 (PDT) In-Reply-To: <4f1c28360a0441219cbb21799ecb88be@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <55CA821B.9090101@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4ADDD17@uxcn10-5.UoA.auckland.ac.nz> <20150817151814.GE24426@mournblade.imrryr.org> <9A043F3CF02CD34C8E74AC1594475C73F4ADDF25@uxcn10-5.UoA.auckland.ac.nz> <4f1c28360a0441219cbb21799ecb88be@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Sat, 22 Aug 2015 18:40:01 -0700 Message-ID: From: Watson Ladd To: Rich Salz Content-Type: multipart/alternative; boundary=001a1135fbc651a07d051df0949a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS and KCI vulnerable handshakes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Aug 2015 01:40:06 -0000 --001a1135fbc651a07d051df0949a Content-Type: text/plain; charset=UTF-8 On Aug 17, 2015 9:08 AM, "Salz, Rich" wrote: > > > I was more interested in the motivation. Same for Apple, > > why would you implement something that pretty much no-one else (at the > > time) supported, and for good reason? > > Perhaps because this was a year before Snowden and the mindset was unquestioning complete RFC implementation? We've known since at least 2001 that the TLS RFC contains misfeatures. Core OpenSSL developers wrote documents detailing how TLS connections can be attacked through the use of these features, documents still sitting on the OpenSSL website, dated 2004. These documents were not brought up on the TLS mailing list, or at TLS meetings. It's not until 2011 that we started to see fixes for these problems. Why wasn't the attitude always one of maintaining security for users? If Snowden told you the Internet was a scary place, you weren't paying attention. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1135fbc651a07d051df0949a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 17, 2015 9:08 AM, "Salz, Rich" <rsalz@akamai.com> wrote:
>
> > I was more interested in the motivation.=C2=A0 Same for Apple, > > why would you implement something that pretty much no-one else (a= t the
> > time) supported, and for good reason?
>
> Perhaps because this was a year before Snowden and the mindset was unq= uestioning complete RFC implementation?

<rant>

We've known since at least 2001 that the TLS RFC contain= s misfeatures. Core OpenSSL developers wrote documents detailing how TLS co= nnections can be attacked through the use of these features, documents stil= l sitting on the OpenSSL website, dated 2004.=C2=A0 These documents were no= t brought up on the TLS mailing list, or at TLS meetings. It's not unti= l 2011 that we started to see fixes for these problems. Why wasn't the = attitude always one of maintaining security for users?

If Snowden tol= d you the Internet was a scary place, you weren't paying attention.

=

</rant>

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

--001a1135fbc651a07d051df0949a-- From nobody Mon Aug 24 09:05:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E61A8749; Mon, 24 Aug 2015 09:05:12 -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 mZbIpGSNfdRh; Mon, 24 Aug 2015 09:05:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3DF1A872A; Mon, 24 Aug 2015 09:05:11 -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: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150824160511.13493.46050.idtracker@ietfa.amsl.com> Date: Mon, 24 Aug 2015 09:05:11 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] TLS WG Interim Meeting: 21-22 September 2015 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: Mon, 24 Aug 2015 16:05:12 -0000 The Transport Layer Security (tls) working group will hold a face-to-face interim meeting at Microsoft in Redmond, Washington, USA on 21-22 September 2015 from 9am-5pm. Date: 21-22 September 2015 Time: 9am-5pm Location: Redmond, Washington, USA Additional information, including agenda and more venue information will be announced on the TLS WG mailing list: https://mailarchive.ietf.org/arch/search/?email_list=tls From nobody Mon Aug 24 09:39:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6831A889D for ; Mon, 24 Aug 2015 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeJsYzmTWkB8 for ; Mon, 24 Aug 2015 09:39:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3EF1ACD63 for ; Mon, 24 Aug 2015 09:39:44 -0700 (PDT) Received: from [192.168.131.138] ([80.92.122.31]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lkwpt-1YvgUd1J5B-00anbq; Mon, 24 Aug 2015 18:39:42 +0200 Message-ID: <55DB489C.80505@gmx.net> Date: Mon, 24 Aug 2015 18:38:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Martin Thomson , Joseph Salowey References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0UN3E5u2kDco2IS2B1rXE1b9tMW6h9FCk" X-Provags-ID: V03:K0:RpCh6lsCjc4FXOUU4rQ0ZRpVnyFhJ8RtwdkIY7DlEkXr95+PN/Y AeUrZQ/G7ukwBnlaYTvIOsAPP8K8aCRR9xUbbSkdr7UN/RqeIS0nrzAwM+XFOCkvD8WmwOw GBY3aZVENk7F3iA7NQNuiCwJvwbnZIQSkrW92zs05bzrrF440BNTXzVakg5iaNeDY6580yZ 5fX4/kncOK18E0ylneQHA== X-UI-Out-Filterresults: notjunk:1;V01:K0:030+xPHA/qY=:VW+5mkSh6/QX8qKoXNFlYT 7s+iV6OzA6yQevPjCtWXTiF79rYVp8R4Gsyq5Cx4pJB/27gyDRuLeptUuzpKvBzca0KWf0x8G kXGx/YJFKKIeHTeIjsM3SCMSvWG8diMEFisxRve/pAEsbR+/t1I5a2SDrK36Xr8X9rMDbq9o9 LeBhy/Bj9m4JDt6ChUUaq/1E0U/RYtoCvWYxDnkv+N8hQeH8b+0fUQqp6tdnIWwNazTwPL0KL xByfEw2vxPoEu7+ouPuvEMWRpGhko/SMzNZafWtHcgjvpmV16lfRI7cNvSMu+iUzM28KQV8WL hPZhgVu3FrkQH4YkTkHpedpoChG1doGjEbkipK4vaMOqjnKtnmj9UnkT1jgbzzN1q0ld8HiXv ol5VGC58QcTyl/Mikuu1miHv/vmJyR41/ZSxf0poLcDo9VGGYg9tnyTY+x/CnsRmLnxuh3/sq nl9AopxDJ3QXo6rnjt5Y3MDwnq2edeOlfykiGM/lo+R4DRoZCHO7w13BH0HIsG5aHtEmKMbK9 Lwro22DEY9P7ISw0ueRcAULav5StJSyfG/cW4peOboVyK0x6sv13V4ajJu/eGNos0hHOCl4Or NYWrdrpSD/l4ETwQNZU4wz9o/ZBm3UYkYYBAV/hI4MJ6yHAs9f6MDCoTsNoPX1Exc448a4YQA zh0BORixzcohOr4eR2S2Y8arOp8p0eixJBPret+SMTQEc1CUCtMK7K9M/fBf7GyE4yZM5oSOs IVY1RT6UiXRxAfdy Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 16:39:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0UN3E5u2kDco2IS2B1rXE1b9tMW6h9FCk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Martin, thanks for your review. On 08/06/2015 10:33 PM, Martin Thomson wrote: > I've read this draft before, but this is considerably different to > what I read, and I haven't been following the discussion, so consider > this as a review with fresh eyes. >=20 > First the high points. I think that this is useful, the right scope, > and reasonably well formulated. I have a couple of minor points >=20 > Figure 2 is in error: it shows CertificateRequest instead of Certificat= e. Good catch. A copy-and-paste error. >=20 > I'd like to see the document explicitly note that msg_type and length > from the handshake message are not covered by the hash. The > description of what is covered is a little too terse (and badly > formatted). There are multiple message type / message length fields included in the message and I am not sure which of those you rare referring to. The msg_type and msg_length from the record layer is not part of the fingerprint calculation. The spec only focuses on the certificate message in Section 4.1 and the CertificateRequest message in Section 4.2. These message do, however, also contain length information. I included an example into the document. See Appendix A: https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached= -info/draft-ietf-tls-cached-info-20.txt >=20 > I'm not sure that I like the lack of both negotiation and signaling > for the hashes that are used here. We had a negotiation capability in earlier versions of the document but it appeared to be an overkill. What is there now is essentially an indication of the hash algorithm based on what the client presents with the CachedInformationType structure. If you need support for a new algorithm then add a new type (and the implementation). We could make it easier to add new algorithms (via the expert review process). We could also register another algorithm already now, if found necessary. > Though I think the chances of a > collision being found, or that a collision would lead to an attack, > are slim, I would rather see this use the PRF hash so we have at least > that much flexibility. While there is indeed a possibility for hash collisions those will still lead to a failed exchange since the TLS server will not possess the correct private key that corresponds to the cached certificate. > If the current design is retained, I would > like to see a little discussion of this in the document. A little > analysis of the properties we expect the hash to provide would also be > good. >=20 > I think that truncated hashes might be advantageous from the server > side. Given that the server only uses hashes to identify which of the > offered (available, known?) cached information is in use, is there any > reason you can't save additional space by arbitrarily truncating the > hash? In many cases I would imagine that the client would be offering > only one option and even if there were a small number of options > presented, a single byte would suffice to disambiguate. >=20 > I'm trying to think why you might want the full-length hash on the > client side, but I believe that the only problem there is that there > might be a collision between the certificates that a server might > offer if you truncate too aggressively. The connection still relies > on the server presenting proof of knowledge of a key that the client > extracts from a certificate bound to the server identity, so I believe > that it would be equally secure if you removed all mention of > certificates from the protocol. And that makes me nervous, because > I'm fairly sure that Karthik will tell me that I'm wrong very shortly; > since we've put in a lot of work to cover key fields in the handshake > hash, and I'm concerned that this could be exploited somehow. >=20 > The more I think about this, the more I think that we need a little > more analysis on this point (i.e., what properties the hash function > needs to provide and why). If it has already happened, mention of > that in the security considerations is needed. >=20 > (I think that truncation on the server side is safe if the client uses > a strong hash function to identify the certificate, but I'm frequently > wrong about these things.) >=20 There are three designs possible for referencing the cached state, namely= 1) The client creates the reference. This is the current approach. The client creates a reference (via the use of the hash function) and tells the server that it has seen certain parameters before and that there is no need to re-transmit them. 2) The server creates the reference. In this design the server allocates the reference and sends it to the client. The client 3) There is no reference at all. The client just tells the server not to send certain payloads because it has cached something already previously. While the server does not get told what has been cached the worst thing that can happen is that the exchange fails (in which case the client has to fall back to a full exchange). Which approach do you prefer? We had various iterations of this throughout the lifetime of the document. Independently of these three approaches it is certainly true that fewer bytes transmitted over the wire are preferable. Ciao Hannes >=20 > On 6 August 2015 at 10:24, Joseph Salowey wrote: >> Hi Folks, >> >> This is the Working Group last call for draft-ietf-tls-cached-info-19.= This >> document has undergone modification since last WGLC so another WGLC is= >> appropriate. This document is a dependency for the DICE working group= >> TLS/DTLS profile. Please send your comments to the TLS list by Septemb= er 2, >> 2015. >> >> Thanks, >> >> J&S >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --0UN3E5u2kDco2IS2B1rXE1b9tMW6h9FCk 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: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV20icAAoJEGhJURNOOiAtYYYH/j7qBWACRwCA3ZugXTfu3OW/ MW4m1nnbdcRPLJeyp1b4qIbDL/myJZGIjtkmPp+EgaMH6D4jAHWOjNtP+rlG/AA7 P2gB4D8cTNxz5NPg+7bHVkv+YIPzt06cwHpAJaef9dIW+oFlO9HNC/Zjf8lwpStx fqzZIIrfEou6KTTjs5EIgM0NiXbvFkdfXBo4WmcmVMPnE7ekSKrXPGoyJuySgi2I lJ4FuRNPC/oltg59YtCvQ3BZd4WyVS8195O0IyFpKpeBpC4uh6cU6kART+ltr0OI okDsDUnR5aPUsj6Wyi/QnApdhyv8tZT/ttTp6OkjrYmsZqZrXzHm98maJLCVAFE= =NozV -----END PGP SIGNATURE----- --0UN3E5u2kDco2IS2B1rXE1b9tMW6h9FCk-- From nobody Mon Aug 24 10:29:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729F41ACE17; Mon, 24 Aug 2015 10:29:22 -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 TyC7WMyEMFRq; Mon, 24 Aug 2015 10:29:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABD21ACDEE; Mon, 24 Aug 2015 10:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150824172921.19492.89459.idtracker@ietfa.amsl.com> Date: Mon, 24 Aug 2015 10:29:21 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-padding-02.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, 24 Aug 2015 17:29:22 -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 : A TLS ClientHello padding extension Author : Adam Langley Filename : draft-ietf-tls-padding-02.txt Pages : 4 Date : 2015-08-24 Abstract: This memo describes a TLS extension that can be used to pad ClientHello messages to a desired size. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-padding/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-padding-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-padding-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 24 11:35:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10E1AD357 for ; Mon, 24 Aug 2015 11:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1riJIZRoPxp7 for ; Mon, 24 Aug 2015 11:35:48 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171DC1AD355 for ; Mon, 24 Aug 2015 11:35:48 -0700 (PDT) Received: by qkbm65 with SMTP id m65so80928654qkb.2 for ; Mon, 24 Aug 2015 11:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4DDvp+7+qEp4ZtayWip4017tFypV5kZQzxLCBgA/Ufc=; b=vmc8320omolt8vZ4xiVG4UBntscuXpltvR4eOh7vX2F+pyvwSCnuuuOJTnSrUYdTHr eTCLq23ilUG4lGZ25q5Aqvc8mB7UlJZgWp2BuC8zZAiOKOzn7nL7OpHf9mDf+6S5kAD4 an+YoSFJSrr+DS3MKwSLK+U0H3+StapBNEgDGEsrer6IKMdJCdeLsSISX+dNOSX6O9Cj XrKTAfQNMdGtGafasw3hjZtU63AbG6aTRl8H4zqnzXLDYWgZMjTUku6eZjHpZqgvuILy Ty+eB0TcMQuILkVZK0RIjyFw1enlr5q8PaxVbaahTd53M6/Rs1Hpictz1a9G7OBLcTuS hEFw== MIME-Version: 1.0 X-Received: by 10.13.206.67 with SMTP id q64mr20113064ywd.154.1440441346501; Mon, 24 Aug 2015 11:35:46 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Mon, 24 Aug 2015 11:35:46 -0700 (PDT) In-Reply-To: <55DB489C.80505@gmx.net> References: <55DB489C.80505@gmx.net> Date: Mon, 24 Aug 2015 11:35:46 -0700 Message-ID: From: Martin Thomson To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] WGLC for draft-ietf-tls-cached-info-19 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 18:35:50 -0000 Hi Hannes, On 24 August 2015 at 09:38, Hannes Tschofenig wrote: >> I'd like to see the document explicitly note that msg_type and length >> from the handshake message are not covered by the hash. The >> description of what is covered is a little too terse (and badly >> formatted). > > There are multiple message type / message length fields included in the > message and I am not sure which of those you rare referring to. > > The msg_type and msg_length from the record layer is not part of the > fingerprint calculation. The spec only focuses on the certificate > message in Section 4.1 and the CertificateRequest message in Section > 4.2. These message do, however, also contain length information. I refer to the msg_type and length from the handshake message, which are the only things with that name in the TLS spec. You use the name `CertificateRequest`, which leads me to conclude that you mean the struct identified as such, which is *inside* the handshake message. (I'm fine with hashing that part, I just want to have it be very clear.) > I included an example into the document. See Appendix A: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-20.txt This includes the msg_type and length. Which means that you should talk about hashing `Handshake` instead. >> I'm not sure that I like the lack of both negotiation and signaling >> for the hashes that are used here. > > We had a negotiation capability in earlier versions of the document but > it appeared to be an overkill. Yeah, that's why I'm thinking that this can use the PRF hash. > What is there now is essentially an indication of the hash algorithm > based on what the client presents with the CachedInformationType > structure. I don't see that anywhere. The algorithm seems to be fixed to SHA-256 in the current draft (and your copy). >> Though I think the chances of a >> collision being found, or that a collision would lead to an attack, >> are slim, I would rather see this use the PRF hash so we have at least >> that much flexibility. > > While there is indeed a possibility for hash collisions those will still > lead to a failed exchange since the TLS server will not possess the > correct private key that corresponds to the cached certificate. Right, this might be all that the analysis requires. >> If the current design is retained, I would >> like to see a little discussion of this in the document. A little >> analysis of the properties we expect the hash to provide would also be >> good. >> >> I think that truncated hashes might be advantageous from the server >> side. Given that the server only uses hashes to identify which of the >> offered (available, known?) cached information is in use, is there any >> reason you can't save additional space by arbitrarily truncating the >> hash? In many cases I would imagine that the client would be offering >> only one option and even if there were a small number of options >> presented, a single byte would suffice to disambiguate. >> >> I'm trying to think why you might want the full-length hash on the >> client side, but I believe that the only problem there is that there >> might be a collision between the certificates that a server might >> offer if you truncate too aggressively. The connection still relies >> on the server presenting proof of knowledge of a key that the client >> extracts from a certificate bound to the server identity, so I believe >> that it would be equally secure if you removed all mention of >> certificates from the protocol. And that makes me nervous, because >> I'm fairly sure that Karthik will tell me that I'm wrong very shortly; >> since we've put in a lot of work to cover key fields in the handshake >> hash, and I'm concerned that this could be exploited somehow. >> >> The more I think about this, the more I think that we need a little >> more analysis on this point (i.e., what properties the hash function >> needs to provide and why). If it has already happened, mention of >> that in the security considerations is needed. >> >> (I think that truncation on the server side is safe if the client uses >> a strong hash function to identify the certificate, but I'm frequently >> wrong about these things.) >> > There are three designs possible for referencing the cached state, namely > > 1) The client creates the reference. > 2) The server creates the reference. > 3) There is no reference at all. I'm not suggesting that you change the design, just provide a description of the properties that it provides - and those that it relies on. On the surface at least, it seems OK to rely on a weak guarantee of collision resistance from the hash. Failure only results in handshake failure, after which the client can fall back. That suggests that a truncated hash output could be used, potentially saving quite a few bytes in the client's first flight. I'd like to do that if it is possible. However, I'm concerned that eliding identity will lead to a weakness somewhere. For instance, if the client uses a shorter hash, then the server might pick up different certificates. Or, it means that identity is not bound to the session hash as directly. If, as you say, we can rely on this being a direct selector for a private key where the security is bound to that private key, then maybe it's OK. From viktor.s.wold.eide@gmail.com Mon Aug 24 13:57:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1181A8766 for ; Mon, 24 Aug 2015 13:57:35 -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 cmqji1Er2D0I for ; Mon, 24 Aug 2015 13:57:34 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B061A1C02 for ; Mon, 24 Aug 2015 13:57:33 -0700 (PDT) Received: by iods203 with SMTP id s203so163920004iod.0 for ; Mon, 24 Aug 2015 13:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=DSvw1o/mVWQRYM2xgkz20CJAzB0qfFt0NP6dWT6HmTY=; b=pOXNWxkFZMKSwFjTODoQSjJrvfjUqXPTG1PIF5Ad4RYXg105Zbkk+fBXZi1bKIqPPD EZnK8bUZP+JKNG4Zw/MKy7KR9Skp6tZIrIrUGLd2gwtceoMTOhKC2W9J+b3xqKsq++jB cFNG7Of7s/+ADa9MoqA+a3LWb+oCFfURtIH93vd/egMOvKzv3iKmZeAMa3KBqs5L+fw4 TtxaR4zW3jeQW7vJh545QMgHKlYKbGhhqYrgS5hCGsLJYUTk7zECnaxjLXJJdxvms2XV Ue7X+8cU2wdhG9z8jjnmP9VyWw3vz0JOBX6JeyF8k+/Bsn1c3+QaPCTWRxIYg1/RT+nv CE1g== X-Received: by 10.107.151.194 with SMTP id z185mr21076404iod.63.1440449853215; Mon, 24 Aug 2015 13:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.4.210 with HTTP; Mon, 24 Aug 2015 13:56:53 -0700 (PDT) From: "Viktor S. Wold Eide" Date: Mon, 24 Aug 2015 22:56:53 +0200 Message-ID: To: TLS@ietf.org Content-Type: multipart/alternative; boundary=001a1140e36ad15d11051e14ddc4 Archived-At: Subject: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 24 Aug 2015 21:12:25 -0000 --001a1140e36ad15d11051e14ddc4 Content-Type: text/plain; charset=UTF-8 Hi, I am looking for a way to achieve identity hiding for DTLS 1.2, which also hopefully can be used in (D)TLS 1.3, when available. >From what I understand, for (D)TLS 1.2 it would be possible to perform an anonymous unencrypted handshake and then to renegotiate the connection with authentication within the encrypted channel, e.g., according to the expired draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation will be removed in the upcoming 1.3 version. What is likely to be the recommended way to achieve identity hiding for (D)TLS 1.3, if any? [1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012 [2] The Transport Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07 Best regards Viktor S. Wold Eide --001a1140e36ad15d11051e14ddc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am looking for a w= ay to achieve identity hiding for DTLS 1.2, which also hopefully can be use= d in (D)TLS 1.3, when available.

From what I understand, for (= D)TLS 1.2 it would be possible to perform an anonymous unencrypted handshak= e=20 and then to renegotiate the connection with authentication within the encry= pted channel, e.g., according to the expired draft [1]. From the latest TLS= 1.3 draft [2] it appears that renegotiation will be removed in the upcomin= g 1.3 version.

What is likely to be the recommended way t= o achieve identity hiding for (D)TLS 1.3, if any?

[= 1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transpor= t Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07

Best regards
Viktor S. Wold Eide

--001a1140e36ad15d11051e14ddc4-- From nobody Mon Aug 24 14:18:03 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D981A88E1 for ; Mon, 24 Aug 2015 14:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJRI1ZScWDeT for ; Mon, 24 Aug 2015 14:18:01 -0700 (PDT) Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8251A8999 for ; Mon, 24 Aug 2015 14:18:01 -0700 (PDT) Received: by vkm66 with SMTP id 66so64168421vkm.1 for ; Mon, 24 Aug 2015 14:18:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0giYE772WoWqs/PiwhXEEXRt0Y9xMej56+aROpRjcZA=; b=HMjmRP6nGTW6a4C/lqgrdu57NIFBzI4GZQM9PXlmOO5xg0lw2U5kdevqokZuuqf9pG rCCyBGdsPeZ7kn1sTFJgKMNEPqmRE71mB3bz6stpV2tu3+uksvGV8e16qRI69724kr9v qNuSEd3pIkUajxbIshhTxcNeW9KGsQD0iJP96MRN/vEl6rqLhRaFo7TLXcAWdhV+Z1zg A2PndN5duW9zsVLeqViH6sm3zvuP8KXx1suctw1ItlTpQNcG3hVm029p/fSkZmTlZisT AQppfPrnAlVpM0Bdwwv32c+fwrmpVBb/OncCEw41A2dCDXxCLKOHGIj+HDWjEIRHzUmX Vf1g== X-Gm-Message-State: ALoCoQkX/n8vFobRFTwKprCV0YVvLVdsbQR6DwAHIngijONKIqcoRW8vJqHhDxMo31N9LwGTBOao X-Received: by 10.52.166.168 with SMTP id zh8mr15463188vdb.65.1440451080148; Mon, 24 Aug 2015 14:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.133.19 with HTTP; Mon, 24 Aug 2015 14:17:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 24 Aug 2015 14:17:20 -0700 Message-ID: To: "Viktor S. Wold Eide" Content-Type: multipart/alternative; boundary=089e0163417cf2f208051e1526e5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 24 Aug 2015 21:18:02 -0000 --089e0163417cf2f208051e1526e5 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < viktor.s.wold.eide@gmail.com> wrote: > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > TLS 1.3 encrypts both the client's and server's certificates already. The server's certificate is secure only against passive attack. The client's is encrypted with a key that the client can authenticate as belonging to the server. -Ekr --089e0163417cf2f208051e1526e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide = <vikto= r.s.wold.eide@gmail.com> wrote:
Hi,

I am looking fo= r a way to achieve identity hiding for DTLS 1.2, which also hopefully can b= e used in (D)TLS 1.3, when available.

From what I understand, = for (D)TLS 1.2 it would be possible to perform an anonymous unencrypted han= dshake=20 and then to renegotiate the connection with authentication within the encry= pted channel, e.g., according to the expired draft [1]. From the latest TLS= 1.3 draft [2] it appears that renegotiation will be removed in the upcomin= g 1.3 version.

What is likely to be the recommended way t= o achieve identity hiding for (D)TLS 1.3, if any?

[= 1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transpor= t Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07

TLS 1.3 encrypts both the cli= ent's and server's certificates already.
The server's= certificate is secure only against passive attack. The
client= 9;s is encrypted with a key that the client can authenticate as
b= elonging to the server.

-Ekr

<= /div>
--089e0163417cf2f208051e1526e5-- From nobody Mon Aug 24 14:33:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EA21A870C for ; Mon, 24 Aug 2015 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 6o29LnHVpLpT for ; Mon, 24 Aug 2015 14:33:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458231A854C for ; Mon, 24 Aug 2015 14:33:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n0RX22zKGz21d; Mon, 24 Aug 2015 23:33:22 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=DDPD9x0f X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id D8e0UEVwwq4Y; Mon, 24 Aug 2015 23:33:20 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 24 Aug 2015 23:33:20 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 67A798009F; Mon, 24 Aug 2015 17:33:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440451999; bh=EhLKb20n94HS6kFqcW2fnDpyMZW2o4bnsSNmhv91Y2M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DDPD9x0fpB+K69k9uRfgLPJDCp+Z4g2vcZ2waAVBzePn6+M6OROCdOQ2QyJWBEXyj nEz0eGYntnV5iLitnDHU8OSG+ZzRYiPj3lp/mE4QFHDGp3cLNFrutMk0pD/lOw666U aOynaKcS9gj+/GYVRWp29gFngOwtVRNZGH/F36Is= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7OLXIPG002396; Mon, 24 Aug 2015 17:33:19 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 24 Aug 2015 17:33:18 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 24 Aug 2015 21:33:26 -0000 On Mon, 24 Aug 2015, Eric Rescorla wrote: > TLS 1.3 encrypts both the client's and server's certificates already. > The server's certificate is secure only against passive attack. Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash of a known CA to you, you can withold your own certificate from being sent. Is a similar mechanism not planned for TLS 1.3? Paul From nobody Mon Aug 24 14:40:24 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0C1B2B34 for ; Mon, 24 Aug 2015 14:40:23 -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 acc6i4Jmn_JS for ; Mon, 24 Aug 2015 14:40:22 -0700 (PDT) Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1651B2B29 for ; Mon, 24 Aug 2015 14:40:21 -0700 (PDT) Received: by vkm66 with SMTP id 66so64428858vkm.1 for ; Mon, 24 Aug 2015 14:40: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=kUiYYqPk0X3CsFQ5eQWJkWfTtR37L8+YMhOPRd/KGKk=; b=Rz3/Uy4L+Xt6HNp5rA0iaWnlihxM2mh7XAKJ7eUTgFShfRgE2niWYUsfy1753Rytn/ 5Rc0Dqd439yRgkTjjyM2tHTU/dJVvqoSB0whD8JDLFmMR0V53Nz2FfE7PDQdjDD8Ps0N EejdTKjcH81QLvcw/RAmZxoOYBQ//+HonBB4FpZSg0qx3h6ccLfNI5yFWG1SQ/IWzQGZ O2d/emBqMLn3Tc+Oj7ShfFiO0ifHYgOPYQj+UD3tXtL1uVnpow/lnInJpiZkKXzObqCf yb5Luwscoh0oOXVfSKA/iwl9mKqrv9WK89mAMcrNdv6DxS3h93ercKFsnYjX5HQNt0uA ftTA== X-Gm-Message-State: ALoCoQmYHCmCeihJYujgMiN7mZosUjsCQJbDPfxbYE0B1MB0ebfuIGfYS9swioMxoA7QV5gJictO X-Received: by 10.52.76.232 with SMTP id n8mr33724646vdw.20.1440452420807; Mon, 24 Aug 2015 14:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.133.19 with HTTP; Mon, 24 Aug 2015 14:39:40 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 24 Aug 2015 14:39:40 -0700 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=bcaec501c594dbbc9f051e1576b9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 24 Aug 2015 21:40:23 -0000 --bcaec501c594dbbc9f051e1576b9 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters wrote: > On Mon, 24 Aug 2015, Eric Rescorla wrote: > > TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. >> > > Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > CAs they trust, so unless you receive a hash of a known CA to you, you > can withold your own certificate from being sent. > > Is a similar mechanism not planned for TLS 1.3? Well, TLS already permits the server to indicate the DN of CAs which should be in the path. I have not heard of any plan to add a digest indication. -Ekr --bcaec501c594dbbc9f051e1576b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 24 Aug 2015, Eri= c Rescorla wrote:

TLS 1.3 encrypts both the client's and server's certificates alread= y.
The server's certificate is secure only against passive attack.

 Not having read the TLS 1.3 draft, in IKE parties can send a hash of the CAs they trust, so unless you receive a hash of a known CA to you, you
can withold your own certificate from being sent.

Is a similar mechanism not planned for TLS 1.3?

=
Well, TLS already permits the server to indicate the DN of CAs which s= hould
be in the path. I have not heard of any plan to add a diges= t indication.

-Ekr


<= /div>
--bcaec501c594dbbc9f051e1576b9-- From nobody Mon Aug 24 15:19:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A8C1AD0D3 for ; Mon, 24 Aug 2015 15:19:11 -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 4fNhOwP0PW8u for ; Mon, 24 Aug 2015 15:19:10 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DFC1ACF1C for ; Mon, 24 Aug 2015 15:19:09 -0700 (PDT) Received: by igui7 with SMTP id i7so72362506igu.1 for ; Mon, 24 Aug 2015 15:19:09 -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=JLucxA28j8JhMiAjGjA99nh9Nw6hJtHEcb84psYickw=; b=hmP3HG0OhZ1Mo7uhmalmI1ITb6l7EvaZjV2AIxKICdr7XKly9vwUvikxcu6skOG9+g Iey2+OXUDQwkmgTE76FDHVlA28D3HNdFoBvNM8tkEevAlmzqQncMbfT2AHaAkGP+eEkc Zi7ToQYUBYDI/pbc502znhAQD165Owb3KSgbJ7VvQDvrzL9Y1l9fq62cloVLo7EGE0Zy 6VAeoVAgdtgfH8Vuc8Z+74Oc8H78wlldvGD0az+jU8bfQuVLeEY0Aj6MV7Uj/jFCTdRS pZdxYkuKaZA6F5C85QLOTjtFuifytDtOjVrc9k/qtkhVjBpgtpiuprw7Gpx0DH1lD++f HAxw== MIME-Version: 1.0 X-Received: by 10.50.43.167 with SMTP id x7mr17960090igl.95.1440454749373; Mon, 24 Aug 2015 15:19:09 -0700 (PDT) Sender: mbadra@gmail.com Received: by 10.64.229.19 with HTTP; Mon, 24 Aug 2015 15:19:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Aug 2015 02:19:09 +0400 X-Google-Sender-Auth: PaEzOmvAVqPZs1yjHKpUKqoeA2A Message-ID: From: Badra To: "Viktor S. Wold Eide" Content-Type: multipart/alternative; boundary=089e011602b2a6cc2d051e1601fc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 24 Aug 2015 22:19:11 -0000 --089e011602b2a6cc2d051e1601fc Content-Type: text/plain; charset=UTF-8 Hi, Another solution was approved for publication as experimental by IESG in 2009 but I declined to process with Pasi Eronen way (previous WG co-Chair) of publishing the document. It is available at https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and it works for TLS and DTLS Best regards, Mohamad On Tue, Aug 25, 2015 at 12:56 AM, Viktor S. Wold Eide < viktor.s.wold.eide@gmail.com> wrote: > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > > Best regards > Viktor S. Wold Eide > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e011602b2a6cc2d051e1601fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Another solution was approved for publica= tion as experimental by IESG in 2009 but I declined to process with Pasi Er= onen way (previous WG co-Chair) of publishing the document.

<= /div>
It is available at=C2=A0https://tools.ietf.org/html/draft-ha= jjeh-tls-identity-protection-09 and it works for TLS and DTLS

Best regards, Mohamad

On Tue, Aug 25, 2015 at 12:56 AM, Vik= tor S. Wold Eide <viktor.s.wold.eide@gmail.com> w= rote:
Hi,

I am looking for a way to achieve iden= tity hiding for DTLS 1.2, which also hopefully can be used in (D)TLS 1.3, w= hen available.

From what I understand, for (D)TLS 1.2 i= t would be possible to perform an anonymous unencrypted handshake=20 and then to renegotiate the connection with authentication within the encry= pted channel, e.g., according to the expired draft [1]. From the latest TLS= 1.3 draft [2] it appears that renegotiation will be removed in the upcomin= g 1.3 version.

What is likely to be the recommended way t= o achieve identity hiding for (D)TLS 1.3, if any?

[= 1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transpor= t Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07

Best regards
<= div>
Viktor S. Wold Eide


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


--089e011602b2a6cc2d051e1601fc-- From nobody Mon Aug 24 16:22:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031611B2B0E for ; Mon, 24 Aug 2015 16:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKHswgYsmery for ; Mon, 24 Aug 2015 16:22:32 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247F21ACEEA for ; Mon, 24 Aug 2015 16:22:32 -0700 (PDT) Received: by iodv127 with SMTP id v127so167137915iod.3 for ; Mon, 24 Aug 2015 16:22:31 -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=ocwg9fHUrL9cI3f7HEcEoyKDtolzRkoqgoC0N9DIySk=; b=B82/7vUzrAuQ3HM1HUSTgsgGynL8emnu3zxd1dO3NcWAdFnBOqIxifZHDGq34mnYp8 NNuRWq5eZ0u2cv7F4wUCcunVSYLNd3oFrLfGWyFQb7mWoLXFTdR8s6nuuJc+nHe6odxi wfkwSJs7OpDW2AuBIlmuEtnt5pB3l741rCSf0= 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=ocwg9fHUrL9cI3f7HEcEoyKDtolzRkoqgoC0N9DIySk=; b=Eh3BKtdheEPyTIOAePcL07VIQBK9396UP6kyF6pMUDiGmfkr+IzY7Zv+LW5Y9mPLHk NMhbPDN2ceKmF+TTI4BxRzCKDqMi+GWWEanuyO/IxgJh2s0XTZ2D8IVzf+QIwG0TCGd/ IlOYzlRx6JuQQdyJXEsbrYUTPX6/xhSnIT+IJ8n0WkCgXgPXPJQWpQ6NP/o4RmMqcGMw J8BX1742ef1FjZ4phOoqhVkwX4m1/vnRJCeDHc7l5k1pgR+BAZOijJqpD6W0/ZefDE2a mqq95RF2RsWckK5fXfNriAgOeI7SnCywCkk6URDfNf/LndY53H0AcnyQH3wpyr9qTx9I hT6Q== X-Gm-Message-State: ALoCoQkI6Gl4W8hyP3FliB5jjDJyk6qWRvbRXd9hk4lv0A1wSZWWK6jePiegPkuF2s6za3QUtA9r X-Received: by 10.107.131.168 with SMTP id n40mr24321969ioi.47.1440458551346; Mon, 24 Aug 2015 16:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.71.1 with HTTP; Mon, 24 Aug 2015 16:22:11 -0700 (PDT) In-Reply-To: <201508222028.46145.davemgarrett@gmail.com> References: <201508211832.14227.davemgarrett@gmail.com> <201508222028.46145.davemgarrett@gmail.com> From: Tom Ritter Date: Mon, 24 Aug 2015 18:22:11 -0500 Message-ID: To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF TLS Subject: Re: [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, 24 Aug 2015 23:22:34 -0000 On 22 August 2015 at 19:28, Dave Garrett wrote: > Toggling solves the undesired bandwidth use concern stated by Tom by maki= ng it fully optional on both sides. The even simpler route of just having t= o check if there's bytes in the encrypted fragment other than the payload w= ould avoid a little bit of complexity, but with no way for an endpoint to s= ay no to increased bandwidth usage that it doesn't want to or can't handle.= Given this constraint, I'd favor either easily toggleable or always-on, ra= ther than a middle-ground where implementations won't know what they're goi= ng to get and can't do anything about it. > > A footnote: Negotiating via an extension is probably not a good idea beca= use client extensions will generally be in the clear. That's why I suggest = a simple message instead. (there's no need to pad the cleartext hello, so i= t's fine to wait until record protection is available) Note that I don't th= ink allowing this to be decided after the handshake is a good idea. > > A more generalized way to handle throttling padding would be to set a low= default and require each endpoint to send a message with a different value= , in max bytes per record (or second, or both) of padding permitted, in ord= er to use a different amount. Each endpoint could easily arbitrarily thrott= le its downstream padding bandwidth independently, if need be. I have a not-very-hidden motive in not having it be negotiable: I want to enable clients to want to send padding be able to do so to any server, even if that server does not want to pad. (They can just discard.) If it's negotiated, the server may say "I don't support padding" and clients who want to use it out out of luck. I do like solutions where the use or non-use of padding is hidden, but I think in many cases it will be obvious, so the above goal comes before this goal for me. I don't believe the topic of encrypting the content type is completely resolved, but that is a separate proposal: https://github.com/tlswg/tls13-spec/pull/51 > I'm curious as to how much of a range would actually be useful, though. F= or actually good protection, you'd really want to pick a stable bandwidth a= nd essentially hold it; keep up/download rates constant or following some c= onsistent pattern with a combination of possibly throttled data and padding= such that the data length and time is completely protected and the stream = is 100% opaque to an observer. I wouldn't expect this to be all that popula= r, though, as it would be a bandwidth hog in many cases. A middle-ground mi= ght involve also specifying a max bytes allowed in between data bursts to h= ide the peaks, but now we're getting more complicated than I think we want = here if we go any further. (and beyond what I know anything about) The curr= ent proposal says that padding algorithms are outside of the scope here, bu= t I think adding this as a built-in feature without coming up with some eas= ily usable default (even if not particularly advanced) is a mistake that wi= ll cause this feature to be largely unused. In general, developing good padding approaches is relatively easy for well defined application protocols, and difficult for extremely generic ones like "Browsing the Internet". If one was developing an application for twitter, google maps, XMPP chat - developing a good padding mechanism to hide specific actions or data would not have the same issues. There's been a number of padding strategies developed by academic researchers studying traffic correlation/confirmation attacks - I don't expect any of them is drop-in-good-enough for a generic browser implementation... but it would be _amazing_ if browser vendors enabled browser extension authors to choose the padding strategy for individual origins. Then we can crowdsource the effort. -tom From nobody Mon Aug 24 16:31:04 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955611A701D for ; Mon, 24 Aug 2015 16:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, 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 Lpi_G4PM4T0e for ; Mon, 24 Aug 2015 16:31:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9E21A701C for ; Mon, 24 Aug 2015 16:31:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CCDACBF10; Tue, 25 Aug 2015 00:30:59 +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 e695mP2Zvhi5; Tue, 25 Aug 2015 00:30:58 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.21.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 779F6BEEB; Tue, 25 Aug 2015 00:30:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440459058; bh=DAgAUSOxxP2dc7lD6/GwiwTo8+ffblGF0d9tq9JU8DI=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=gsRdXMw524Jwmg3Pj3LYUZw4bSwbpy+tRcT+p9g8D9UKbXJU9IPxN0JqW22Wsp7pg Cl+Jw9DICYvGpSNtJi2fPJ/6axNjn/N5VeVFtRTtOQ5zRV+LUMcvLlosVY3mMx/7Cg m6b9vVse9wa7EQt9Gq4szSfjsyf+uHypeOmnFGH4= Message-ID: <55DBA92F.8000806@cs.tcd.ie> Date: Tue, 25 Aug 2015 00:30:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Tom Ritter , Dave Garrett References: <201508211832.14227.davemgarrett@gmail.com> <201508222028.46145.davemgarrett@gmail.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF TLS Subject: Re: [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, 24 Aug 2015 23:31:03 -0000 On 25/08/15 00:22, Tom Ritter wrote: > it would be _amazing_ if browser vendors enabled > browser extension authors to choose the padding strategy for > individual origins. Then we can crowdsource the effort. Excellent idea! S. From nobody Mon Aug 24 17:10:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4E1ABD36 for ; Mon, 24 Aug 2015 17:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbcJ5WfUkvzM for ; Mon, 24 Aug 2015 17:10:21 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3007F1ABC0F for ; Mon, 24 Aug 2015 17:10:21 -0700 (PDT) Received: by ykdt205 with SMTP id t205so140206713ykd.1 for ; Mon, 24 Aug 2015 17:10: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=8mSDaiNOegFgORyHUFRLam5h/+g8XxN2MCnQQ4CEbps=; b=Mh0MMqBFGF5sj/dtesQkfRBw0e5JCDMubJG0QIk3lHHts2BGCv1HmC7XfApXny4RUq 3QfLnYyaqkuVPQ5t6z4rpMKALtakquHkBP9UlGGtXsnUnYmDeEtcMNljW1KJkz8PJ25P rZadBaJTfSUxlY917AGCo+jRv4Ox42xl7m7JGPdlneJXRYyZAve0RJH+5g19ZT735uEh lTU52fqofo48w7PjoS5Cemc8mkLISe09Mu9RzdXkO8d1BpnYR7nMZ9pE0se5HWR19S/a pKG1wwVYyScHd2Z7LxMi3bZrQ2LD8HajHjy53+4C4mEUWTCkbnhAb81Uty0ri5tsCg4q IgOQ== MIME-Version: 1.0 X-Received: by 10.13.213.197 with SMTP id x188mr33266819ywd.64.1440461420485; Mon, 24 Aug 2015 17:10:20 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Mon, 24 Aug 2015 17:10:20 -0700 (PDT) In-Reply-To: <55DBA92F.8000806@cs.tcd.ie> References: <201508211832.14227.davemgarrett@gmail.com> <201508222028.46145.davemgarrett@gmail.com> <55DBA92F.8000806@cs.tcd.ie> Date: Mon, 24 Aug 2015 17:10:20 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [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, 25 Aug 2015 00:10:25 -0000 On 24 August 2015 at 16:30, Stephen Farrell wrote: > > > On 25/08/15 00:22, Tom Ritter wrote: >> it would be _amazing_ if browser vendors enabled >> browser extension authors to choose the padding strategy for >> individual origins. Then we can crowdsource the effort. > > Excellent idea! I believe that this would be possible, but you would have to enumerate what information you might want to have available. At the TLS layer, we've lost a lot of the context. You might be better off with HTTP(/2) layer padding. The From nobody Mon Aug 24 18:19:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AB1AC409 for ; Mon, 24 Aug 2015 18:19:17 -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 qzS_NWfcX7tR for ; Mon, 24 Aug 2015 18:19:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85EE41AC3C1 for ; Mon, 24 Aug 2015 18:19:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1E03C284D64; Tue, 25 Aug 2015 01:19:14 +0000 (UTC) Date: Tue, 25 Aug 2015 01:19:14 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150825011913.GR9021@mournblade.imrryr.org> 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: Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:19:17 -0000 On Mon, Aug 24, 2015 at 05:33:18PM -0400, Paul Wouters wrote: > On Mon, 24 Aug 2015, Eric Rescorla wrote: > > >TLS 1.3 encrypts both the client's and server's certificates already. > >The server's certificate is secure only against passive attack. > > Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > CAs they trust, so unless you receive a hash of a known CA to you, you > can withold your own certificate from being sent. > > Is a similar mechanism not planned for TLS 1.3? This would break DANE, unless the mechanism also allowed the client to send a TLSA RRset instead, with the server then needing code to figure out which chains match which TLSA RRs. This is I think too complex. If the client is willing to live without any certificate at all, it can include anon-(EC)DH ciphersuites in its cipherlist at a higher preference than any ciphersuites that use certificates.. Otherwise, the server sends a suitable chain per SNI and closest match to supported signature algorithms. -- Viktor. From nobody Mon Aug 24 18:57:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AD1AD0A7 for ; Mon, 24 Aug 2015 18:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 IhVIn6RL6ID6 for ; Mon, 24 Aug 2015 18:56:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0A01AD0A5 for ; Mon, 24 Aug 2015 18:56:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n0YN64fT2z8t for ; Tue, 25 Aug 2015 03:56:54 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=APpWO4/d X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id STfPb1Foary3 for ; Tue, 25 Aug 2015 03:56:52 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 25 Aug 2015 03:56:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E4F528009D for ; Mon, 24 Aug 2015 21:56:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440467810; bh=vOxh37OLO1Bt1Py4utiXezRTNa5aiaWbs205BJx/J3c=; h=Date:From:To:Subject:In-Reply-To:References; b=APpWO4/dxyYFo7/KODNK+wn4OI/fxdipMT/EkzgM36k17G7pCvMCxDa4/ae1mAEMP vyMsJZRdwnA/gTS2U6dvqlWVLbtj9lrN5vr2Pu2oIc/tRbnwcUkm5Kt+tBAyQY2nm6 +hVe6Vd8UL9nTKwWHdyXMiyWPU0xjGjnQvBjMJJI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7P1uoQe009977 for ; Mon, 24 Aug 2015 21:56:50 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 24 Aug 2015 21:56:50 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: <20150825011913.GR9021@mournblade.imrryr.org> Message-ID: References: <20150825011913.GR9021@mournblade.imrryr.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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: Tue, 25 Aug 2015 01:56:58 -0000 On Tue, 25 Aug 2015, Viktor Dukhovni wrote: >> Not having read the TLS 1.3 draft, in IKE parties can send a hash of the >> CAs they trust, so unless you receive a hash of a known CA to you, you >> can withold your own certificate from being sent. >> >> Is a similar mechanism not planned for TLS 1.3? > > This would break DANE, unless the mechanism also allowed the client > to send a TLSA RRset instead, with the server then needing code to > figure out which chains match which TLSA RRs. This is I think too > complex. If you publish your public key in DNS you would also just always send your public key over TLS. There is no privacy issue there, so no reason to withhold it. Paul From nobody Mon Aug 24 19:19:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9791ACD45 for ; Mon, 24 Aug 2015 19:19: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 yiFEiU1zsW8E for ; Mon, 24 Aug 2015 19:19:28 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05151ACD6F for ; Mon, 24 Aug 2015 19:19:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E2DB8284D64; Tue, 25 Aug 2015 02:19:26 +0000 (UTC) Date: Tue, 25 Aug 2015 02:19:26 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150825021926.GS9021@mournblade.imrryr.org> References: <20150825011913.GR9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 02:19:29 -0000 On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote: > >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the > >>CAs they trust, so unless you receive a hash of a known CA to you, you > >>can withold your own certificate from being sent. > >> > >>Is a similar mechanism not planned for TLS 1.3? > > > >This would break DANE, unless the mechanism also allowed the client > >to send a TLSA RRset instead, with the server then needing code to > >figure out which chains match which TLSA RRs. This is I think too > >complex. > > If you publish your public key in DNS you would also just always > send your public key over TLS. There is no privacy issue there, > so no reason to withhold it. Not sure how this comports with your original proposal. What would a client have to send to convince the server to not withold its certificate? What does witholding it mean anyway, the client needs the public key at least if the server signs the key exchange. Is there something here worth pursuing in the context of TLS? -- Viktor. From nobody Mon Aug 24 21:04:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF0F1A89D3 for ; Mon, 24 Aug 2015 21:04: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 6jf4R-c70BU9 for ; Mon, 24 Aug 2015 21:04:39 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413601A907A for ; Mon, 24 Aug 2015 21:04:39 -0700 (PDT) Received: by qkfh127 with SMTP id h127so94277827qkf.1 for ; Mon, 24 Aug 2015 21:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=qTB8VQpRpsE8Te2f3Ol5852MZCFYq38dHkSEDgBTAJI=; b=hRldjFLaunRIMzzco2PDndc8ciNhwFQpeUYaDOrJHbg9K0mA8KA2E6KOsG4YKPDhHo +RLHszgzINckvIPsL3QXbwHuSRgmXW3ilBbzJ2eMfCPMg+oS//PjStfzeTTwHGvK4sTv lpr3a/Pa1a1j2PdsbszM57Mj/GWTcJJoQ+qpnM/29/QXFpH2KMqB5w/PwDIrzdG7Tce7 mvasUIXnlQwEXqOlvQIHGV7EgraOIrgjZvmkSVKBO8IQUFvWx7O7OdG3DrOr+CCiVKZm nNcqYQWrn+mb64yDWqS381mjcCXpdRlOKcwP4CUJl7fesUyh2TqaTAykDwLK79AAhToq G2fA== X-Received: by 10.55.22.143 with SMTP id 15mr29744574qkw.38.1440475478507; Mon, 24 Aug 2015 21:04:38 -0700 (PDT) Received: from dave-laptop.localnet (pool-108-52-139-147.phlapa.fios.verizon.net. [108.52.139.147]) by smtp.gmail.com with ESMTPSA id q76sm9384898qkq.22.2015.08.24.21.04.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Aug 2015 21:04:37 -0700 (PDT) From: Dave Garrett To: Tom Ritter , IETF TLS Date: Tue, 25 Aug 2015 00:04:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201508222028.46145.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201508250004.36291.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Headerless records (was: 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, 25 Aug 2015 04:04:41 -0000 The topic of encrypting the content type came up again, and a core WG charter goal is to encrypt as much as possible. To this end, I suggest we consider going all the way in this area: headerless records. Each protected record would contain nothing but an aead-ciphered struct with the bare minimum it needs, namely ContentType & content, plus maybe padding. Nothing else is really needed. The only thing that needs to know anything here is the peer with the key. struct { aead-ciphered struct { ContentType type; uint16 length = TLSPlaintext.length; opaque content[TLSPlaintext.length]; opaque padding[padding_length]; }; } TLSCiphertext; Arbitrary padding can be added after the content, up to the total record maximum size. If we even wanted to ditch the length field, we could do: struct { aead-ciphered struct { if (padding_allowed) { opaque padding<0..(2^14+256-TLSPlaintext.length)>; } ContentType type; opaque content[TLSPlaintext.length]; }; } TLSCiphertext; In which case content is just the remainder of the record after the type. (without the explicit length field, padding needs to come first so it can have its length in its vector first) Cleartext records would of course be unchanged, as they need to stay as-is for backwards compatibility. With an encrypted record format like one of the above, everything after the handshake is opaque and potentially padded. The additional data fed to the AEAD cipher is just the sequence number at this point. The version can easily be mixed into the keying material by adding it to the HKDF label, and then we don't need to re-verify it after the fact if they key depends on it. Dave From nobody Tue Aug 25 00:02:46 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82DD1A8AFE for ; Tue, 25 Aug 2015 00:02:44 -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 YSA7aOglJRkl for ; Tue, 25 Aug 2015 00:02:43 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C69E1A1B8A for ; Tue, 25 Aug 2015 00:02:43 -0700 (PDT) Received: by ykll84 with SMTP id l84so146213573ykl.0 for ; Tue, 25 Aug 2015 00:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oz8gDCgtZOHNtW9ppzqhJisgtV1zReIdNN75J675Ces=; b=Z5ltqkBBQMY4QU22zPIaKTPvjsDrWxGkWrTOl4QjgSr/AR0DpWqKFvTQab54Y6/rw/ V3nEyOzWZ5ZPyjNBVeURKHRQrNbn0r2UXBjVi0hWQjB9KpMH7e5EiQy9q+q4FIZlgvBC 75ThIUT4lQBAXEcJmWi8DZNORd1Oqf0OGHvJEHVg1JXY8+KjO/lbU7FO2WNMhG8eWdxG C/xDlRhUM+1lfiip6zxmLkBK23881Ejg0E7PA4mLXcTlRfj5wcwCL0uDhI8WMiYfDGDR d4xcaB/JGC1A7hcc7aazKjKvwdnj2xUHP7gg6EDYQUXP/bQLmpK+ORJC2RCsc0RhcoBB EsRw== MIME-Version: 1.0 X-Received: by 10.13.225.66 with SMTP id k63mr35892625ywe.148.1440486162950; Tue, 25 Aug 2015 00:02:42 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 00:02:42 -0700 (PDT) In-Reply-To: <201508250004.36291.davemgarrett@gmail.com> References: <201508222028.46145.davemgarrett@gmail.com> <201508250004.36291.davemgarrett@gmail.com> Date: Tue, 25 Aug 2015 00:02:42 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Headerless records (was: 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, 25 Aug 2015 07:02:44 -0000 On 24 August 2015 at 21:04, Dave Garrett wrote: > uint16 length = TLSPlaintext.length; You can't recover the plaintext without knowing how long it is. This part at a minimum needs to be in the clear. At which point you need it to be based on TLSCiphertext.length From nobody Tue Aug 25 01:43:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C531A888E for ; Tue, 25 Aug 2015 01:43: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 CWe2vGN1ZuaW for ; Tue, 25 Aug 2015 01:43:20 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC831A8758 for ; Tue, 25 Aug 2015 01:43:20 -0700 (PDT) Received: by igfj19 with SMTP id j19so6315239igf.0 for ; Tue, 25 Aug 2015 01:43: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=A8+Xq8tZmU42TVFEGa6JtOVw8v5lZAjYOhvpCi3ynHI=; b=KKl16Of4E3uEAwnAn/V2B7ZxR+Jmi1AUar+EAxE8TPjHoWOD5wAz8Gx2i1Qwesnare pMw61MWh/958GQqWwY5Bzwgv3X/QmFAHt8nBSCyL1GtC9S+TGtQqwH0CCGHK+E8yHqim JL6Mfyn7jppMdV5bmzOTPDPuOssu4EUtRPWYWdy+9AH5bSj8ipHcXDjB3XyvSwot0dds M3SA5u+fuTU+USuyZZbf/017/x2/LKr0kJmQzggm0jdLn29flQ9p6/IKwpgmctYoDE2c ZZRXXN1ceQ24V3pXTiaElB6s2sLIqWlohev4hdvC+mN9Unch+MWdilQEBPAupntEUCen u80g== MIME-Version: 1.0 X-Received: by 10.50.50.225 with SMTP id f1mr1015517igo.19.1440492200129; Tue, 25 Aug 2015 01:43:20 -0700 (PDT) Received: by 10.107.51.15 with HTTP; Tue, 25 Aug 2015 01:43:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Aug 2015 10:43:19 +0200 Message-ID: From: Pascal Urien To: "Viktor S. Wold Eide" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: TLS@ietf.org Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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: Tue, 25 Aug 2015 08:43:22 -0000 Hi a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt the client certificat with an extra key computed from the master secret see https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01 Rgs Pascal 2015-08-24 22:56 UTC+02:00, Viktor S. Wold Eide : > Hi, > > I am looking for a way to achieve identity hiding for DTLS 1.2, which also > hopefully can be used in (D)TLS 1.3, when available. > > >From what I understand, for (D)TLS 1.2 it would be possible to perform an > anonymous unencrypted handshake and then to renegotiate the connection with > authentication within the encrypted channel, e.g., according to the expired > draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation > will be removed in the upcoming 1.3 version. > > What is likely to be the recommended way to achieve identity hiding for > (D)TLS 1.3, if any? > > [1] Transport Layer Security (TLS) Encrypted Handshake Extension, > draft-ray-tls-encrypted-handshake-00, expired in 2012 > [2] The Transport Layer Security (TLS) Protocol Version 1.3, > draft-ietf-tls-tls13-07 > > > Best regards > Viktor S. Wold Eide > From nobody Tue Aug 25 01:47:37 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911881A875C for ; Tue, 25 Aug 2015 01:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JraugxnsVpy for ; Tue, 25 Aug 2015 01:47:35 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49831A1BC2 for ; Tue, 25 Aug 2015 01:47:34 -0700 (PDT) Received: by wicja10 with SMTP id ja10so7913114wic.1 for ; Tue, 25 Aug 2015 01:47: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=Pc3Jp9sQG+rVIDEV6XcNQybXQD7tg5enzPpJbEBrA74=; b=bNC8s5H/55Tgg4/lZZQ8RCFRklfucPJrYbeJevcAWEBm/yzESrWiecco5WkTFho4uR UXbGzo2KZ7Asb9THRI3URoC1aZ+32cec6zK8D0NK0TxmYKJuPe9G+3Z0HkI/vPVm0OxS PYOmAUpN/b6baowLMYiZa0EHsBba6dvYoeUCHYv1M9FmUkIj0kuKs6e2caeQ4gqOkMZ1 cGAkzVAd2BvHb9xOunwTu9aqR3UhSJ5xQQMc67LQ4hXyFe8w3J/1v8GWb6cQfX+yAVNA R0ke7a1EMGTqbMCSUqBqWLfrpEZlMpy1lmJKSeUcCsd/cjW3PBYvoaKjDWMoMrcvZO4m PImw== X-Received: by 10.194.201.71 with SMTP id jy7mr48994988wjc.93.1440492453550; Tue, 25 Aug 2015 01:47:33 -0700 (PDT) Received: from [172.24.248.148] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id eu2sm1528806wic.8.2015.08.25.01.47.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 01:47:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: Date: Tue, 25 Aug 2015 11:47:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201508211832.14227.davemgarrett@gmail.com> <201508222028.46145.davemgarrett@gmail.com> To: Tom Ritter X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IETF TLS Subject: Re: [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, 25 Aug 2015 08:47:36 -0000 > On Aug 25, 2015, at 2:22 AM, Tom Ritter wrote: >=20 > On 22 August 2015 at 19:28, Dave Garrett = wrote: >> Toggling solves the undesired bandwidth use concern stated by Tom by = making it fully optional on both sides. The even simpler route of just = having to check if there's bytes in the encrypted fragment other than = the payload would avoid a little bit of complexity, but with no way for = an endpoint to say no to increased bandwidth usage that it doesn't want = to or can't handle. Given this constraint, I'd favor either easily = toggleable or always-on, rather than a middle-ground where = implementations won't know what they're going to get and can't do = anything about it. >>=20 >> A footnote: Negotiating via an extension is probably not a good idea = because client extensions will generally be in the clear. That's why I = suggest a simple message instead. (there's no need to pad the cleartext = hello, so it's fine to wait until record protection is available) Note = that I don't think allowing this to be decided after the handshake is a = good idea. >>=20 >> A more generalized way to handle throttling padding would be to set a = low default and require each endpoint to send a message with a different = value, in max bytes per record (or second, or both) of padding = permitted, in order to use a different amount. Each endpoint could = easily arbitrarily throttle its downstream padding bandwidth = independently, if need be. >=20 >=20 > I have a not-very-hidden motive in not having it be negotiable: I want > to enable clients to want to send padding be able to do so to any > server, even if that server does not want to pad. (They can just > discard.) If it's negotiated, the server may say "I don't support > padding" and clients who want to use it out out of luck. I=E2=80=99m not sure having one side send a continuous stream of large = record buys you much if the other side doesn=E2=80=99t. Suppose an HTTPS = server has 100 resources, each with a different size, it won=E2=80=99t = help if the client obscures the identity of the resource it=E2=80=99s = asking for if the resource can be identified by its size. Same goes for = the existence of traffic. If the server stays quiet until there=E2=80=99s = an actual request, the client=E2=80=99s continuous stream of = padding-only records is just wasted effort. IMO this is an argument for negotiation, although even with negotiation = we can never be assured that the other side is doing TFC well.=20 Yoav From nobody Tue Aug 25 07:26:28 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F01B32D4 for ; Tue, 25 Aug 2015 07:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPbEpCAvyleF for ; Tue, 25 Aug 2015 07:26:26 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819F81B32BE for ; Tue, 25 Aug 2015 07:26:25 -0700 (PDT) Received: by igcse8 with SMTP id se8so13751758igc.1 for ; Tue, 25 Aug 2015 07:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+P0mV+81V7VRRnKBKXIppaR+Cw3rChHfEp28CX5ef6c=; b=GCfp90k14qPcdm66TQAXpMAx70q4bAXZB7NEBnzWrMfE99V2d+54bWng3kClj8LCB1 HrofVde+RKWXTcgoEXmqdCckbgOH0E9ACuMQ4q66chUKxYZreC77lx3Oa8eOkN+JrWLQ wuYe90DmvsCGMvQwLWp8SIX2S4kHN78ppegR4= 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=+P0mV+81V7VRRnKBKXIppaR+Cw3rChHfEp28CX5ef6c=; b=f3U9HZO4uMtvOv6Xvp5TNxa6P0rJm1jg6s6m223jgldTXuMdn+n0X/WA6qHPyILtvp 8HnHddjNtyXp6zjSHyYDZ3oJAyVxHmTw5nSNhNWqS4zgJb/8QlUON3gEcK4ZZKX9Zchs pp0mkgxYCrndY7JFejogXoCEso2qt0Nay9VWDPMKaJj1ZoTxtpCfw+0fIJe1vs2c08WU 7iqykY/RBKZ1KNmMkPFvIivkkgIIHCB8fLqdCC01ZVFeEK0J1Nn1UAoFtVAm2SFmP1WB alsiqukUjltC0SoeRHQw/5hT+jSUTzbZSx/rE3ouvz7nZjBtEp17Eb4rQfAq/Ie0BA5O YlXw== X-Gm-Message-State: ALoCoQnRQI/sqNLuIxvNAf6LKKiTQr+C7lYzMBkCCs0FIVnpbycKzEzuBaFaMM/Q8vZP8kldpZ7+ MIME-Version: 1.0 X-Received: by 10.50.73.98 with SMTP id k2mr2904161igv.96.1440512784840; Tue, 25 Aug 2015 07:26:24 -0700 (PDT) Received: by 10.79.31.197 with HTTP; Tue, 25 Aug 2015 07:26:24 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <201508222028.46145.davemgarrett@gmail.com> <201508250004.36291.davemgarrett@gmail.com> Date: Tue, 25 Aug 2015 10:26:24 -0400 Message-ID: From: Kyle Rose To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Headerless records (was: 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, 25 Aug 2015 14:26:27 -0000 >> uint16 length = TLSPlaintext.length; > > You can't recover the plaintext without knowing how long it is. This > part at a minimum needs to be in the clear. At which point you need > it to be based on TLSCiphertext.length Is that really true? You could decrypt the first block/few bytes to get the length (without authentication, of course) and then decrypt the remainder according to this candidate length. Then authenticate the entire record to make sure the candidate length was correct. (I am not claiming anything about the purity of this approach, only that it is technically feasible.) Kyle From nobody Tue Aug 25 07:42:15 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520AC1B29E2 for ; Tue, 25 Aug 2015 07:42:13 -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 ghRnMHi3ODqO for ; Tue, 25 Aug 2015 07:42:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A26F1A907B for ; Tue, 25 Aug 2015 07:42:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3F4B2284B69; Tue, 25 Aug 2015 14:42:11 +0000 (UTC) Date: Tue, 25 Aug 2015 14:42:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150825144210.GD9021@mournblade.imrryr.org> References: <201508222028.46145.davemgarrett@gmail.com> <201508250004.36291.davemgarrett@gmail.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: Subject: Re: [TLS] Headerless records (was: 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: Tue, 25 Aug 2015 14:42:13 -0000 On Tue, Aug 25, 2015 at 10:26:24AM -0400, Kyle Rose wrote: > (I am not claiming anything about the purity of this approach, only > that it is technically feasible.) SSH now has ciphersuites where the payload length is encrypted, IIRC via a key that is different from the payload key. -- Viktor. From nobody Tue Aug 25 08:26:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAC1B34F5 for ; Tue, 25 Aug 2015 08:26:37 -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 JaocY85_sbgV for ; Tue, 25 Aug 2015 08:26:36 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070071B34F4 for ; Tue, 25 Aug 2015 08:26:36 -0700 (PDT) Received: by ykfw73 with SMTP id w73so160138868ykf.3 for ; Tue, 25 Aug 2015 08:26: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=FxFIWfMbYEDJDLJmkmYXMx8lB8hGgZ8ih03UsMALzTs=; b=q1RqZrVTEvNOq7Gx9ouMcvU693/D0nm+9/bf/lnrtCi59T4XY9jLAvbAH5b6WtjSj1 khvum6PBWtKCaKWrp70PhVx07ZCMKi8+PW4V7DJvk5lr5I3hT1oAuxhGZsw1CqA6sLs4 A3YmDR8uNQMo7an75OKKqgIjOiana2z41UCQjMWZix8/X78Ja+ZhoWXZB484d4GU+77j kUamSuZqZC/a67lSU5G8q5uYBgj2nIcc15u9Eio4UixFJ6c/NUExpJI8ThLInAgtWilN BQb/Rqbvz10yEvnQzpDCa07tovphvV5baDL8QnjOGIt1jyWXlaUuakIsl8FDDSHfmKfr ly8Q== MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr37757276ywx.56.1440516395397; Tue, 25 Aug 2015 08:26:35 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:26:35 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:26:35 -0700 (PDT) In-Reply-To: References: <201508222028.46145.davemgarrett@gmail.com> <201508250004.36291.davemgarrett@gmail.com> Date: Tue, 25 Aug 2015 08:26:35 -0700 Message-ID: From: Martin Thomson To: Kyle Rose Content-Type: multipart/alternative; boundary=001a1142196e0a7a42051e245c50 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Headerless records (was: 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, 25 Aug 2015 15:26:37 -0000 --001a1142196e0a7a42051e245c50 Content-Type: text/plain; charset=UTF-8 On Aug 25, 2015 7:26 AM, "Kyle Rose" wrote: > > >> uint16 length = TLSPlaintext.length; > > > > You can't recover the plaintext without knowing how long it is. This > > part at a minimum needs to be in the clear. At which point you need > > it to be based on TLSCiphertext.length > > Is that really true? You could decrypt the first block/few bytes to > get the length (without authentication, of course) and then decrypt > the remainder according to this candidate length. Then authenticate > the entire record to make sure the candidate length was correct. That depends on the aead - and the implementation. GCM can - maybe - be broken apart that way*, but I can't think that going to all the trouble of formulating an aead just to break it open at the first point that it becomes inconvenient. You could imagine an aead that made that difficult or impossible (just reverse the order of the bytes...). Or, without imagining at all, you can have hardware module that enforce authentication before releasing plaintext. --001a1142196e0a7a42051e245c50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 25, 2015 7:26 AM, "Kyle Rose" <krose@krose.org> wrote:
>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 length =3D TLSPlainte= xt.length;
> >
> > You can't recover the plaintext without knowing how long it i= s.=C2=A0 This
> > part at a minimum needs to be in the clear.=C2=A0 At which point = you need
> > it to be based on TLSCiphertext.length
>
> Is that really true? You could decrypt the first block/few bytes to > get the length (without authentication, of course) and then decrypt > the remainder according to this candidate length. Then authenticate > the entire record to make sure the candidate length was correct.

That depends on the aead - and the implementation. GCM can -= maybe - be broken apart that way*, but I can't think that going to all= the trouble of formulating an aead just to break it open at the first poin= t that it becomes inconvenient.

You could imagine an aead that made that difficult or imposs= ible (just reverse the order of the bytes...). Or, without imagining at all= , you can have hardware module that enforce authentication before releasing= plaintext.

--001a1142196e0a7a42051e245c50-- From nobody Tue Aug 25 08:28:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE361B3282 for ; Tue, 25 Aug 2015 08:28:46 -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 1IYQ8A7jawzf for ; Tue, 25 Aug 2015 08:28:45 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4E91B3240 for ; Tue, 25 Aug 2015 08:28:45 -0700 (PDT) Received: by ykbi184 with SMTP id i184so160001368ykb.2 for ; Tue, 25 Aug 2015 08:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Km8mHBq44kBUHqnc1FNX7pqBy69e/zTcnFAbD77Feik=; b=yg4e/a5q6ytspgFgN1l5ObHAddIHlGokbE5hQ/c9qG213siapVTVOBr24Jc9gwsDjY 34HZxZM1lHTa59edPE9rS0twuivbMUImcaEW+XUCgSTEmhXUrCoR2ufPdZR+uRZ5uhQw WV+7mwAjVRgyzducUpj/oaZeBRWjE8nvISt+/3tZIYpJb2LwF57K0lY5f+JZRu9Yc5D2 9qL5Hqe+pz7iWx3F9Mmz86abjJEY2iCd3WVnynjWg9aXfrQZJfNVpcjA9ObOvq2Pxgd9 sFbLutI9MQwoS+k+rKMpbI7Ui63gPFRnbQFEVG2Nr4PvoAOyi4pJzCWo/DdkrAumcM7B 7TgQ== MIME-Version: 1.0 X-Received: by 10.170.165.193 with SMTP id h184mr38410484ykd.1.1440516524763; Tue, 25 Aug 2015 08:28:44 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:28:44 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Tue, 25 Aug 2015 08:28:44 -0700 (PDT) In-Reply-To: <20150825144210.GD9021@mournblade.imrryr.org> References: <201508222028.46145.davemgarrett@gmail.com> <201508250004.36291.davemgarrett@gmail.com> <20150825144210.GD9021@mournblade.imrryr.org> Date: Tue, 25 Aug 2015 08:28:44 -0700 Message-ID: From: Martin Thomson To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113a9160c07415051e2463d8 Archived-At: Subject: Re: [TLS] Headerless records (was: 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, 25 Aug 2015 15:28:46 -0000 --001a113a9160c07415051e2463d8 Content-Type: text/plain; charset=UTF-8 On Aug 25, 2015 7:42 AM, "Viktor Dukhovni" wrote: > SSH now has ciphersuites where the payload length is encrypted, > IIRC via a key that is different from the payload key. Yeah, I'm not that enthusiastic about that feature, but if you want more complexity, it is possible. The authentication properties are interesting there, of course. --001a113a9160c07415051e2463d8 Content-Type: text/html; charset=UTF-8


On Aug 25, 2015 7:42 AM, "Viktor Dukhovni" <ietf-dane@dukhovni.org> wrote:
> SSH now has ciphersuites where the payload length is encrypted,
> IIRC via a key that is different from the payload key.
Yeah, I'm not that enthusiastic about that feature, but if you want more complexity, it is possible. The authentication properties are interesting there, of course.

--001a113a9160c07415051e2463d8-- From nobody Wed Aug 26 14:11:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B951B331B for ; Wed, 26 Aug 2015 14:11:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leMMkEvT-Jwt for ; Wed, 26 Aug 2015 14:11:03 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89ED1B3316 for ; Wed, 26 Aug 2015 14:11:02 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so127931517lbb.0 for ; Wed, 26 Aug 2015 14:11:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2F+970HLHgYsszzpry5ujq7CNTwTUyJhWe2zMFW2PHw=; b=IOKULOw0tCOzacCvzowhmaqYHLoybQCm4OGcaetimScLm5Kzt5z7aaHjnwn0FW2Xj2 0rQRq5ftfwodTZby5b4N50rVHrOyU1tdEZUlW9N8E9PgJKS09X2flzUuWMXEVFfj3lfI xo02VgFcM3osdVawpCkiDY5hLnLXI8F7fTcE3I8eTcBYm2s5JOr5RE9k28Z3qX5S3Sya /7h8N+oIZwkzhpVqMJP3kmIDdqDtvFWKedZdrd16SDqwdqqmb07lm4BrRltAdxIxYYAw 0HTQHJzfH91Ni8tuDjYkWwZHUIN0cRvuBD5US0U10a65kg5TJ0e/IOrWn3dGLOIkjIAP 6p6A== X-Gm-Message-State: ALoCoQlKRThiWQ9AOePWYX97pkpP1zFF+edRbq+Z4yLFIJWM1VSZvfK3wSH0bcm1BwfFfN4wniKj MIME-Version: 1.0 X-Received: by 10.152.45.69 with SMTP id k5mr476218lam.13.1440623461372; Wed, 26 Aug 2015 14:11:01 -0700 (PDT) Received: by 10.112.122.17 with HTTP; Wed, 26 Aug 2015 14:11:01 -0700 (PDT) Date: Wed, 26 Aug 2015 14:11:01 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c28594abae1e051e3d494d Archived-At: Subject: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:11:04 -0000 --001a11c28594abae1e051e3d494d Content-Type: text/plain; charset=UTF-8 It looks like we have good consensus on PR 169 to relax certificate list ordering requirements. I had one question on the revised text. I'm unclear on the final clause in this section: "Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates they may require." I just want to make sure there isn't the intention of omitting certificates that are not seif-signed. Thanks, Joe --001a11c28594abae1e051e3d494d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It looks like we have good consensus on PR 169 to relax ce= rtificate list ordering requirements.=C2=A0 I had one question on the revis= ed text.=C2=A0 I'm unclear on the final clause in this section:
"Because certificate validation requires that trust anchor= s be distributed independently, a self-signed certificate that specifies a = trust anchor MAY be omitted from the chain, provided that supported peers a= re known to possess any omitted certificates they may require." =C2=A0=

I just want to make sure there isn't the inte= ntion of omitting certificates that are not seif-signed. =C2=A0
<= br>
Thanks,

Joe
--001a11c28594abae1e051e3d494d-- From nobody Wed Aug 26 14:42:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2E1B2D19 for ; Wed, 26 Aug 2015 14:42: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 32mcYbQti53G for ; Wed, 26 Aug 2015 14:42:04 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98151ACE4A for ; Wed, 26 Aug 2015 14:42:03 -0700 (PDT) Received: by qgeg42 with SMTP id g42so431041qge.1 for ; Wed, 26 Aug 2015 14:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=SNtghEVUnowZG6+mwGbF1bCpDjR6CgkEXIHGJ0tatw4=; b=XZplGQUeSNmD5OU1+c5uZJ3lSyva2ZPKaMsalK6eWvrIDOWHBTScoeuwWPXSLh9LNP 06z4sQLHIJqtSJqJHTptAYYw6LrqcGf3gQHj4j1LEjJj9HSpGCQ0DSTs69Stfvgj6sXx Wrnd8m6VkuiDlzlFD8kdMQLyIvU8rcJj1YchKH2dSlYvrKYp4E6QKNNQCwi0axd+n33I dTTMCUm87WHOQ1wM/ZfHIByaEIDwzyN3EV891I8rB381a7wQzXX0IIJIBF/uuvWM3Wrh pKoJbFvXRBrtUKH4AI1LCj13H2d+Wm/AHnXHipYx91K0ILNd4/u5CCzXEl/JQkzB3cV0 nT0A== X-Received: by 10.140.194.17 with SMTP id p17mr1390268qha.62.1440625322729; Wed, 26 Aug 2015 14:42:02 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 184sm15588qhy.6.2015.08.26.14.42.02 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 26 Aug 2015 14:42:02 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 26 Aug 2015 17:42:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201508261742.01242.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:42:05 -0000 On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: > It looks like we have good consensus on PR 169 to relax certificate list > ordering requirements. I had one question on the revised text. I'm > unclear on the final clause in this section: > > "Because certificate validation requires that trust anchors be distributed > independently, a self-signed certificate that specifies a trust anchor MAY > be omitted from the chain, provided that supported peers are known to > possess any omitted certificates they may require." > > I just want to make sure there isn't the intention of omitting certificates > that are not seif-signed. Well, technically anything can be omitted; it just won't validate. :p I'm not opposed to tweaking the wording here, but I don't really see it as a problem. If someone does, though, that's reason enough for me to agree to changing it. Simplest change is: "any omitted certificates they may require" -> "it" \/ "Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess it." Dave From nobody Wed Aug 26 14:43:25 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8EC1B2CC7 for ; Wed, 26 Aug 2015 14:43: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 X67D4lfCwjdY for ; Wed, 26 Aug 2015 14:43:22 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA591A8774 for ; Wed, 26 Aug 2015 14:43:22 -0700 (PDT) Received: by ykbi184 with SMTP id i184so651601ykb.2 for ; Wed, 26 Aug 2015 14:43: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=JnB0dyWhMzGn3Kdo7IcP0ujMJzY/lAJwOBe/zQM1PvU=; b=MYooW1M4AHvdldsvrK57fbQoE/b8K1rS2DNcFpReYY4gEhQNX+JCoCP9fjebx7hJpm 58mRk9+1FjRDtE7mpPYR1j/MW36FUzQyOUMc9KQ7eSX5RNYV2NhDjegFWuNQNMo1ZakV oj6PG0RrPH6TWvnwiyMNJBYSK3ymhZyfunQ4E6p54oxbgGX8DeXTlEOg2ME8o75qdfMm j0hCiJbR/m2QB0NOQGs2drrFSyyAqFV+KAcIqjpUMl1GxqFjauWDj0wBRZAkkjP8v4i5 4AYMHYlhVjLGAGNmoQkUG0BBx8Vq4SgyizaSSjTOK8Jgt+eXxl3eQ5I/L2uQPWr3hbHc rkjQ== MIME-Version: 1.0 X-Received: by 10.129.49.200 with SMTP id x191mr791088ywx.56.1440625401911; Wed, 26 Aug 2015 14:43:21 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Wed, 26 Aug 2015 14:43:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Aug 2015 14:43:21 -0700 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:43:24 -0000 On 26 August 2015 at 14:11, Joseph Salowey wrote: > "Because certificate validation requires that trust anchors be distributed > independently, a self-signed certificate that specifies a trust anchor MAY > be omitted from the chain, provided that supported peers are known to > possess any omitted certificates they may require." I always thought that the primary reason for omitting a certificate was that you had a good reason to expect that clients had the certificate already. Whether the certificate is self-signed seems like a poor proxy for that. From nobody Wed Aug 26 14:46:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6FF1B32C9 for ; Wed, 26 Aug 2015 14:46:00 -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_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUHrxU_U_tpf for ; Wed, 26 Aug 2015 14:45:57 -0700 (PDT) Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345E51B32C6 for ; Wed, 26 Aug 2015 14:45:57 -0700 (PDT) Received: by gateway24.websitewelcome.com (Postfix, from userid 500) id C35A6C32CFCE8; Wed, 26 Aug 2015 16:45:56 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway24.websitewelcome.com (Postfix) with ESMTP id B3432C32CFC98 for ; Wed, 26 Aug 2015 16:45:56 -0500 (CDT) Received: from [96.231.216.201] (port=53803 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZUiW4-000JQ0-4a for tls@ietf.org; Wed, 26 Aug 2015 16:45:56 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <093BBB86-E367-4FF8-83A3-4CB35835B245@ieca.com> Date: Wed, 26 Aug 2015 17:45:54 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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.216.201 X-Exim-ID: 1ZUiW4-000JQ0-4a X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:53803 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] consensus: signature_algorithms extension as MTI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:46:01 -0000 All, After reviewing threads concerning whether the signature_algorithms = extension should be MTI, the general consensus on the list seems to = prefer making the signature_algorithms extension MTI for TLS 1.3. =20 ekr - Please incorporate this into the next version of the TLS 1.3. spt= From nobody Wed Aug 26 14:50:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2529F1B3354 for ; Wed, 26 Aug 2015 14:50:30 -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 5LO_qt0oo2-s for ; Wed, 26 Aug 2015 14:50:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D561B3345 for ; Wed, 26 Aug 2015 14:50:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 15E5C284D24; Wed, 26 Aug 2015 21:50:24 +0000 (UTC) Date: Wed, 26 Aug 2015 21:50:23 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150826215023.GF9021@mournblade.imrryr.org> 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: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 21:50:30 -0000 On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote: > It looks like we have good consensus on PR 169 to relax certificate list > ordering requirements. I had one question on the revised text. I'm > unclear on the final clause in this section: > > "Because certificate validation requires that trust anchors be distributed > independently, a self-signed certificate that specifies a trust anchor MAY > be omitted from the chain, provided that supported peers are known to > possess any omitted certificates they may require." > > I just want to make sure there isn't the intention of omitting certificates > that are not seif-signed. There is no such intention, the new text in question expands on existing text in previous versions of TLS that specifically blesses omission of self-signed issuers. Such omission is no longer universally applicable, since with DANE-TA(2) for example, even self-signed issuers MUST be included in the server chain. https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.2.2 So the intent here is to hedge the circumstances under which chain elements are ommitted. This is not an attempt to bless further chain optimization. What's new here is the "provided that ...". -- Viktor. From nobody Wed Aug 26 22:25:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6282B1ACE87 for ; Wed, 26 Aug 2015 22:25:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFGtnhfv0m-t for ; Wed, 26 Aug 2015 22:25:09 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414A21ACE3F for ; Wed, 26 Aug 2015 22:25:09 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so4600005lbb.0 for ; Wed, 26 Aug 2015 22:25: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:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=69bE6GgkAX3pzWQPV3D5ojh7GbmQRY6MpR+lzlbTXII=; b=FEPvwhwKVtY9Gm0GZGjpoFeGZkpqrLnj+57+Qe/MOqpQixXjVMvC7QpwpbmC6KuJKU KWQlET+8yXHPwtrc/7bAGenXm+Kxc0fFP9Y8GFmgCChAYLDVafUxXsGmelY+xcGBV15w 8ZNQiHzUZF5N9QMiWDKW9QKFgG+2tevcefub4SdzgGcupy18FjhlvAeeQjZ9Z1wqIbd1 7hAjrT4d3ez+YLjVlueLUDVDa3sQRYUuMXxRV+8LI3fv0X4oW8SxPUeAm6nZO9JRG7h4 R/JSV5VUBR8mK9PYKM0wciuqKs/NqNH2rs4nlOUKGcUpWj+KNmRU+kfrEp7PDJnHKXNL i6HA== X-Gm-Message-State: ALoCoQkQEx2TfJDGn8lfSpbFRNc/HQgmnRpzLCMybY1s+E7qTShz/1ET6CflAiTJR1c5ysFSzTRf MIME-Version: 1.0 X-Received: by 10.112.14.8 with SMTP id l8mr1249108lbc.68.1440653107588; Wed, 26 Aug 2015 22:25:07 -0700 (PDT) Received: by 10.112.122.17 with HTTP; Wed, 26 Aug 2015 22:25:07 -0700 (PDT) In-Reply-To: <20150826215023.GF9021@mournblade.imrryr.org> References: <20150826215023.GF9021@mournblade.imrryr.org> Date: Wed, 26 Aug 2015 22:25:07 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c36b74b90d18051e4430f1 Archived-At: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 05:25:12 -0000 --001a11c36b74b90d18051e4430f1 Content-Type: text/plain; charset=UTF-8 Thanks Viktor, I missed this part of the discussion. The text looks fine to me as is. Joe On Wed, Aug 26, 2015 at 2:50 PM, Viktor Dukhovni wrote: > On Wed, Aug 26, 2015 at 02:11:01PM -0700, Joseph Salowey wrote: > > > It looks like we have good consensus on PR 169 to relax certificate list > > ordering requirements. I had one question on the revised text. I'm > > unclear on the final clause in this section: > > > > "Because certificate validation requires that trust anchors be > distributed > > independently, a self-signed certificate that specifies a trust anchor > MAY > > be omitted from the chain, provided that supported peers are known to > > possess any omitted certificates they may require." > > > > I just want to make sure there isn't the intention of omitting > certificates > > that are not seif-signed. > > There is no such intention, the new text in question expands on > existing text in previous versions of TLS that specifically blesses > omission of self-signed issuers. Such omission is no longer > universally applicable, since with DANE-TA(2) for example, even > self-signed issuers MUST be included in the server chain. > > https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.2.2 > > So the intent here is to hedge the circumstances under which chain > elements are ommitted. This is not an attempt to bless further > chain optimization. What's new here is the "provided that ...". > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c36b74b90d18051e4430f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Viktor, =C2=A0I missed this part of the discussion.= =C2=A0 The text looks fine to me as is.

Joe
<= div class=3D"gmail_extra">
On Wed, Aug 26, 20= 15 at 2:50 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>= wrote:
On Wed, Aug 26, = 2015 at 02:11:01PM -0700, Joseph Salowey wrote:

> It looks like we have good consensus on PR 169 to relax certificate li= st
> ordering requirements.=C2=A0 I had one question on the revised text.= =C2=A0 I'm
> unclear on the final clause in this section:
>
> "Because certificate validation requires that trust anchors be di= stributed
> independently, a self-signed certificate that specifies a trust anchor= MAY
> be omitted from the chain, provided that supported peers are known to<= br> > possess any omitted certificates they may require."
>
> I just want to make sure there isn't the intention of omitting cer= tificates
> that are not seif-signed.

There is no such intention, the new text in question expands on
existing text in previous versions of TLS that specifically blesses
omission of self-signed issuers.=C2=A0 Such omission is no longer
universally applicable, since with DANE-TA(2) for example, even
self-signed issuers MUST be included in the server chain.

=C2=A0 =C2=A0 https://tools.ietf.org= /html/draft-ietf-dane-ops-16#section-5.2.2

So the intent here is to hedge=C2=A0 the circumstances under which chain elements are ommitted.=C2=A0 This is not an attempt to bless further
chain optimization.=C2=A0 What's new here is the "provided that ..= .".

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--001a11c36b74b90d18051e4430f1-- From nobody Thu Aug 27 01:37:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5A1B39C1 for ; Thu, 27 Aug 2015 01: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 7cyzxR6YwiWW for ; Thu, 27 Aug 2015 01:37:41 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B82F1B36F4 for ; Thu, 27 Aug 2015 01:37:41 -0700 (PDT) Received: by iodt126 with SMTP id t126so49221175iod.2 for ; Thu, 27 Aug 2015 01:37: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:from:date:message-id:subject:to :cc:content-type; bh=HvNLDXTG+1tNyMnoMF5CjQrwCyM4Wqe4ZFncDpE53NI=; b=cXwW2rUe1zDCk1tgnJq4SsEm/3L+62yI0YcYC8zXFDcm4D4tGOhHKUYqRvRJwmuzaD FyDXOtyqSDXiYqRW0AX0nkHO1Orsf0c8t25ud01qOFY2p7l6p78G483GNg+4B14zqpa0 1XfDjXRdZx9SyY4OrfipcIU/+QHgV5csTBjgU8zl07MYQIfBJU/+NBX/3wMfP/mhWfAk nT0VD0o4lGVu9dObNtt3T4Oe5PcIlwKf9tiqMOlASbqW7oU7zd+R4Idqdk8jQVCqMtyS 9YVSz7fkEi325MnysEfAsaSlzivQj223LwMEr3MwOLG6gcL3CgWHI7L8KdaKg+hKKNXj W4Jg== X-Received: by 10.107.151.194 with SMTP id z185mr8663097iod.63.1440664661055; Thu, 27 Aug 2015 01:37:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.68 with HTTP; Thu, 27 Aug 2015 01:37:01 -0700 (PDT) In-Reply-To: References: From: "Viktor S. Wold Eide" Date: Thu, 27 Aug 2015 10:37:01 +0200 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140e36a5cde90051e46e13f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 08:37:43 -0000 --001a1140e36a5cde90051e46e13f Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > > > On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < > viktor.s.wold.eide@gmail.com> wrote: > >> Hi, >> >> I am looking for a way to achieve identity hiding for DTLS 1.2, which >> also hopefully can be used in (D)TLS 1.3, when available. >> >> From what I understand, for (D)TLS 1.2 it would be possible to perform an >> anonymous unencrypted handshake and then to renegotiate the connection with >> authentication within the encrypted channel, e.g., according to the expired >> draft [1]. From the latest TLS 1.3 draft [2] it appears that renegotiation >> will be removed in the upcoming 1.3 version. >> >> What is likely to be the recommended way to achieve identity hiding for >> (D)TLS 1.3, if any? >> >> [1] Transport Layer Security (TLS) Encrypted Handshake Extension, >> draft-ray-tls-encrypted-handshake-00, expired in 2012 >> [2] The Transport Layer Security (TLS) Protocol Version 1.3, >> draft-ietf-tls-tls13-07 >> >> > TLS 1.3 encrypts both the client's and server's certificates already. > The server's certificate is secure only against passive attack. The > client's is encrypted with a key that the client can authenticate as > belonging to the server. > > Thanks a lot for the clarification. Would it be reasonable to include your answer or something similar into the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" section? Best regards Viktor S. Wold Eide --001a1140e36a5cde90051e46e13f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <ekr@rtfm.com> wr= ote:
=

On Mon,= Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <viktor.s.wold.ei= de@gmail.com> wrote:
Hi,

I am lo= oking for a way to achieve identity hiding for DTLS 1.2, which also hopeful= ly can be used in (D)TLS 1.3, when available.

From what I unde= rstand, for (D)TLS 1.2 it would be possible to perform an anonymous unencry= pted handshake=20 and then to renegotiate the connection with authentication within the encry= pted channel, e.g., according to the expired draft [1]. From the latest TLS= 1.3 draft [2] it appears that renegotiation will be removed in the upcomin= g 1.3 version.

What is likely to be the recommended way t= o achieve identity hiding for (D)TLS 1.3, if any?

[= 1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transpor= t Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07

TLS 1.3 encrypts both = the client's and server's certificates already.
The serve= r's certificate is secure only against passive attack. The
cl= ient's is encrypted with a key that the client can authenticate as
belonging to the server.


Thanks a lot for the clarification.
Would it be reasonable to include your answer or something similar into the TLS=20 1.3 draft, for example in the "Major Differences from TLS 1.2" se= ction?

Best regards
Viktor S. Wold Eide

--001a1140e36a5cde90051e46e13f-- From nobody Thu Aug 27 01:40:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629F01B3A3B for ; Thu, 27 Aug 2015 01:40:47 -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 gHzHvU_3EF-L for ; Thu, 27 Aug 2015 01:40:46 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63981B3A7A for ; Thu, 27 Aug 2015 01:40:45 -0700 (PDT) Received: by ignq3 with SMTP id q3so3810549ign.1 for ; Thu, 27 Aug 2015 01:40: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:from:date:message-id:subject:to :cc:content-type; bh=E0U2db+RiC9V0WmDlgjjOLhPMxse+O7orpU3CYkcF/I=; b=YatI1+XYpmDlJHgXjJieyVPT1DHbbdnJnAOvcnnv2o/5ryOZzrFCf0YtUtuThWAMAp 4eUx2ZLhbdfohSn+luj80UNvPXjX84X77dtlYfHUO6+4rGohBofukx5sBVg/3dvPb4xV w7EkcxJtbXUkMcquZFtVmxk+kb/N3eZj8edw+Hr9uILv13tQVSzwRPYU9DxU3/4Fj67J JjgJX7RfznE+LF4WGFMLCqCHwJeEZCQs0K/W19eYYNCK/mK3buj8PHJvd6X2E5dCXFct QQsX0uTQ9ut8jb+SBVbRClQDiZ2fBYLJT3cR3OPhBtzv4TXY+WE+BqkUjwJA72GWXedb iLLQ== X-Received: by 10.50.142.1 with SMTP id rs1mr8838416igb.17.1440664845264; Thu, 27 Aug 2015 01:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.68 with HTTP; Thu, 27 Aug 2015 01:40:05 -0700 (PDT) In-Reply-To: References: From: "Viktor S. Wold Eide" Date: Thu, 27 Aug 2015 10:40:05 +0200 Message-ID: To: Badra Content-Type: multipart/alternative; boundary=001a1130c35657afd5051e46ecb1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 08:40:47 -0000 --001a1130c35657afd5051e46ecb1 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 25, 2015 at 12:19 AM, Badra wrote: > Hi, > > Another solution was approved for publication as experimental by IESG in > 2009 but I declined to process with Pasi Eronen way (previous WG co-Chair) > of publishing the document. > > It is available at > https://tools.ietf.org/html/draft-hajjeh-tls-identity-protection-09 and > it works for TLS and DTLS > > Thanks for the reference. Best regards Viktor S. Wold Eide --001a1130c35657afd5051e46ecb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Aug 25, 2015 at 12:19 AM, Badra <badra@isima.fr> wrote:=
Hi,

Anothe= r solution was approved for publication as experimental by IESG in 2009 but= I declined to process with Pasi Eronen way (previous WG co-Chair) of publi= shing the document.

It is available at=C2=A0https://tools.ietf.org/html/draft-hajjeh-tls-identity-prot= ection-09 and it works for TLS and DTLS


Thanks for the reference.

Best regards
Viktor S. Wold Ei= de

--001a1130c35657afd5051e46ecb1-- From nobody Thu Aug 27 01:43:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573D1A879B for ; Thu, 27 Aug 2015 01:43: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 TKshjec6uNnm for ; Thu, 27 Aug 2015 01:43:24 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6D71A1A69 for ; Thu, 27 Aug 2015 01:43:24 -0700 (PDT) Received: by igcse8 with SMTP id se8so61875062igc.1 for ; Thu, 27 Aug 2015 01:43: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=RAJFRrHJzzceeQXGcVfLwwfdidCYLsvHpV098q0fQyQ=; b=wLHkTuc5bh8TTOp0GpHLph71obJkhl4nao5utStVJP+/PT5MQzcBQuYSELtWrbC1ii UGywf0bL1TQwDEpLH0e9yU3shj6+8CaG8iT27P7LMIH00WKdOxDWJy0nTGPbL6cXYbfi 7TX+2naCRnewZGdV4k+thDDogl3LeygjEtgd4zuqB8s7f9CWZZcXek0nJj7xIxycPDbz f0W1Ciz7PRZvBWyS5NyIlnn98bZWD7aNNzLBAPmzSK9jJqbelfd1eirh0fLizyw4ItFu zsEYDdjlhsnaF5+0hH8108Ll00kyBHU36fE0JJp+2NOgLDVe/ztOQX5nu535izEc0oht FjHQ== X-Received: by 10.50.93.102 with SMTP id ct6mr8133325igb.75.1440665003642; Thu, 27 Aug 2015 01:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.68 with HTTP; Thu, 27 Aug 2015 01:42:44 -0700 (PDT) In-Reply-To: References: From: "Viktor S. Wold Eide" Date: Thu, 27 Aug 2015 10:42:44 +0200 Message-ID: To: Pascal Urien Content-Type: multipart/alternative; boundary=047d7b160275c8560e051e46f5a7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 08:43:25 -0000 --047d7b160275c8560e051e46f5a7 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 25, 2015 at 10:43 AM, Pascal Urien wrote: > Hi > > a working solution fot TLS 1.0,1.1, 1.2, DTLS 1.0, 1.2 is to encrypt > the client certificat with an extra key computed from the master > secret > > see > > https://tools.ietf.org/html/draft-urien-badra-eap-tls-identity-protection-01 > > Thanks for the suggestion and for the reference. Best regards Viktor S. Wold Eide --047d7b160275c8560e051e46f5a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Aug 25, 2015 at 10:43 AM, Pascal Urien <pascal.urien@gmail.co= m> wrote:
https://tools.ietf.org/h= tml/draft-urien-badra-eap-tls-identity-protection-01


Thanks for the suggestion and for the reference.=

Best regards
Viktor S. Wold Eide

--047d7b160275c8560e051e46f5a7-- From nobody Thu Aug 27 02:14:44 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72DD1A8F3B for ; Thu, 27 Aug 2015 02:14:42 -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 MCScS6SQo8i8 for ; Thu, 27 Aug 2015 02:14:41 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9C91A8AAF for ; Thu, 27 Aug 2015 02:14:41 -0700 (PDT) Received: by igui7 with SMTP id i7so56838668igu.1 for ; Thu, 27 Aug 2015 02:14: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:from:date:message-id:subject:to :content-type; bh=oz6I32dNSWcPP/XpXGrQvb0ErFxO4VsYPpFov/td7Qg=; b=Tt0XRuu3ob+aw8O1g7PSvIjfOCGGMDKhUlKVLX6ApqIJbLK8zgWu7RmaKklcvRJ7k2 XJehN9CzBa/qsgI4/q9jhHHs/+3PhyUJwM80vaJpWSEHVctUVuAUon7gEktQF3/vUmIN KMnajyN8vZq2PNkpvTbaevMmmgvOowiYwzA3Ndhh50P6J/I4xWp4QkD/uqrQXqerXUqC 5Uc+qUV5HcafrMDm69aITF27FJF7uMi5FWzqFiAkd+0D0grNe1Pqw/Aru2zmLAg1O+QX z/S02u4IReqHacM4yH1b/i7VvIHGaBQLKEnniAdJkuyKCFAEtfc2IMsodcxBI4lqSPR2 nY0A== X-Received: by 10.50.93.102 with SMTP id ct6mr8211864igb.75.1440666881006; Thu, 27 Aug 2015 02:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.68 with HTTP; Thu, 27 Aug 2015 02:14:01 -0700 (PDT) In-Reply-To: References: From: "Viktor S. Wold Eide" Date: Thu, 27 Aug 2015 11:14:01 +0200 Message-ID: To: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b160275aea3e7051e47658e Archived-At: Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 09:14:43 -0000 --047d7b160275aea3e7051e47658e Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > > > TLS 1.3 encrypts both the client's and server's certificates already. > The server's certificate is secure only against passive attack. The > client's is encrypted with a key that the client can authenticate as > belonging to the server. > > It's good to see that both the client's and the server's certificates are encrypted in TLS 1.3, providing protection against passive eavesdropping. For some use cases it might be worthwhile to reduce the information made available to an active attacker also. Are there any suggestions in this direction for TLS 1.3? One might think of a multi stage approach, something like: - Anonymous connection establishment, resulting in a secure channel. - Authentication by means of group certificate. - Authentication by means of a host specific certificate. The purpose of the second step above is to first only provide the group identity to an active attacker, and then to reveal the host identities (certificate information) only after group membership has been mutually authenticated. Does something like this seem reasonable for TLS 1.3 or are there any other ways for providing protection of identities against an active attack? Best regards Viktor S. Wold Eide --047d7b160275aea3e7051e47658e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <ekr@rtfm.com= > wrote:

TLS 1.3 encrypts both the client's and server's certificate= s already.
The server's certificate is secure only against passive = attack. The
client's is encrypted with a key that the client = can authenticate as
belonging to the server.

=

<= br>
It's good to see that both the client's and=20 the server's certificates are encrypted in TLS 1.3, providing protectio= n against passive eavesdropping.

For some use cases it=20 might be worthwhile to reduce the information made available to an=20 active attacker also. Are there any suggestions in this direction for=20 TLS 1.3?

One might think of a multi stage approach, somet= hing like:
- Anonymous connection establishment, resulting in a secure c= hannel.
- Authentication by means of group certificate.
- Authentication by means of a host specific certificate.

<= /div>
The purpose of the second step above is to first only provide the group=20 identity to an active attacker, and then to reveal the host identities (cer= tificate information) only after group membership has been mutually authent= icated.

Does something like this seem reasonable for TLS 1.3 or are there any other=20 ways for providing protection of identities against an active attack?

Best regards
Viktor S. Wold Eide

--047d7b160275aea3e7051e47658e-- From nobody Thu Aug 27 04:17:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605381B2CB0 for ; Thu, 27 Aug 2015 04:17:52 -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 ZbLRbB-C9r77 for ; Thu, 27 Aug 2015 04:17:50 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C56B1B2BEF for ; Thu, 27 Aug 2015 04:17:49 -0700 (PDT) Received: by wicne3 with SMTP id ne3so599281wic.0 for ; Thu, 27 Aug 2015 04:17: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:from:date :message-id:subject:to:cc:content-type; bh=ZEU48+SmP4quW/gKuQSKWVlQh0cGM9HFNIgwpGWAJhk=; b=Hqzbaxa5yHHBSlgb6L3xgubv5tGbfGgOhH4Ng3hPw5DTFMdS4b9Hc6NXgNsn6HIg+d m0EIhc607yxoPbcDn03AR0K/d5cdN47VrhAmvFWeCZR9HBu+EVD659oJ2ERPQyGRrzKN kNH6sYn+vgJnrn495uf5gB+Z6WBVoilKLmHOFTKCLRo17zwIKu1FL9w7Sz6XrrMhn21V /KSPi8BCmDHXrd+fxSokkchz2hY6MwrGlXpwF4g/ZFwoB3nrqE0hC61TnUt8pT5VHAoU A2IRQaJdZA8ltD6WSHh55q3h0gY5Ut1908r3cyu+iEJT+MVmvjaxL+ro7eswI8O3O3GP cB+A== X-Gm-Message-State: ALoCoQmREkjFj7Ug04HGeDeOTiJR3IAcabyX+S80j6m7nsBmJD85YhlPfqkfvLe5KwyaIN5XWq8b X-Received: by 10.194.133.73 with SMTP id pa9mr4140613wjb.148.1440674268334; Thu, 27 Aug 2015 04:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 04:17:08 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Aug 2015 04:17:08 -0700 Message-ID: To: "Viktor S. Wold Eide" Content-Type: multipart/alternative; boundary=089e011771a9006279051e491e9e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 11:17:52 -0000 --089e011771a9006279051e491e9e Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide < viktor.s.wold.eide@gmail.com> wrote: > > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide < >> viktor.s.wold.eide@gmail.com> wrote: >> >>> Hi, >>> >>> I am looking for a way to achieve identity hiding for DTLS 1.2, which >>> also hopefully can be used in (D)TLS 1.3, when available. >>> >>> From what I understand, for (D)TLS 1.2 it would be possible to perform >>> an anonymous unencrypted handshake and then to renegotiate the connection >>> with authentication within the encrypted channel, e.g., according to the >>> expired draft [1]. From the latest TLS 1.3 draft [2] it appears that >>> renegotiation will be removed in the upcoming 1.3 version. >>> >>> What is likely to be the recommended way to achieve identity hiding for >>> (D)TLS 1.3, if any? >>> >>> [1] Transport Layer Security (TLS) Encrypted Handshake Extension, >>> draft-ray-tls-encrypted-handshake-00, expired in 2012 >>> [2] The Transport Layer Security (TLS) Protocol Version 1.3, >>> draft-ietf-tls-tls13-07 >>> >>> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > Thanks a lot for the clarification. > > Would it be reasonable to include your answer or something similar into > the TLS 1.3 draft, for example in the "Major Differences from TLS 1.2" > section? > Sure. It's mostly a changelog now, but I'll try to add something. -Ekr > Best regards > Viktor S. Wold Eide > > --089e011771a9006279051e491e9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide = <vikto= r.s.wold.eide@gmail.com> wrote:

On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <ekr@rtfm= .com> wrote:


On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <viktor.s.wold.eide@gmail.com> wrote:
Hi,=

I am looking for a way to achieve identity hiding for DTLS 1= .2, which also hopefully can be used in (D)TLS 1.3, when available.

=
From what I understand, for (D)TLS 1.2 it would be possible to perfor= m an anonymous unencrypted handshake=20 and then to renegotiate the connection with authentication within the encry= pted channel, e.g., according to the expired draft [1]. From the latest TLS= 1.3 draft [2] it appears that renegotiation will be removed in the upcomin= g 1.3 version.

What is likely to be the recommended way t= o achieve identity hiding for (D)TLS 1.3, if any?

[= 1] Transport Layer Security (TLS) Encrypted Handshake Extension, draft-ray-tls-encrypted-handshake-00, expired in 2012
[2] The Transpor= t Layer Security (TLS) Protocol Version 1.3, draft-ietf-tls-tls13-07

TLS 1.3 encrypts both = the client's and server's certificates already.
The serve= r's certificate is secure only against passive attack. The
cl= ient's is encrypted with a key that the client can authenticate as
belonging to the server.


Thanks a lot for the clarifica= tion.

Would it be reasonable to include your answer or something similar into the TLS=20 1.3 draft, for example in the "Major Differences from TLS 1.2" se= ction?

Sure. It= 's mostly a changelog now, but I'll try to add something.

-Ekr




=C2=A0
Best regards
= Viktor S. Wold Eide


--089e011771a9006279051e491e9e-- From nobody Thu Aug 27 04:18:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748311A1BD9 for ; Thu, 27 Aug 2015 04:18: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 XxgyIrvTpNX2 for ; Thu, 27 Aug 2015 04:18:49 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82AE1A88AE for ; Thu, 27 Aug 2015 04:18:48 -0700 (PDT) Received: by widdq5 with SMTP id dq5so41645408wid.0 for ; Thu, 27 Aug 2015 04:18:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FiSKjIL9Un1zebMa8k4rm3dVmjFFirGjR4TxmTasj0k=; b=i/I0CEFD2xrjn1NCPZRiE2YQGUoM2vOphP7+LWc6LnDEQP3AOKOKCWruwq03osqGjX cLctjpTtMYRokTcq8YiES+ITVNo6qxplyVP2g9KH8oSxPaLSeaP4UHzdl9BxyvElXdL8 ns1GnaRhYQ1koLdKB4jEvdbBxWC40hiFQRyu7ZO2EWuC9/YKO37kr86BxQCQ4LO2Nes5 u9NxjdD2JoRWtyvHIc0l939itakxzt+MnbGHluAYBBsi+xRiAtEH2hi/0BCdA9QRf5LU UVNLkh1Lub9EdakTRNhM5YTLFywhBlZTcuRar1+D736tBGczwGEhAyImIyk23HNRg97M QvOQ== X-Gm-Message-State: ALoCoQlzsCeNhUZVF6o8+yFTHmcxxuSj7PJc8+K8XO3Y+a06gik56ED2bggyYrqWtWuGDx5gAViy X-Received: by 10.180.74.148 with SMTP id t20mr18783226wiv.31.1440674327712; Thu, 27 Aug 2015 04:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 04:18:08 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Aug 2015 04:18:08 -0700 Message-ID: To: "Viktor S. Wold Eide" Content-Type: multipart/alternative; boundary=f46d043c7f5c8a69f3051e4921bc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)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, 27 Aug 2015 11:18:50 -0000 --f46d043c7f5c8a69f3051e4921bc Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide < viktor.s.wold.eide@gmail.com> wrote: > On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: > >> >> >> TLS 1.3 encrypts both the client's and server's certificates already. >> The server's certificate is secure only against passive attack. The >> client's is encrypted with a key that the client can authenticate as >> belonging to the server. >> >> > > It's good to see that both the client's and the server's certificates are > encrypted in TLS 1.3, providing protection against passive eavesdropping. > > For some use cases it might be worthwhile to reduce the information made > available to an active attacker also. Are there any suggestions in this > direction for TLS 1.3? > > One might think of a multi stage approach, something like: > - Anonymous connection establishment, resulting in a secure channel. > - Authentication by means of group certificate. > - Authentication by means of a host specific certificate. > > The purpose of the second step above is to first only provide the group > identity to an active attacker, and then to reveal the host identities > (certificate information) only after group membership has been mutually > authenticated > I don't think this matches most TLS use cases very well, since the client generally isn't authenticated at all, so there's no point in the server progressively revealing more. -Ekr Does something like this seem reasonable for TLS 1.3 or are there any other > ways for providing protection of identities against an active attack? > > Best regards > Viktor S. Wold Eide > > --f46d043c7f5c8a69f3051e4921bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide = <vikto= r.s.wold.eide@gmail.com> wrote:
On Mon, Aug 24, 2015 at 11:17 PM, Er= ic Rescorla <ekr@rtfm.com> wrote:

TLS 1.3 encrypts both the client&= #39;s and server's certificates already.
The server's certifica= te is secure only against passive attack. The
client's is enc= rypted with a key that the client can authenticate as
belonging t= o the server.


=

It's good to see that = both the client's and=20 the server's certificates are encrypted in TLS 1.3, providing protectio= n against passive eavesdropping.

For some use cases it=20 might be worthwhile to reduce the information made available to an=20 active attacker also. Are there any suggestions in this direction for=20 TLS 1.3?

One might think of a multi stage approach, somet= hing like:
- Anonymous connection establishment, resulting in a secure c= hannel.
- Authentication by means of group certificate.
- Authentication by means of a host specific certificate.

<= /div>
The purpose of the second step above is to first only provide the group=20 identity to an active attacker, and then to reveal the host identities (cer= tificate information) only after group membership has been mutually authent= icated

I don't th= ink this matches most TLS use cases very well, since the client
g= enerally isn't authenticated at all, so there's no point in the ser= ver progressively
revealing more.

-Ekr

Does something like this seem reasonable for TLS 1.3 or are there any other=20 ways for providing protection of identities against an active attack?
=
=C2=A0
Best regard= s
Viktor S. Wold Eide


--f46d043c7f5c8a69f3051e4921bc-- From nobody Thu Aug 27 10:22:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70091B3C77 for ; Thu, 27 Aug 2015 10:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSRxfACyl6D1 for ; Thu, 27 Aug 2015 10:22:33 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFFA1B3CAB for ; Thu, 27 Aug 2015 10:22:33 -0700 (PDT) Received: by igui7 with SMTP id i7so66415232igu.1 for ; Thu, 27 Aug 2015 10:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=XqVe37WTBCqKR3Oi1qupYPRV8Dg2hEoo2VrxPLCq4Do=; b=S5nxU4rb/+PdYqd/TyV1XvWMACytGfm5LnF1wwSOBsFD4XmANpYx+QFZiLh/AslnoE FI2exiVwYeJWdYozmSQwHuwwba9Wf1hksjDBwHmvwKuRFZkBSktIMg1L8PRNqUP4Ym+B Nx/7GcZt1Q/mp6HHorTnKxvVkv8PGkJonGlvoc2Uh8cLGUn9wzghZGu4I6r57l+9S4tg /rhkiNAEeFtpQofFcurggB5GNYB5if2ytG6qTfAiTAQWurPjPoyzgKif0B9X1vLFAeSP M+dbTMQPGhurq29E14k4cqn7OciwacvhFFn2wsGhc0iR971HSTq9Un3KL09bdDfWKRrZ btLQ== X-Received: by 10.50.79.202 with SMTP id l10mr10418411igx.7.1440696152542; Thu, 27 Aug 2015 10:22:32 -0700 (PDT) Received: from wcygchokhani (d226-123-206.home.cgocable.net. [24.226.123.206]) by smtp.gmail.com with ESMTPSA id yr6sm6362279igb.14.2015.08.27.10.22.31 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Aug 2015 10:22:31 -0700 (PDT) From: "Santosh Chokhani" To: "'Dave Garrett'" , References: <201508261742.01242.davemgarrett@gmail.com> In-Reply-To: <201508261742.01242.davemgarrett@gmail.com> Date: Thu, 27 Aug 2015 13:22:33 -0400 Message-ID: <029b01d0e0ec$f6706890$e35139b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH8kcAbrURJ+nrXVHG9nAKgjV7ZWgJFzuk5nbaEuoA= Content-Language: en-us Archived-At: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:22:34 -0000 To me it seems that both of these wordings could be interpreted by someone that if you do not have a trust anchor and you get it in the TLS handshake, you can use it and trust it. That sounds dangerous. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett Sent: Wednesday, August 26, 2015 5:42 PM To: tls@ietf.org Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: > It looks like we have good consensus on PR 169 to relax certificate > list ordering requirements. I had one question on the revised text. > I'm unclear on the final clause in this section: > > "Because certificate validation requires that trust anchors be > distributed independently, a self-signed certificate that specifies a > trust anchor MAY be omitted from the chain, provided that supported > peers are known to possess any omitted certificates they may require." > > I just want to make sure there isn't the intention of omitting > certificates that are not seif-signed. Well, technically anything can be omitted; it just won't validate. :p I'm not opposed to tweaking the wording here, but I don't really see it as a problem. If someone does, though, that's reason enough for me to agree to changing it. Simplest change is: "any omitted certificates they may require" -> "it" \/ "Because certificate validation requires that trust anchors be distributed independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess it." Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 27 10:29:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2D1B2BF1 for ; Thu, 27 Aug 2015 10:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bjnJlCKI_rS for ; Thu, 27 Aug 2015 10:29:48 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4001B2A59 for ; Thu, 27 Aug 2015 10:29:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A328284D23; Thu, 27 Aug 2015 17:29:47 +0000 (UTC) Date: Thu, 27 Aug 2015 17:29:47 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150827172946.GR9021@mournblade.imrryr.org> References: <201508261742.01242.davemgarrett@gmail.com> <029b01d0e0ec$f6706890$e35139b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029b01d0e0ec$f6706890$e35139b0$@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:29:49 -0000 On Thu, Aug 27, 2015 at 01:22:33PM -0400, Santosh Chokhani wrote: > To me it seems that both of these wordings could be interpreted by someone > that if you do not have a trust anchor and you get it in the TLS handshake, > you can use it and trust it. > > That sounds dangerous. Beyond a general "there's no such thing as fool-proof", I don't see how such an interpretation might be arrived at. Trust-anchors are both frequently sent and frequently not sent in the TLS handshake. The new text just says that it may be acceptable to omit them, but sometimes clients need the trust-anchor certificate to be sent, because they verify it by fingerprint or similar, and don't have a (complete) local copy. The text is fine. -- Viktor. From nobody Thu Aug 27 11:48:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C561A1BDF for ; Thu, 27 Aug 2015 11:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCHkFthwt-gW for ; Thu, 27 Aug 2015 11:48:16 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3331B2E6C for ; Thu, 27 Aug 2015 11:48:16 -0700 (PDT) Received: by ykbi184 with SMTP id i184so29972975ykb.2 for ; Thu, 27 Aug 2015 11:48:15 -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=fwVGps26P1BE87NBFFia7MVfRPlZLIGEx2jwf0ENCx8=; b=SOLbneCjh5igVlHi4fqhupgxCxyN0++g72H6ywkDMQATxajPjcWjUadWHpNndKXc9J YlJj6yUWbHXmXeh+zgWH2pEiwLcsXp5PR66q4G7VlAT4ZFbgEpmy04qlLvAjX3TRYo0S nDW4Ssye/yDMaO67k9jsHxIRUMS52/E5Zx2TaGnVy+yo/T5TURK/YHwRNaWyB17zGsMW Ax3N2mgoGZRIIURl20FF/7k7IDNmQhSMLlaQF2w29tx0cL5skx9YDO7YKSiMSkGeb7e+ /+SceOKbXVy++ZY0gPRFmoQO6MRjxN6WGLvLFML8P7FT5ugc/ghysuVLesU20MaiL7A/ q/Fw== MIME-Version: 1.0 X-Received: by 10.170.57.202 with SMTP id 193mr4734934ykz.118.1440701295300; Thu, 27 Aug 2015 11:48:15 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 11:48:15 -0700 (PDT) Date: Thu, 27 Aug 2015 11:48:15 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:48:17 -0000 I've been looking at the latest TLS 1.3 spec and there are a lot of MUSTs that are completely toothless. To pick on a recent changeset: > The signature algorithm and hash algorithm MUST be a pair offered in the "signature_algorithms" extension (see {{signature-algorithms}}). > All implementations MUST use the "signature_algorithms" extension when offering and negotiating certificate authenticated cipher suites. > All implementations MUST use the "supported_groups" extension when offering and negotiating DHE or ECDHE cipher suites. This isn't good. "MUST" language MUST have consequences or you are left with all sorts of variations. If you don't stipulate consequences, then people violate the MUST and you get interop issues. I propose that we don't do this in future without due consideration. In all these cases, the peer that notices a violation of the requirement can (and I would argue MUST) fail the handshake and probably generate a fatal alert. The exceptions to this are where you need to permit non-compliant behaviour for legacy interoperability reasons. For TLS 1.3, I think that we can limit that to the ClientHello handling and - if we feel like we can mandate changes that affect TLS 1.2 or earlier for clients that support 1.3 - the ServerHello. I think only the ClientHello. From nobody Thu Aug 27 12:13:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CE81B3758 for ; Thu, 27 Aug 2015 12:13:20 -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 flBLMCHjo7I8 for ; Thu, 27 Aug 2015 12:13:19 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89841B340B for ; Thu, 27 Aug 2015 12:13:18 -0700 (PDT) Received: by widdq5 with SMTP id dq5so2306398wid.1 for ; Thu, 27 Aug 2015 12:13:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DNEisSLeJjGGNCXkHyuoP6uHJF1de3If8i7M7VDeIGg=; b=kpB5wzd9NDUCqGhalWGy9K6Hom1TzSVlFxpfigYe/8IxiUYN5xSv0Oj6UfMmnU6TDt /rk8CDl9CtnE9jueUmogh8DU2k8Or5QZXk5mkfkdp87E7I4lizhrkVT1WhWEMywV7wYF zmX343mArwFVhnMfJn8vP8v9AneNFw6f3Yn2hMvPCCryJnaIlqZ9Bj0jdrbGdRP0NFu6 d44zuZULHp2ddfG3RQku11a66U7vQDcAjvMMLhf42lBb/aGbI5KzMwzuukvK59zsIAqy npEgeY26PBgr/AK9ecHGKugXuh/4rOFGcWy7LMdQ0dRLrmxSskR/I4bWaxnoQ2wC5qWa SudA== X-Gm-Message-State: ALoCoQkDZm6HLXChFlhVZVpjKr5yEMRahVvYnB13n6L+8vjT4kj5f4zNVHC15zq3OS2T1YJ6sHjb X-Received: by 10.194.216.68 with SMTP id oo4mr6509497wjc.81.1440702797552; Thu, 27 Aug 2015 12:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 12:12:37 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 27 Aug 2015 12:12:37 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0141a09279b897051e4fc2a6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:13:20 -0000 --089e0141a09279b897051e4fc2a6 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 11:48 AM, Martin Thomson wrote: > I've been looking at the latest TLS 1.3 spec and there are a lot of > MUSTs that are completely toothless. To pick on a recent changeset: > > > The signature algorithm and hash algorithm MUST be a pair offered in the > "signature_algorithms" extension (see {{signature-algorithms}}). > I note that we had a very extensive discussio n > > All implementations MUST use the "signature_algorithms" extension when > offering and negotiating certificate authenticated cipher suites. > > > All implementations MUST use the "supported_groups" extension when > offering and negotiating DHE or ECDHE cipher suites. > This is an example of a MUST that is not always easy to enforce. Consider what happens if you have a client which offers both ECDHE and PSK (for resumption) and omits supported_groups. If the server picks PSK it's a pain to check for supported groups and I'm not sure that the world is improved by that code. > I propose that we don't do this in future without due consideration. > In all these cases, the peer that notices a violation of the > requirement can (and I would argue MUST) fail the handshake and > probably generate a fatal alert. > I agree consideration of this question is good. The exceptions to this are where you need to permit non-compliant > behaviour for legacy interoperability reasons. For TLS 1.3, I think > that we can limit that to the ClientHello handling and - if we feel > like we can mandate changes that affect TLS 1.2 or earlier for clients > that support 1.3 - the ServerHello. I think only the ClientHello. As noted above, I don't think that this is the only exception. -Ekr --089e0141a09279b897051e4fc2a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 11:48 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
I'v= e been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless.=C2=A0 To pick on a recent changeset:
> The signature algorithm and hash algorithm MUST be a pair offered in t= he
"signature_algorithms" extension (see {{signature-algorithms}}).<= br>

I note that we had a very extensive dis= cussio n

=C2=A0
I propose that we don't do this in future without due consideration. In all these cases, the peer that notices a violation of the
requirement can (and I would argue MUST) fail the handshake and
probably generate a fatal alert.

I agre= e consideration of this question is good.


The exceptions to this are where you need to permit non-compliant
behaviour for legacy interoperability reasons.=C2=A0 For TLS 1.3, I think that we can limit that to the ClientHello handling and - if we feel
like we can mandate changes that affect TLS 1.2 or earlier for clients
that support 1.3 - the ServerHello.=C2=A0 I think only the ClientHello.

As noted above, I don't think that this is= the only exception.

-Ekr
--089e0141a09279b897051e4fc2a6-- From nobody Thu Aug 27 12:19:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C771B2DC0 for ; Thu, 27 Aug 2015 12:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLM7qHo5Di6Q for ; Thu, 27 Aug 2015 12:19:53 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F101B2CCC for ; Thu, 27 Aug 2015 12:19:53 -0700 (PDT) Received: by qgdu11 with SMTP id u11so2165181qgd.1 for ; Thu, 27 Aug 2015 12:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=t7stsPbpCsaPA2OgJJLVgHsTTk2LcNwEteYauapB+5Q=; b=b/c68eX0c7/AmxrdZ9VB9RvviSHCjN34c+q4OEEYemmbGlOjsI2v7KOYvtAvp6yAX9 0+ZU4lTxL64ntJRujhGe8xr3ctVfYIjEK33IGbyEtqyX8eA9tW0AskMK6aincWgvFgvj NI7e615AkdtOcAFi/A+aX4XwGzciRlSpwH+z3FGM8WReVfhwCB4YTRo1EwosrJTQqMBU eL2BlO2LU8bsRNS9CZGX1dp0Y2z1z5ZWv/2+lmh7TDW3/uxApHPJa5cpT/ucBrrSU8Xw 172zbTaj2HFSIkw10mdWpKCma6zMv+LDiKITZhooVZvpvdUWNGgT/Bs9AifNtfGuU2ig O+Gg== X-Received: by 10.140.195.141 with SMTP id q135mr9982564qha.75.1440703191926; Thu, 27 Aug 2015 12:19:51 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id b82sm1786628qhc.46.2015.08.27.12.19.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Aug 2015 12:19:51 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Martin Thomson Date: Thu, 27 Aug 2015 15:19:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508271519.49848.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:19:55 -0000 On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote: > I've been looking at the latest TLS 1.3 spec and there are a lot of > MUSTs that are completely toothless. To pick on a recent changeset: > > > The signature algorithm and hash algorithm MUST be a pair offered in the > "signature_algorithms" extension (see {{signature-algorithms}}). Some changes to this are now in this PR: https://github.com/tlswg/tls13-spec/pull/231/files (language based on list discussion) > > All implementations MUST use the "signature_algorithms" extension when > offering and negotiating certificate authenticated cipher suites. Actually, I did get a strict requirement in there for that one: https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms > All clients MUST send a valid "signature_algorithms" extension in their ClientHello when offering certificate authenticated cipher suites. Servers receiving a TLS 1.3 ClientHello offering certificate authenticated cipher suites without this extension MUST send a "missing_extension" alert message and close the connection. I think it warrants repeating in the MTI section as well. > > All implementations MUST use the "supported_groups" extension when > offering and negotiating DHE or ECDHE cipher suites. My initial draft had similar language, however ekr says the WG doesn't have consensus to be more strict. I would like to consider all of these extensions as mandatory to send, and malformed if not present when offering/negotiating any applicable cipher suites: signature_algorithms, supported_groups, client_key_share, pre_shared_key, server_name (though, I'm fine with a SHOULD error on lack of SNI when applicable) Dave From nobody Thu Aug 27 12:26:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A8C1B3D12 for ; Thu, 27 Aug 2015 12:26:46 -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 XJLrUVkd--iK for ; Thu, 27 Aug 2015 12:26:45 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAF01B3D11 for ; Thu, 27 Aug 2015 12:26:44 -0700 (PDT) Received: by wicge2 with SMTP id ge2so2632755wic.0 for ; Thu, 27 Aug 2015 12:26: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=t4yDEN3SE3XBoy3HDzkS9BDI7b2FhOCtXZaA2cIAtrE=; b=jgnBXPlWuvd9Zvz4Tv55XAxE98+YaXu/LSBTw/fqsWLecrmjOlXFWRJudJ84eTCvpS 3iM2pJZR5oSScraOOYFGR8huMm07kn6RLkGuhJKos7J4zAFiB86c5aqiGB5Xxk6NKjoQ OKLq3ru1rGm0BRePHFLLlIArOtg2VXvaFDXFFIX0eNrPRei7KaCv+AyOLvZ0JjEe9WAg CF56B7Mey5tXPSrUBAHsfPFGPB+wGSFpvH9Y6XMC07ws9deWXibF907z7SoAc7aXLYeW cTWGViTLTl/q0byn6gIxxNYDUrXF4Xk+XHJzB524sjRpuMau3vvUYrw45/lN8gUP5NY6 F72g== X-Gm-Message-State: ALoCoQmnrDsezJdqwCD6DJC4VkCYZ3aUpfx0ktHWiqf5bFIywH43OxutoFFEH9MCN77xGPzLSX54 X-Received: by 10.180.73.244 with SMTP id o20mr225406wiv.31.1440703603422; Thu, 27 Aug 2015 12:26:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 12:26:03 -0700 (PDT) In-Reply-To: <201508271519.49848.davemgarrett@gmail.com> References: <201508271519.49848.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 27 Aug 2015 12:26:03 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d0435c06a824e12051e4ff2fe Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:26:47 -0000 --f46d0435c06a824e12051e4ff2fe Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett wrote: > On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote: > > I've been looking at the latest TLS 1.3 spec and there are a lot of > > MUSTs that are completely toothless. To pick on a recent changeset: > > > > > The signature algorithm and hash algorithm MUST be a pair offered in > the > > "signature_algorithms" extension (see {{signature-algorithms}}). > > Some changes to this are now in this PR: > https://github.com/tlswg/tls13-spec/pull/231/files > (language based on list discussion) > > > > All implementations MUST use the "signature_algorithms" extension when > > offering and negotiating certificate authenticated cipher suites. > > Actually, I did get a strict requirement in there for that one: > > > https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms > > All clients MUST send a valid "signature_algorithms" extension in their > ClientHello when offering certificate authenticated cipher suites. Servers > receiving a TLS 1.3 ClientHello offering certificate authenticated cipher > suites without this extension MUST send a "missing_extension" alert message > and close the connection. > > I think it warrants repeating in the MTI section as well. > > > > All implementations MUST use the "supported_groups" extension when > > offering and negotiating DHE or ECDHE cipher suites. > > My initial draft had similar language, however ekr says the WG doesn't > have consensus to be more strict. I would like to consider all of these > extensions as mandatory to send, and malformed if not present when > offering/negotiating any applicable cipher suites: > signature_algorithms, supported_groups, client_key_share, pre_shared_key, > server_name (though, I'm fine with a SHOULD error on lack of SNI when > applicable My problem is precisely the conflation of offering with negotiating. The way that many stacks work (for instance NSS) is that they negotiate the cipher suite *first* and then they check for the presence or absence of the relevant extensions. It's not clear to me that it's an improvement to require them to check for error conditions that are not otherwise relevant. -Ekr --f46d0435c06a824e12051e4ff2fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot o= f
> MUSTs that are completely toothless.=C2=A0 To pick on a recent changes= et:
>
> > The signature algorithm and hash algorithm MUST be a pair offered= in the
> "signature_algorithms" extension (see {{signature-algorithms= }}).

Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files=
(language based on list discussion)

> > All implementations MUST use the "signature_algorithms"= extension when
> offering and negotiating certificate authenticated cipher suites.

Actually, I did get a strict requirement in there for that one:

https://= github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-a= lgorithms
> All clients MUST send a valid "signature_algorithms" extensi= on in their ClientHello when offering certificate authenticated cipher suit= es. Servers receiving a TLS 1.3 ClientHello offering certificate authentica= ted cipher suites without this extension MUST send a "missing_extensio= n" alert message and close the connection.

I think it warrants repeating in the MTI section as well.

> > All implementations MUST use the "supported_groups" ext= ension when
> offering and negotiating DHE or ECDHE cipher suites.

My initial draft had similar language, however ekr says the WG doesn= 't have consensus to be more strict. I would like to consider all of th= ese extensions as mandatory to send, and malformed if not present when offe= ring/negotiating any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key, s= erver_name (though, I'm fine with a SHOULD error on lack of SNI when ap= plicable

My problem is precisely the confla= tion of offering with negotiating. The way that
many stacks work = (for instance NSS) is that they negotiate the cipher suite
*first= * and then they check for the presence or absence of the relevant extension= s.
It's not clear to me that it's an improvement to requi= re them to check for error
conditions that are not otherwise rele= vant.

-Ekr

--f46d0435c06a824e12051e4ff2fe-- From nobody Thu Aug 27 12:51:51 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5271B3BF1 for ; Thu, 27 Aug 2015 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWQAd5hI4s-v for ; Thu, 27 Aug 2015 12:51:48 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5E91B3BD4 for ; Thu, 27 Aug 2015 12:51:48 -0700 (PDT) Received: by qkda128 with SMTP id a128so16839936qkd.3 for ; Thu, 27 Aug 2015 12:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=6rzzzs9wvDzwW9VmxtON+/79EKXokVq/0YjRCxlewa4=; b=Q9Io7uxW6rKreAU/vSnDN/74kVtdJM/ppANEU0wry/0WBIcoZlU+twdG4JxmaUjJcP QTwer3eM6Kir/kqEBiV7p/6NUnPEojORuaip574I29Illrjgg7jX+aHqcGy88oM/ZKZx ef3d785dZMfeGJEwUDaOYE+MAZfPZR7wpTbKqK+TeYS9uccgWVQws7A9jpgrQ5mAoZsl r52wnugCkczwiQv4miyN5fI2xzQ3NCy6eRmbrrskadRNta636DnuyGmQodqamBu6hN7Q sCpvjt71ZJgFKa6g81J5qJ4zZeMwoiVn+acBx3eD61lrZ9X5UPJpKzQ1LxZ2oLivl4yP gJsQ== X-Received: by 10.55.214.217 with SMTP id p86mr9770574qkl.75.1440705107874; Thu, 27 Aug 2015 12:51:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 44sm1851897qgg.37.2015.08.27.12.51.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Aug 2015 12:51:47 -0700 (PDT) From: Dave Garrett To: Eric Rescorla , Martin Thomson Date: Thu, 27 Aug 2015 15:51:42 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201508271519.49848.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201508271551.42561.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:51:50 -0000 On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > My problem is precisely the conflation of offering with negotiating. The way that > many stacks work (for instance NSS) is that they negotiate the cipher suite > *first* and then they check for the presence or absence of the relevant extensions. > It's not clear to me that it's an improvement to require them to check for error > conditions that are not otherwise relevant. I'm not fundamentally opposed to having a hard requirement of an error check on negotiation, and basically a soft expectation on mere offering (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That said, categorizing the cipher suites and just doing a quick check for which categories are there and what extensions came with it is not a very complicated requirement. I'm philosophically in the "do it right or explode so it can be found and fixed immediately" camp when it comes to very clear requirements like this, but I'm aware that this is sadly not always the dominant thought process. :| Dave From nobody Thu Aug 27 13:01:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4D51B3261 for ; Thu, 27 Aug 2015 13:01:58 -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 HS9SGt7rStkG for ; Thu, 27 Aug 2015 13:01:55 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B781B3102 for ; Thu, 27 Aug 2015 13:01:55 -0700 (PDT) Received: by ykll84 with SMTP id l84so32338231ykl.0 for ; Thu, 27 Aug 2015 13:01:54 -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=KX4jRH1NgTk0inzqBD+i7r+YGZP/lff+6DvbDQF3NHA=; b=fNCSTNUN9BmFRMUzlEJTsXfK8YjGjgYK7suHOrMdWLT+eGQr4KmtocMtmISEzV4n5+ drDJ3OGD0E5KvlC+JdKSpcNhRRpIKbXEDL9z0kNbpXsW0XegTz1I4CdbSOFy8o8DvW8L 8iQSYaFceqGIqFlkZ/GtbtqSV+cx3aLU5Or8iXGhYN0FlFarIm7CwJNpXNmImdI4FLIh opfCy2GVwJ5xQTcFjPpRIUtL8BMUOuBE7wl9lJ/AL8mFh7zh9G/DleLe44IuzjfX6tcG J1y5W+YxeWj+dXkKbtUCfISF/H5gP+uw14XTDd+HMiykZ55gHzZxiNV0ZBOcfGHI+YiS /oEQ== MIME-Version: 1.0 X-Received: by 10.13.206.67 with SMTP id q64mr5318797ywd.154.1440705714452; Thu, 27 Aug 2015 13:01:54 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 13:01:54 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 13:01:54 -0700 (PDT) In-Reply-To: References: <201508271519.49848.davemgarrett@gmail.com> Date: Thu, 27 Aug 2015 13:01:54 -0700 Message-ID: From: Martin Thomson To: EKR Content-Type: multipart/alternative; boundary=001a114dafac56186c051e5070dc Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:01:58 -0000 --001a114dafac56186c051e5070dc Content-Type: text/plain; charset=UTF-8 The opposite in fact. NSS checks extensions first. That is how we filter out ECC cipher suites if the named_groups extension doesn't list anything we support. On Aug 27, 2015 12:26 PM, "Eric Rescorla" wrote: > > > On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett > wrote: > >> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote: >> > I've been looking at the latest TLS 1.3 spec and there are a lot of >> > MUSTs that are completely toothless. To pick on a recent changeset: >> > >> > > The signature algorithm and hash algorithm MUST be a pair offered in >> the >> > "signature_algorithms" extension (see {{signature-algorithms}}). >> >> Some changes to this are now in this PR: >> https://github.com/tlswg/tls13-spec/pull/231/files >> (language based on list discussion) >> >> > > All implementations MUST use the "signature_algorithms" extension when >> > offering and negotiating certificate authenticated cipher suites. >> >> Actually, I did get a strict requirement in there for that one: >> >> >> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms >> > All clients MUST send a valid "signature_algorithms" extension in their >> ClientHello when offering certificate authenticated cipher suites. Servers >> receiving a TLS 1.3 ClientHello offering certificate authenticated cipher >> suites without this extension MUST send a "missing_extension" alert message >> and close the connection. >> >> I think it warrants repeating in the MTI section as well. >> >> > > All implementations MUST use the "supported_groups" extension when >> > offering and negotiating DHE or ECDHE cipher suites. >> >> My initial draft had similar language, however ekr says the WG doesn't >> have consensus to be more strict. I would like to consider all of these >> extensions as mandatory to send, and malformed if not present when >> offering/negotiating any applicable cipher suites: >> signature_algorithms, supported_groups, client_key_share, pre_shared_key, >> server_name (though, I'm fine with a SHOULD error on lack of SNI when >> applicable > > > My problem is precisely the conflation of offering with negotiating. The > way that > many stacks work (for instance NSS) is that they negotiate the cipher suite > *first* and then they check for the presence or absence of the relevant > extensions. > It's not clear to me that it's an improvement to require them to check for > error > conditions that are not otherwise relevant. > > -Ekr > > --001a114dafac56186c051e5070dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The opposite in fact. NSS checks extensions first. That is h= ow we filter out ECC cipher suites if the named_groups extension doesn'= t list anything we support.

On Aug 27, 2015 12:26 PM, "Eric Rescorla&qu= ot; <ekr@rtfm.com> wrote:


On Thu, Aug 27, 2015 at= 12:19 PM, Dave Garrett <davemgarrett@gmail.com> wrote:=
On Thursday, August 27, 2015 02:48= :15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot o= f
> MUSTs that are completely toothless.=C2=A0 To pick on a recent changes= et:
>
> > The signature algorithm and hash algorithm MUST be a pair offered= in the
> "signature_algorithms" extension (see {{signature-algorithms= }}).

Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files=
(language based on list discussion)

> > All implementations MUST use the "signature_algorithms"= extension when
> offering and negotiating certificate authenticated cipher suites.

Actually, I did get a strict requirement in there for that one:

https://= github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-a= lgorithms
> All clients MUST send a valid "signature_algorithms" extensi= on in their ClientHello when offering certificate authenticated cipher suit= es. Servers receiving a TLS 1.3 ClientHello offering certificate authentica= ted cipher suites without this extension MUST send a "missing_extensio= n" alert message and close the connection.

I think it warrants repeating in the MTI section as well.

> > All implementations MUST use the "supported_groups" ext= ension when
> offering and negotiating DHE or ECDHE cipher suites.

My initial draft had similar language, however ekr says the WG doesn= 't have consensus to be more strict. I would like to consider all of th= ese extensions as mandatory to send, and malformed if not present when offe= ring/negotiating any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key, s= erver_name (though, I'm fine with a SHOULD error on lack of SNI when ap= plicable

My problem is precisely the confla= tion of offering with negotiating. The way that
many stacks work = (for instance NSS) is that they negotiate the cipher suite
*first= * and then they check for the presence or absence of the relevant extension= s.
It's not clear to me that it's an improvement to requi= re them to check for error
conditions that are not otherwise rele= vant.

-Ekr

--001a114dafac56186c051e5070dc-- From nobody Thu Aug 27 13:02:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F11A802E for ; Thu, 27 Aug 2015 13:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bigAx9O9g1p for ; Thu, 27 Aug 2015 13:02:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860201A6EE8 for ; Thu, 27 Aug 2015 13:02:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8B589284D23; Thu, 27 Aug 2015 20:02:08 +0000 (UTC) Date: Thu, 27 Aug 2015 20:02:08 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150827200208.GV9021@mournblade.imrryr.org> References: <201508271519.49848.davemgarrett@gmail.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: Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:02:20 -0000 On Thu, Aug 27, 2015 at 12:26:03PM -0700, Eric Rescorla wrote: > My problem is precisely the conflation of offering with negotiating. The > way that many stacks work (for instance NSS) is that they negotiate the > cipher suite *first* and then they check for the presence or absence of > the relevant extensions. > > It's not clear to me that it's an improvement to require them to check > for error conditions that are not otherwise relevant. One issue related to "layered" negotiation, in which one first chooses X, then with X already chosen, chooses Y, ... is that some choices of X are not compatible with any available Y, while other choices of X might work. A specific example may help: Many libraries will first choose the highest mutually supported protocol version, and only then select a mutually supported cipher suite. However, not all ciphersuites are compatible with all protocols versions. So we can have situations in which TLS 1.2 and TLS 1.3 are offered by the client and TLS 1.3 is selected by the server, but none of the ciphers offered by the client are AEAD. Should the server have chosen TLS 1.2, or MUST the client figure out that it can't do TLS 1.3 and not offer it. There will undoubtedly be clients that naively give the server "impossible" options along with other options that work. Should servers try to handle this gracefully? Note that in the above scenario the client might offer *some* TLS 1.3 compatible ciphers, but it may happen that none are shared by the server, while they both share common TLS 1.2 ciphers. One way to avoid such problems is to suggest that clients that don't offer the MTI ciphers for a particular protocol version (and thus can't generically expect interoperability with servers that implement that protocol) SHOULD NOT offer the protocol version. Libraries might then have an option that is on by default, and suppresses protocols for which the MTI ciphers are not enabled. Clients that really want to offer only non-MTI ciphers would have to clear the option explicitly. Half-baked ideas aside, some discussion of the problem may be relevant so that servers or clients avoid negotiating impossible partial choices. -- Viktor. From nobody Thu Aug 27 13:06:14 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A421D1B37E5 for ; Thu, 27 Aug 2015 13:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZPCJrbSKkDw for ; Thu, 27 Aug 2015 13:06:11 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3086F1B3862 for ; Thu, 27 Aug 2015 13:06:11 -0700 (PDT) Received: by ykfw73 with SMTP id w73so32480155ykf.3 for ; Thu, 27 Aug 2015 13:06: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=kRwM6zFFQykwySF20/K4P91rSVOQI2mC9dPvDtyJLqo=; b=mtM1/V0gKpus8M+Uek2cu2hKXPq7XCijgI9U98lzMRbCpoPbLCi55zr+Ihzxi/HsGs SkUTRC8b7StNCF3iLEjDitDAhtpSjY1bNhtqCs1QY8EcASRQBwZRQ5yP67qqc+p9zH93 Gf6WLpAMudOaiphXKeCOs4voviCNDnH3xfhbiqAPDQkmfGeRNr6RGuEj8PpA9oLgRh95 4TsB1MzJAHvGA5B7LURd/TeLyuZNIFD3D/L7LEukiPs7QDnFdhHW5Fa/ibn7EZ6So1Lw qaQSuXs4GbWFuug8YMjW8c01n5/CbJeFn+bDgCsHr6syUFlNG/rFRLd2IMo/T/JSiU76 h0QQ== MIME-Version: 1.0 X-Received: by 10.13.234.138 with SMTP id t132mr5302000ywe.89.1440705970569; Thu, 27 Aug 2015 13:06:10 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 13:06:10 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Thu, 27 Aug 2015 13:06:10 -0700 (PDT) In-Reply-To: <201508271551.42561.davemgarrett@gmail.com> References: <201508271519.49848.davemgarrett@gmail.com> <201508271551.42561.davemgarrett@gmail.com> Date: Thu, 27 Aug 2015 13:06:10 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c0541b69a0d26051e507fbf Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:06:12 -0000 --94eb2c0541b69a0d26051e507fbf Content-Type: text/plain; charset=UTF-8 The statement I'd like to see is something like this... An endpoint that receives an illegal combination of "things" MAY choose to treat that as a fatal error. In this case, that means that if you include an ECDHE suite without an ECDHE named_group, don't expect to have the connection succeed. On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote: > On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: > > My problem is precisely the conflation of offering with negotiating. The > way that > > many stacks work (for instance NSS) is that they negotiate the cipher > suite > > *first* and then they check for the presence or absence of the relevant > extensions. > > It's not clear to me that it's an improvement to require them to check > for error > > conditions that are not otherwise relevant. > > I'm not fundamentally opposed to having a hard requirement of an error > check on negotiation, and basically a soft expectation on mere offering > (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That > said, categorizing the cipher suites and just doing a quick check for which > categories are there and what extensions came with it is not a very > complicated requirement. I'm philosophically in the "do it right or explode > so it can be found and fixed immediately" camp when it comes to very clear > requirements like this, but I'm aware that this is sadly not always the > dominant thought process. :| > > > Dave > --94eb2c0541b69a0d26051e507fbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The statement I'd like to see is something like this...<= /p>

An endpoint that receives an illegal combination of "th= ings" MAY choose to treat that as a fatal error.

In this case, that means that if you include an ECDHE suite = without an ECDHE named_group, don't expect to have the connection succe= ed.

On Aug 27, 2015 12:51 PM, "Dave Garrett&quo= t; <davemgarrett@gmail.com= > wrote:
On Thurs= day, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. T= he way that
> many stacks work (for instance NSS) is that they negotiate the cipher = suite
> *first* and then they check for the presence or absence of the relevan= t extensions.
> It's not clear to me that it's an improvement to require them = to check for error
> conditions that are not otherwise relevant.

I'm not fundamentally opposed to having a hard requirement of an error = check on negotiation, and basically a soft expectation on mere offering (SH= OULD, MAY, or not mentioned; stern warning and shake of finger). That said,= categorizing the cipher suites and just doing a quick check for which cate= gories are there and what extensions came with it is not a very complicated= requirement. I'm philosophically in the "do it right or explode s= o it can be found and fixed immediately" camp when it comes to very cl= ear requirements like this, but I'm aware that this is sadly not always= the dominant thought process. :|


Dave
--94eb2c0541b69a0d26051e507fbf-- From nobody Thu Aug 27 13:06:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6F71B3954 for ; Thu, 27 Aug 2015 13:06:54 -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 qJIZcyVGS70L for ; Thu, 27 Aug 2015 13:06:53 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4981B382B for ; Thu, 27 Aug 2015 13:06:52 -0700 (PDT) Received: by wicgk12 with SMTP id gk12so2543185wic.1 for ; Thu, 27 Aug 2015 13:06:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BP/4nNm6HWDD3u2FausXwgtvzcoz7YzdgEyGTc5pf5o=; b=Dlnd+tGU1zl+w1vOs9zD0ZtSZEvLhfE08PNHg7l0zzwr5s6I0Ke0cMNadNA+p79qd/ 6dQ6603lQMbXBUuZ8WIgMibyfxp4hWj1NIuwtOJTP1zeSZg/fqkmM2FJxYpoSVW7NhrT hbOXqkM2VBuY3Vy0rrg2uCtaIGc1WvdFKzQ4eQ/aD+bsY/TSVwPwNi/5Y9GwzxXFXDUK WtC0KhZhZlz3HG9CxZjBx835sQ/lbszRNfkySv00stGBvErUxFS9kpMlRVJayBz6Zn46 dyMomF/Y6gGkNfJgUG2rq/oBxux28/ur5I1Ep0YEO6X69EpEGGn5G1OxBG1wWScJ3BBi yPPw== X-Gm-Message-State: ALoCoQnMerpeVos4q15Ji5MyQ9GRLK5JYIXgZYQ5FwuE3otiqV2S238+L722zd2Ykqa8Ev2/X9n3 X-Received: by 10.180.75.78 with SMTP id a14mr402047wiw.68.1440706011267; Thu, 27 Aug 2015 13:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 13:06:11 -0700 (PDT) In-Reply-To: References: <201508271519.49848.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 27 Aug 2015 13:06:11 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d0438eb9d071b62051e50829d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:06:55 -0000 --f46d0438eb9d071b62051e50829d Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson wrote: > The opposite in fact. NSS checks extensions first. That is how we filter > out ECC cipher suites if the named_groups extension doesn't list anything > we support. > Well, yes and no. We don't for instance check for the *absence* of the extension. -Ekr > On Aug 27, 2015 12:26 PM, "Eric Rescorla" wrote: > >> >> >> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett >> wrote: >> >>> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote: >>> > I've been looking at the latest TLS 1.3 spec and there are a lot of >>> > MUSTs that are completely toothless. To pick on a recent changeset: >>> > >>> > > The signature algorithm and hash algorithm MUST be a pair offered in >>> the >>> > "signature_algorithms" extension (see {{signature-algorithms}}). >>> >>> Some changes to this are now in this PR: >>> https://github.com/tlswg/tls13-spec/pull/231/files >>> (language based on list discussion) >>> >>> > > All implementations MUST use the "signature_algorithms" extension >>> when >>> > offering and negotiating certificate authenticated cipher suites. >>> >>> Actually, I did get a strict requirement in there for that one: >>> >>> >>> https://github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-algorithms >>> > All clients MUST send a valid "signature_algorithms" extension in >>> their ClientHello when offering certificate authenticated cipher suites. >>> Servers receiving a TLS 1.3 ClientHello offering certificate authenticated >>> cipher suites without this extension MUST send a "missing_extension" alert >>> message and close the connection. >>> >>> I think it warrants repeating in the MTI section as well. >>> >>> > > All implementations MUST use the "supported_groups" extension when >>> > offering and negotiating DHE or ECDHE cipher suites. >>> >>> My initial draft had similar language, however ekr says the WG doesn't >>> have consensus to be more strict. I would like to consider all of these >>> extensions as mandatory to send, and malformed if not present when >>> offering/negotiating any applicable cipher suites: >>> signature_algorithms, supported_groups, client_key_share, >>> pre_shared_key, server_name (though, I'm fine with a SHOULD error on lack >>> of SNI when applicable >> >> >> My problem is precisely the conflation of offering with negotiating. The >> way that >> many stacks work (for instance NSS) is that they negotiate the cipher >> suite >> *first* and then they check for the presence or absence of the relevant >> extensions. >> It's not clear to me that it's an improvement to require them to check >> for error >> conditions that are not otherwise relevant. >> >> -Ekr >> >> --f46d0438eb9d071b62051e50829d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 1:01 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

The opposite in fact. NSS checks extensions first. That is how we = filter out ECC cipher suites if the named_groups extension doesn't list= anything we support.


Well, yes and no.= We don't for instance check for the *absence* of the extension.
<= div>
-Ekr
=C2=A0
On Aug 27, 2015 12:26 PM, "Eric Rescorla&qu= ot; <ekr@rtfm.com&= gt; wrote:


On T= hu, Aug 27, 2015 at 12:19 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
On Thursday, Au= gust 27, 2015 02:48:15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot o= f
> MUSTs that are completely toothless.=C2=A0 To pick on a recent changes= et:
>
> > The signature algorithm and hash algorithm MUST be a pair offered= in the
> "signature_algorithms" extension (see {{signature-algorithms= }}).

Some changes to this are now in this PR:
https://github.com/tlswg/tls13-spec/pull/231/files=
(language based on list discussion)

> > All implementations MUST use the "signature_algorithms"= extension when
> offering and negotiating certificate authenticated cipher suites.

Actually, I did get a strict requirement in there for that one:

https://= github.com/tlswg/tls13-spec/blob/master/draft-ietf-tls-tls13.md#signature-a= lgorithms
> All clients MUST send a valid "signature_algorithms" extensi= on in their ClientHello when offering certificate authenticated cipher suit= es. Servers receiving a TLS 1.3 ClientHello offering certificate authentica= ted cipher suites without this extension MUST send a "missing_extensio= n" alert message and close the connection.

I think it warrants repeating in the MTI section as well.

> > All implementations MUST use the "supported_groups" ext= ension when
> offering and negotiating DHE or ECDHE cipher suites.

My initial draft had similar language, however ekr says the WG doesn= 't have consensus to be more strict. I would like to consider all of th= ese extensions as mandatory to send, and malformed if not present when offe= ring/negotiating any applicable cipher suites:
signature_algorithms, supported_groups, client_key_share, pre_shared_key, s= erver_name (though, I'm fine with a SHOULD error on lack of SNI when ap= plicable

My problem is precisely the confla= tion of offering with negotiating. The way that
many stacks work = (for instance NSS) is that they negotiate the cipher suite
*first= * and then they check for the presence or absence of the relevant extension= s.
It's not clear to me that it's an improvement to requi= re them to check for error
conditions that are not otherwise rele= vant.

-Ekr


--f46d0438eb9d071b62051e50829d-- From nobody Thu Aug 27 13:07:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D98C1A87C9 for ; Thu, 27 Aug 2015 13:07: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 uzLZfuSFJutK for ; Thu, 27 Aug 2015 13:07:24 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0253A1A8711 for ; Thu, 27 Aug 2015 13:07:24 -0700 (PDT) Received: by widdq5 with SMTP id dq5so2633970wid.0 for ; Thu, 27 Aug 2015 13: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=Jm22WbWvt1izbSVu10uRzoq/CM4ztqtFqR8Xi5b4uOs=; b=HuHPEFcgwoVacVMthFs1uw61N3e/YY8wqCtqPUb/gvcLn5OYcoerQORU6fAyI9iAE5 B7bqlFVl/5ExSFAcqJ3UwOPyLJgN1CzwJiuwANEgovqVnshycxnsBu7TIeaWcV5JVV6v 3AN/quX7b/ND6RZeHwxApOzD2vHHUWGHdEKzgDTeluK0iTFdLUTA0FYNE2uKIk1q49VZ NvmsgPI4ekarVi9COHkd0hpi3OX0UIyYojOR4BeUaWIjXZVTF4psEIpgYXC3+H4tx8R/ G1YpHEckMawM6mnYm3QbabynARqfWAMkd4w1ftH5aTJcnor3stcNgxvR91LiUYPGq46K cXUA== X-Gm-Message-State: ALoCoQma9B/m16xpb5phjypz+NUKb10+080mePqoj3cS6C+EPjap4weMbnbTx4WRP7lGhio4BJjM X-Received: by 10.180.74.148 with SMTP id t20mr359362wiv.31.1440706042694; Thu, 27 Aug 2015 13:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Thu, 27 Aug 2015 13:06:43 -0700 (PDT) In-Reply-To: References: <201508271519.49848.davemgarrett@gmail.com> <201508271551.42561.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 27 Aug 2015 13:06:43 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c7f5ce6ba02051e508318 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:07:26 -0000 --f46d043c7f5ce6ba02051e508318 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 1:06 PM, Martin Thomson wrote: > The statement I'd like to see is something like this... > > An endpoint that receives an illegal combination of "things" MAY choose to > treat that as a fatal error. > This seems totally reasonable. -Ekr > In this case, that means that if you include an ECDHE suite without an > ECDHE named_group, don't expect to have the connection succeed. > On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote: > >> On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote: >> > My problem is precisely the conflation of offering with negotiating. >> The way that >> > many stacks work (for instance NSS) is that they negotiate the cipher >> suite >> > *first* and then they check for the presence or absence of the relevant >> extensions. >> > It's not clear to me that it's an improvement to require them to check >> for error >> > conditions that are not otherwise relevant. >> >> I'm not fundamentally opposed to having a hard requirement of an error >> check on negotiation, and basically a soft expectation on mere offering >> (SHOULD, MAY, or not mentioned; stern warning and shake of finger). That >> said, categorizing the cipher suites and just doing a quick check for which >> categories are there and what extensions came with it is not a very >> complicated requirement. I'm philosophically in the "do it right or explode >> so it can be found and fixed immediately" camp when it comes to very clear >> requirements like this, but I'm aware that this is sadly not always the >> dominant thought process. :| >> >> >> Dave >> > --f46d043c7f5ce6ba02051e508318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 1:06 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

The statement I'd like to see is something like this...

An endpoint that receives an illegal combination of "th= ings" MAY choose to treat that as a fatal error.

= This seems totally reasonable.

-Ekr
=C2= =A0

In this case, that m= eans that if you include an ECDHE suite without an ECDHE named_group, don&#= 39;t expect to have the connection succeed.

On Aug 27, 2015 12:51 PM, "Dave Garrett&quo= t; <davemgar= rett@gmail.com> wrote:
On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. T= he way that
> many stacks work (for instance NSS) is that they negotiate the cipher = suite
> *first* and then they check for the presence or absence of the relevan= t extensions.
> It's not clear to me that it's an improvement to require them = to check for error
> conditions that are not otherwise relevant.

I'm not fundamentally opposed to having a hard requirement of an error = check on negotiation, and basically a soft expectation on mere offering (SH= OULD, MAY, or not mentioned; stern warning and shake of finger). That said,= categorizing the cipher suites and just doing a quick check for which cate= gories are there and what extensions came with it is not a very complicated= requirement. I'm philosophically in the "do it right or explode s= o it can be found and fixed immediately" camp when it comes to very cl= ear requirements like this, but I'm aware that this is sadly not always= the dominant thought process. :|


Dave

--f46d043c7f5ce6ba02051e508318-- From nobody Thu Aug 27 13:11:05 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4FB1B3737 for ; Thu, 27 Aug 2015 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h2OH7g3P1i9 for ; Thu, 27 Aug 2015 13:11: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 536FD1B3434 for ; Thu, 27 Aug 2015 13:11:01 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 71C76740011; Thu, 27 Aug 2015 20:11:00 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 5A703740009; Thu, 27 Aug 2015 20:11:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440706260; bh=bLTOZyllMOYAeopSr8PKAZbERjfjxujIg0DqKYRVNuE=; l=244; h=From:To:CC:Date:References:In-Reply-To:From; b=inHqfMkXWzyQxXdLPFo0fAzECbkzJM5CA5UwefeYHyp3e9MPQQ9OoZbOILgE6sng9 5rxnH0Yze9w12RjX4aQb1FHW5/+zANT+l3+wh9dsEM8XxB1pnKAspuqpnvwVmg3cON 6hvoT7tNnPPpXzHT1f5iPED+RyTH21X79Hy+bzN4= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 5772F1E080; Thu, 27 Aug 2015 20:11:00 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 27 Aug 2015 15:10:59 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Thu, 27 Aug 2015 15:10:59 -0500 From: "Salz, Rich" To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] MUST or what? Thread-Index: AQHQ4PjyXcrd7AgoREqeZ/yOmJ66o54gjI6AgAABvoCAAAcqAP//sJrNgAAA2NA= Date: Thu, 27 Aug 2015 20:10:58 +0000 Message-ID: <467ac457098b4a409df87f09b526e9e0@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <201508271519.49848.davemgarrett@gmail.com> <201508271551.42561.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:11:03 -0000 PiBBbiBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIGFuIGlsbGVnYWwgY29tYmluYXRpb24gb2YgInRo aW5ncyIgTUFZIGNob29zZSB0byB0cmVhdCB0aGF0IGFzIGEgZmF0YWwgZXJyb3IuDQoNCkZyb20g dGhlIGd1eSB3aG8gd3JvdGUgdGhhdCBQb3N0ZWwgd2FzIHdyb25nLg0KDQpCdXQgKzEgZnJvbSBt ZS4NCg0K From nobody Thu Aug 27 14:36:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98071B2A6A for ; Thu, 27 Aug 2015 14:36: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 nGGyQ2TiHVTb for ; Thu, 27 Aug 2015 14:36:36 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895F21B2AE9 for ; Thu, 27 Aug 2015 14:36:36 -0700 (PDT) Received: by qgeb6 with SMTP id b6so19244727qge.3 for ; Thu, 27 Aug 2015 14:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Pm8HxAaCRp6h3vRt9WXS1AmOfbFFy4LWbb0BUDmFBHs=; b=iEKgU4Btce16j0HsC1+sm9MjHirp3CzsoVvYv8L4UOdY6axYN7P8DZE9R6Yas3zYxB /N44FKXUEp7RpWRotSjBv1dXjRR5vh2yA1DOVNge/b6iqqQMagwC0q6f8Vvdp/5fXres vkMQ502YENtS4W1o4PVprFKCNy/HmwlXIQV5fQhh+Y54a4P82eViDIlAyc+0YSIurVdJ Wx0Nbct7Md6Owx8lwIJ82+vqs9r8O4b4SAQ4t2IuTQHl+ooZmEE/xv4rtGTNzsHyNBIE 73F8jiicrHTwKrOVMj7lENVussMMAwrhjw/5UvhDb13fHllkSKUtMhoesi+TLBr4lYeI r01w== X-Received: by 10.140.152.203 with SMTP id 194mr10869331qhy.47.1440711395899; Thu, 27 Aug 2015 14:36:35 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id c60sm2021724qgc.27.2015.08.27.14.36.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Aug 2015 14:36:35 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Thu, 27 Aug 2015 17:36:33 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <467ac457098b4a409df87f09b526e9e0@ustx2ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <467ac457098b4a409df87f09b526e9e0@ustx2ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508271736.33619.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 21:36:38 -0000 PR to put this into writing: https://github.com/tlswg/tls13-spec/pull/232 Dave From nobody Thu Aug 27 21:24:48 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787A1B2CBB for ; Thu, 27 Aug 2015 21:24:46 -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 TidH9uyIesYQ for ; Thu, 27 Aug 2015 21:24:43 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E791B2CA8 for ; Thu, 27 Aug 2015 21:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1440735884; x=1472271884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OSwy2jBIdkf14WM68X+b1jUKTb3XANo8WX/wt9nP960=; b=zevZugXfozLIdZlOxN8/BMOEQeEwG1EAlNLRGqqZ+aHQK1OLcfRGnZe5 lNXbhuTp4U2DWKMHYZAxFMe6sRl9tvHuZW/jp4+FChrsAewWbiIl//OCt fDUNdp44dELj1YBOT0yO5KWrHHSlpnDu6DbHN16URpP5zIOO3TxW0Sq9G TEhQ/R/sTfowL+ThrHPNkG0SLk5ogjGK4KUVxubdr0JTnj8rIM07W6btQ CqemuwpBzYDQL4Nfv2zEd8+Rrfcex8smzNsn8M/0CJYaiEB4gI5aJkpZ7 XEYPs1rrCoXJ/j5wYOCPwXAglxk1lJk17UJc5YzfugGlZt56eerqbou5L g==; X-IronPort-AV: E=Sophos;i="5.17,424,1437393600"; d="scan'208";a="38271944" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Aug 2015 16:24:38 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 28 Aug 2015 16:24:37 +1200 From: Peter Gutmann To: Martin Thomson , Dave Garrett Thread-Topic: [TLS] MUST or what? Thread-Index: AQHQ4Pj2LgOoeHtO7kayfT/An/ayC54fb5KAgAABvoCAAAcqAIAABAsAgAFUHYQ= Date: Fri, 28 Aug 2015 04:24:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE9CFB@uxcn10-5.UoA.auckland.ac.nz> References: <201508271519.49848.davemgarrett@gmail.com> <201508271551.42561.davemgarrett@gmail.com>, In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 04:24:46 -0000 Martin Thomson writes:=0A= =0A= >An endpoint that receives an illegal combination of "things" MAY choose to= =0A= >treat that as a fatal error.=0A= =0A= Does that actually help? What it's saying in full is:=0A= =0A= An endpoint that receives an illegal combination of "things" MAY choose t= o =0A= treat that as a fatal error or MAY choose not to treat it as a fatal erro= r.=0A= =0A= which is a no-op. Admittedly it explicitly allows you to treat it as an er= ror =0A= while previously the response was left open, but it's still not terribly = =0A= useful, anyone writing a client that submits gibberish things can claim it'= s =0A= OK and the server needs to be fixed to accept it.=0A= =0A= Peter.= From nobody Thu Aug 27 21:29:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960A31B31C6 for ; Thu, 27 Aug 2015 21:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18GLasabD6fF for ; Thu, 27 Aug 2015 21:29:14 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B00A1B31BE for ; Thu, 27 Aug 2015 21:29: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=mail; t=1440736154; x=1472272154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lhaK7XFFdW3GhLJ547HQ6+DcMq44RTGlKK5+iFPDfxY=; b=ZdRiwIWiZrFswpS+HaHskOGDRtUw+pU81e+VVipj8a6LJeVoIjoNjcf+ vFwGf/x5zWcsM8El+6d4TNpoevdOCE4eS7YqwYB908sGRk1Fb7Nli2lNJ cXDNpAZR38QNLuQ0LdE1kJNLbqv5LHD687Jd0+VDE2/8AZqeI+H0/Ka1/ /vSVIleB0ugB331wCMywgr0WzUHJgK0zDKU7HkG0LkNnrtvzN7g72AwAA EeoXCRecn8DYNDPb25M44DDXy6TnwC0atNnrXbdtehpUtwrJrPYo28Y9S LpM0Nil3Rff58/pZnxaQHeJ1Tsy3ROygoBfpxcnE6bDgHucBEJ3+zNWf+ A==; X-IronPort-AV: E=Sophos;i="5.17,424,1437393600"; d="scan'208";a="38272835" 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 mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Aug 2015 16:29:13 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.48]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 28 Aug 2015 16:29:12 +1200 From: Peter Gutmann To: Martin Thomson , EKR Thread-Topic: [TLS] MUST or what? Thread-Index: AQHQ4Pj2LgOoeHtO7kayfT/An/ayC54fb5KAgAABvoCAAAoEAIABVqzI Date: Fri, 28 Aug 2015 04:29:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4AE9D0C@uxcn10-5.UoA.auckland.ac.nz> References: <201508271519.49848.davemgarrett@gmail.com> , In-Reply-To: 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: Cc: "tls@ietf.org" Subject: Re: [TLS] MUST or what? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 04:29:15 -0000 Martin Thomson writes:=0A= =0A= >The opposite in fact. NSS checks extensions first. That is how we filter o= ut =0A= >ECC cipher suites if the named_groups extension doesn't list anything we = =0A= >support.=0A= =0A= I have to do the same thing, bouncing back and forth between cipher suites = and=0A= extensions in order to find something that fits. That was the motivation f= or=0A= the creation of the "Standardised ECC Cipher Suites for TLS" draft:=0A= =0A= TLS-ECC [3] provides an extremely flexible, and by extension=0A= extremely complex means of specifying a large number of options=0A= involving the use of ECC algorithms for TLS [2]. As such the "cipher=0A= suites" in TLS-ECC [3] and by extension TLS-ECC-Brainpool [4] aren't=0A= suites in the conventional TLS sense but more an indication of intent=0A= to negotiate a Chinese menu, with details to be decided on later via=0A= various TLS extensions and parameter settings. This makes deciding=0A= on a particular suite nondeterministic, since later parameter choices=0A= and settings can negate the initial "cipher suite" choice, requiring=0A= returning to the suite list to try with another Chinese-menu suite in=0A= the hope that later parameter choices allow it to be used.=0A= =0A= Peter.= From nobody Fri Aug 28 07:28:11 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DB71A1AE1 for ; Fri, 28 Aug 2015 07:28: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 8FIN27Mwcb3e for ; Fri, 28 Aug 2015 07:28:08 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7701A036F for ; Fri, 28 Aug 2015 07:28:08 -0700 (PDT) Received: by igyq3 with SMTP id q3so13764388igy.1 for ; Fri, 28 Aug 2015 07:28: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:from:date:message-id:subject:to :cc:content-type; bh=0Knbc94nRc1qayKvr6MfvpPMCKC9dLWaKYaek2Moufk=; b=GITd9tT6FrtS2d4jxuHvhtMRs2QrUda9cSNTzkJL7w9wS4FcbDqTqTDmB3qgzkqOhf HXY3wQo25qD/MdgJrYziunRwF9pS+obJtM56ZCB02dW64gpHhs6eA8qAT+ltJD3HNABN qZ4y7Gl0BdXlAuI7dOKTDzUmx9Jr2YYQOun4qHZ8eUBAdqeFLNaC88UyrqxLml4jIpVB fpzLAdidPd85qYA63IE4+uATJGZqcJS+Gj3gMu0RupXpjgT0cLQuMfz1Q6DWTrtXufi7 48FgzJItRTWJgIFqVAMLDCiUUosPNdCedQ0OdCBBG6XBupQK3KCPF8kMl7loQcTM/0DQ 7FhQ== X-Received: by 10.50.62.148 with SMTP id y20mr3658175igr.17.1440772087668; Fri, 28 Aug 2015 07:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.68 with HTTP; Fri, 28 Aug 2015 07:27:28 -0700 (PDT) In-Reply-To: References: From: "Viktor S. Wold Eide" Date: Fri, 28 Aug 2015 16:27:28 +0200 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7bdcab347ce824051e5fe4cc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 14:28:10 -0000 --047d7bdcab347ce824051e5fe4cc Content-Type: text/plain; charset=UTF-8 On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla wrote: > > > On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide < > viktor.s.wold.eide@gmail.com> wrote: > >> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote: >> >>> >>> >>> TLS 1.3 encrypts both the client's and server's certificates already. >>> The server's certificate is secure only against passive attack. The >>> client's is encrypted with a key that the client can authenticate as >>> belonging to the server. >>> >>> >> >> It's good to see that both the client's and the server's certificates are >> encrypted in TLS 1.3, providing protection against passive eavesdropping. >> >> For some use cases it might be worthwhile to reduce the information made >> available to an active attacker also. Are there any suggestions in this >> direction for TLS 1.3? >> >> One might think of a multi stage approach, something like: >> - Anonymous connection establishment, resulting in a secure channel. >> - Authentication by means of group certificate. >> - Authentication by means of a host specific certificate. >> >> The purpose of the second step above is to first only provide the group >> identity to an active attacker, and then to reveal the host identities >> (certificate information) only after group membership has been mutually >> authenticated >> > > I don't think this matches most TLS use cases very well, since the client > generally isn't authenticated at all, so there's no point in the server > progressively > revealing more. > > Although the client generally is not authenticated currently, TLS 1.3 and DTLS 1.3 are likely to stay for a long time and then to be used for lots of different use cases, including more peer-to-peer interaction. For some use-cases, including peer-to-peer interaction, being able to progressively reveal more information would improve protection. Whether this is a worthwhile tradeoff or not, depends on many different factors. I think it is both relevant and interesting to see to what extent (D)TLS 1.3 would support such use cases. Best regards Viktor S. Wold Eide --047d7bdcab347ce824051e5fe4cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
<= br>

On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide &= lt;viktor= .s.wold.eide@gmail.com> wrote:
On Mon, Aug 24, 2015 at 11:17= PM, Eric Rescorla <ekr@rtfm.com> wrote:


TLS 1.3 encrypts both the client'= s and server's certificates already.
The server's certificate i= s secure only against passive attack. The
client's is encrypt= ed with a key that the client can authenticate as
belonging to th= e server.



It's good to see that both= the client's and=20 the server's certificates are encrypted in TLS 1.3, providing protectio= n against passive eavesdropping.

For some use cases it=20 might be worthwhile to reduce the information made available to an=20 active attacker also. Are there any suggestions in this direction for=20 TLS 1.3?

One might think of a multi stage approach, somet= hing like:
- Anonymous connection establishment, resulting in a secure c= hannel.
- Authentication by means of group certificate.
- Authentication by means of a host specific certificate.

<= /div>
The purpose of the second step above is to first only provide the group=20 identity to an active attacker, and then to reveal the host identities (cer= tificate information) only after group membership has been mutually authent= icated

I don&#= 39;t think this matches most TLS use cases very well, since the client
generally isn't authenticated at all, so there's no point in = the server progressively
revealing more.


Although the client ge= nerally is not=20 authenticated currently, TLS 1.3 and DTLS 1.3 are likely to stay for a=20 long time and then to be used for lots of different use cases, including more peer-to-peer interaction. For some use-cases, including=20 peer-to-peer interaction, being able to progressively reveal more=20 information would improve protection. Whether this is a worthwhile tradeoff= or=20 not, depends on many different factors. I think it is both relevant and=20 interesting to see to what extent (D)TLS 1.3 would support such use=20 cases.

Best regards
Viktor S. Wold Eide

<= /div>
--047d7bdcab347ce824051e5fe4cc-- From nobody Fri Aug 28 07:49:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65B01B2D31 for ; Fri, 28 Aug 2015 07:49:35 -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 Y5mpV2k2sKVB for ; Fri, 28 Aug 2015 07:49:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EEA1B2C5E for ; Fri, 28 Aug 2015 07:49:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 09AF2284D24; Fri, 28 Aug 2015 14:49:33 +0000 (UTC) Date: Fri, 28 Aug 2015 14:49:33 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150828144932.GH9021@mournblade.imrryr.org> 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: Subject: Re: [TLS] Privacy considerations - identity hiding from eavesdropping in (D)TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 14:49:35 -0000 On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote: > > I don't think this matches most TLS use cases very well, since the client > > generally isn't authenticated at all, so there's no point in the server > > progressively > > revealing more. > > > > > Although the client generally is not authenticated currently, TLS 1.3 and > DTLS 1.3 are likely to stay for a long time and then to be used for lots of > different use cases, including more peer-to-peer interaction. For some > use-cases, including peer-to-peer interaction, being able to progressively > reveal more information would improve protection. Whether this is a > worthwhile tradeoff or not, depends on many different factors. I think it > is both relevant and interesting to see to what extent (D)TLS 1.3 would > support such use cases. It seems that with TLS 1.3 the client MUST send SNI, presumably in the clear. Typically there's not much else of interest in the server certificate to hide. I don't see a realistic way to hide the server identity even from passive wiretap via TLS. Encryption of the TCP layer, plus TLS channel-binding (or super-encryption) might be necessary to limit the metadata leakage to just the transport layer endpoint addresses. With IPsec the leakage is just the network layer addresses. Is anyone looking into leveraging TCPinc (when available) in TLS? Extract channel-binding data from the socket, authenticate it with TLS, and perhaps use TLS with NULL ciphers and if possible a simplified handshake... -- Viktor. From nobody Fri Aug 28 08:08:42 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59531B29F9 for ; Fri, 28 Aug 2015 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.695 X-Spam-Level: ** X-Spam-Status: No, score=2.695 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 HFLq4YiRJelN for ; Fri, 28 Aug 2015 08:08:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (unknown [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D41ACE23 for ; Fri, 28 Aug 2015 08:08:38 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 78F914C018 for ; Fri, 28 Aug 2015 15:08:37 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 62DE94B838 for ; Fri, 28 Aug 2015 15:08:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440774517; bh=D7Tgha7YXZHb3EL7tbyMEYOOJeJfg/SS8EpqIzPnGCE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=oXkzohuYj1ptHZ/zCwBagkp2361EmnPL5s4UJDwtxofqggB3HrjfRNuJr4mAXzA2+ IPSVs8SdauaR5aOUJ0Exl+jNgwOS3wpIwuQe1Hui5uGpZPbpNzHYYys56dYRZofp1T hK11FKLJoR1TcF8+punU+CzychN9RfKqxuf++EzY= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 3C4DC2069 for ; Fri, 28 Aug 2015 15:08:37 +0000 (GMT) Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 28 Aug 2015 10:08:36 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 28 Aug 2015 08:08:36 -0700 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Fri, 28 Aug 2015 10:08:36 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: [tls13-spec] expand MTI Extensions and add more strict requirements (#232) Thread-Index: AQHQ4Q8euOk3t0CCHUSpRsz8/mu4CZ4guImAgADLRrA= Date: Fri, 28 Aug 2015 15:08:35 +0000 Message-ID: <6a08cc2038f749f8b94da7a09991c446@ustx2ex-dag1mb2.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [tls13-spec] expand MTI Extensions and add more strict requirements (#232) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:08:41 -0000 SGF2aW5nIGRpc2N1c3Npb25zIHRocm91Z2ggZ2l0aHViIGlzIGEgcmVhbGx5IGJhZCBpZGVhLiAg TWFpbCBmb3JtYXR0aW5nIGNhbiBnZXQgZXZlbiBtb3JlIG1hbmdsZWQsIGFuZCB3ZSBsb3NlIHRo ZSBJRVRGIG1haWwgYXJjaGl2ZSBhbmQgcGFydGljaXBhdGlvbi4gIEkgdGhpbmsgd2UgbmVlZCB0 byBiZSBtb3JlIGRpbGlnZW50IGFuZCBhdm9pZCBkb2luZyB0aGF0Lg0KDQo+IFRoZXJlJ3MganVz dCBubyBzdGF0ZW1lbnQgb2Ygd2hhdCB0byBkbyB3aGVuIGl0J3MgcmVxdWlyZWQgYW5kIG5vdCBn aXZlbi4NCg0KVGhhdCdzIG5vdCBuZWNlc3NhcmlseSBhIHByb2JsZW0uICBUaGUgYmVoYXZpb3Ig b2YgdGhlIG90aGVyIHBhcnR5IG5lZWQgbm90IGJlIHN0cmljdGx5IGRlZmluZWQuICBJdCBjYW4g c2VuZCBhbiBhbGVydCBvciBjb250aW51ZSBhbG9uZyBhcyBiZXN0IGFzIGl0IHdhbnRzLiAgTWVy ZWx5IGRlc2NyaWJpbmcgd2hhdCBtdXN0IGJlIGRvbmUgaXMgZW5vdWdoLiAgVmVyeSBmZXcgc3Bl Y3MgZnVsbHkgbWFuZGF0ZSB3aGF0IG11c3QgYmUgZG9uZSBpZiBhbGwgdGhlIHJlcXVpcmVtZW50 cyBhcmUgbm90IG1ldDsgSSB0aGluayBYTUwgd2FzIHRoZSBmaXJzdCB3aWRlc3ByZWFkIEludGVy bmV0IG9uZSB0byBkbyBzby4NCg0KCS9yJA0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2Ft YWkgVGVjaG5vbG9naWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6 DQo= From nobody Fri Aug 28 09:13:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37EC1A1AA6 for ; Fri, 28 Aug 2015 09:13: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 k8yWwnXMwODW for ; Fri, 28 Aug 2015 09:13:06 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CF01A03E3 for ; Fri, 28 Aug 2015 09:13:06 -0700 (PDT) Received: by qkfh127 with SMTP id h127so31043334qkf.1 for ; Fri, 28 Aug 2015 09:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=7NOdRygUsKsYn34zvm4ZM+e3q+xWkNUkl8fcQv0/FMo=; b=W+Tft7i34c9fCEq7eZglZ7rwnrp0OCCBgmkE4tbkGUlB4vQOtMJj118DsvGQJoz8v0 UsJ/bDB6TUlyn4TEviSc3kYc9KRvAjlxEwHGZtMyPOYUM6h8s8X13vmCyWd+21uG+2BE ELv79qBJQ4XDP6oCfa6NPUfyZF1nsHGA6izGJtnaToXVjCLNzFqkzwREc1YxB+gkBbn0 9c5m5LNLjp78H7H5NFHE+mZXbRdLJtUh0nbZ4Pymw8nO/1QheLE6ikxPjF85LHWwJ30s byAGZjstNlL0a0LnuuaDJN6Cy+DX2bMDs74fJyTRYG9OQjbZR6YfMSH91OdAcR5J5E+3 +ihQ== X-Received: by 10.55.51.79 with SMTP id z76mr17345773qkz.32.1440778385432; Fri, 28 Aug 2015 09:13:05 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id g49sm3693349qgf.29.2015.08.28.09.13.04 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 09:13:04 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 28 Aug 2015 12:13:03 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150828144932.GH9021@mournblade.imrryr.org> In-Reply-To: <20150828144932.GH9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508281213.03823.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 16:13:08 -0000 On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote: > Having discussions through github is a really bad idea. You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now. On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote: > It seems that with TLS 1.3 the client MUST send SNI, presumably in > the clear. Typically there's not much else of interest in the > server certificate to hide. I don't see a realistic way to hide > the server identity even from passive wiretap via TLS. Currently, we're at implementations MUST support (not necessarily send) SNI, servers MAY require it, and servers SHOULD error on such a failed requirement. This doesn't change the status quo much. If servers don't require it, you don't need to send it. HTTP/2 has its own SNI requirement, though, so lots of TLS will be moving in that direction. The idea I had the other day is that we can technically do SNI encryption with the current TLS 1.3 draft, as-is. All that needs to really be done is stick it in a 0-RTT EncryptedExtensions, preferably only when the server specifies that it is allowed via adding a flag to server config. This would require the actual server share the 0-RTT DH key across the virtual servers it's picking via SNI, so early data probably should be off in this instance for many use-cases. The simplest route that would allow for encrypted SNI with 0-RTT application data allowed would be to just add a second long-term DH key to the server config for SNI (and an option for servers to have one do both if they don't need two). Seeing as this would still need to be opt-in via a flag in the config, we could use the same extension ID and just encrypt it using the second key. Servers that provide an SNI key get encrypted; others get clear or none. If we can also get a way to distribute server config out-of-band, this would even allow initial-connection SNI encryption. I don't think encrypted SNI to servers without any prior information is really that viable, and that's been said before by others on this list. Now, with that said, you could just create a way for any client to ask a server for its config without any attempt to connect right away, in which case it can follow up with encrypted SNI at the cost of that 1-RTT (e.g. the QUIC way of doing things). Even if we allow ServerConfiguration to be optional normally, we could add this config request mode and make support for that mandatory (though, potentially with short-lived keys). This route would still require some prior information about this server: knowledge that it could request a key for SNI at all without just getting rejected. Doing so without that would require a multiple attempt check of some kind that's probably a bad idea. Dave From nobody Fri Aug 28 09:22:56 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037751A1B8B for ; Fri, 28 Aug 2015 09:22:55 -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 rs0Lhb5Jbkp0 for ; Fri, 28 Aug 2015 09:22:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB931A1B88 for ; Fri, 28 Aug 2015 09:22:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1BE33284D24; Fri, 28 Aug 2015 16:22:52 +0000 (UTC) Date: Fri, 28 Aug 2015 16:22:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150828162251.GM9021@mournblade.imrryr.org> References: <20150828144932.GH9021@mournblade.imrryr.org> <201508281213.03823.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201508281213.03823.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 16:22:55 -0000 On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote: > The idea I had the other day is that we can technically do SNI encryption > with the current TLS 1.3 draft, as-is. All that needs to really be done > is stick it in a 0-RTT EncryptedExtensions, preferably only when the server > specifies that it is allowed via adding a flag to server config. This > would require the actual server share the 0-RTT DH key across the virtual > servers it's picking via SNI, so early data probably should be off in this > instance for many use-cases. So the client would now need to cache some session data by transport address, and other data by name and port. That's rather complex. And how often will the same client visit multiple servers at the same transport address? I don't really see this as viable or worth the effort. > I don't think encrypted SNI to servers without any prior information is > really that viable, and that's been said before by others on this list. I don't think SNI hiding is viable without encryption at the transport or network layers. And there's still a metadata leak via DNS which may prove difficult to address. -- Viktor. From nobody Fri Aug 28 09:33:35 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671A01A8903 for ; Fri, 28 Aug 2015 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnqysQWZgpLg for ; Fri, 28 Aug 2015 09:33:32 -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 C12251A887E for ; Fri, 28 Aug 2015 09:33:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2DF2E740098 for ; Fri, 28 Aug 2015 16:33:32 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 178B4740050 for ; Fri, 28 Aug 2015 16:33:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440779612; bh=yqGgmvKT47S5YWZNFVQMEQu9cXy+4V86Lp3Z2IGfGEo=; l=915; h=From:To:Date:References:In-Reply-To:From; b=amGcjrVCpw9pBLvAgDIXFweDg6+p9jiVPxRbSbKgA5d2F+Pzyw6rGnJaEpev14pn6 wAvA6ESFes7c0Q4qkDmVzD7zD0VN/RAw+vKtXLIdIQyOVUW6jDjJub3nB1LA/9Bbe1 xUT8Ld4uF+iIX6jGXPOXAz9B2f37gdfrNbfCOWWM= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 13EEE1E080 for ; Fri, 28 Aug 2015 16:33:32 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 28 Aug 2015 11:33:31 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Fri, 28 Aug 2015 11:33:31 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) Thread-Index: AQHQ4ayRRnZKd+mYm0W69zVWwS2qcZ4h7AsA//+sgMA= Date: Fri, 28 Aug 2015 16:33:31 +0000 Message-ID: References: <20150828144932.GH9021@mournblade.imrryr.org> <201508281213.03823.davemgarrett@gmail.com> <20150828162251.GM9021@mournblade.imrryr.org> In-Reply-To: <20150828162251.GM9021@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 16:33:34 -0000 > > The idea I had the other day is that we can technically do SNI > > encryption with the current TLS 1.3 draft, as-is. Yeah, some of us talked about this in Dallas, etc., when the "semi-static E= DH key" really started to take hold. I showed slides at the interim before= IETF 90 in Toronto, that seemed to convince everyone that it doesn't reall= y get you the privacy you think you get. (I couldn't find them in the meet= ing materials; if anyone wants the PDF let me know.) There's still the DNS = leakage, to which dkg reasonably points out that we should not succumb to t= he deadly embrace of each component waiting for the other. > And how often will the same client visit multiple servers at the same > transport address? Anyone who visits sites hosted by a CDN. And, I suspect, many large portal= s. =20 > I don't really see this as viable or worth the effort. Agree. /r$ From nobody Fri Aug 28 10:01:54 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FBD1B2E01 for ; Fri, 28 Aug 2015 10:01: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 n279JNoB7bgL for ; Fri, 28 Aug 2015 10:01:52 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A8C1B2DE7 for ; Fri, 28 Aug 2015 10:01:52 -0700 (PDT) Received: by qgi69 with SMTP id 69so3792148qgi.1 for ; Fri, 28 Aug 2015 10:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=HvmYclU4RUZXkCJ76til8TERFjsBf/ZQcdaRMIErrd8=; b=w+MjuEUvsjs1bWilVuWaT2DCXu1SAFxxw9twCRRejXGanmnOwve+51hXf05tfJbL0q PA6mWttFAm+wsmBqFadzoBb2ltsXUygNVbEeby90COC2jhX0+pY9MqU0zEdiZCnO4L2x 2bRHXBQT32DNS2ndaSP1GgwKMizU01aVfmek/6vs3lUuLKhp421uJsuIuXl0F58Amm3t Byl967bhXOJjN0SnZ1cgQVGmbkAQOFM4T29viHxQ0FDDEYQ1Frozo08FqUGQjE/Gawqo i/74e0Ln0WTqfXm0daUchSw8ZFE4TORbSDa3yQv9G43SDtIdzznwB2FbfThGFmNEvJpT Ro7w== X-Received: by 10.140.133.84 with SMTP id 81mr18614849qhf.13.1440781311325; Fri, 28 Aug 2015 10:01:51 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id b16sm3804297qkj.1.2015.08.28.10.01.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 10:01:50 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 28 Aug 2015 13:01:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150828162251.GM9021@mournblade.imrryr.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508281301.49878.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:01:53 -0000 On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote: > > And how often will the same client visit multiple servers at the same > > transport address? > > Anyone who visits sites hosted by a CDN. And, I suspect, many large portals. How's it done with IPv6, generally? Are there setups where everyone is sharing a v6 IP? We could eventually get to the point where a reverse DNS lookup is all that's needed for everyone if things were set up smartly. Probably a better setup for things to work, but worse for passive surveillance. (though, IPv6 could eventually let clients randomize their IP frequently, which helps some things; getting off-topic here, though) > > I don't really see this as viable or worth the effort. > > Agree. I agree that it's a lot of effort for relatively little gain. I might be worth considering, but if the consensus is that TLS just isn't designed to do this easily enough to be worth it, then I don't really dispute a decision to just drop the concept. Dave From nobody Fri Aug 28 10:06:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9CF1B2EB2 for ; Fri, 28 Aug 2015 10:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iaa-AmHUaLNX for ; Fri, 28 Aug 2015 10:06:04 -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 51D3A1B2DE7 for ; Fri, 28 Aug 2015 10:06:03 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8367D496C02; Fri, 28 Aug 2015 17:06:02 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6DD9A496C09; Fri, 28 Aug 2015 17:06:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1440781562; bh=0umb/niv6OOaIPiaLP4O9Sxk2PbDn+dzeFqTY7LMlzQ=; l=399; h=From:To:Date:References:In-Reply-To:From; b=C2VDlcDwr6MD5Cvn3SUZQ0NUKNQYGtQufDm87Jagado+x4N23R3pt4KOS1ls66Uy4 NyR5nXhWEV5ljRcaZByiWWx7+XGhQB8zwKRs7g5EwUBpfmOqbJaM89X4x3s0GsQtjF HPfu4bPZfwUAyN37vOTeQiplJMXtTA847Fd5K//I= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 58DE31E080; Fri, 28 Aug 2015 17:06:02 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 28 Aug 2015 12:06:02 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1076.000; Fri, 28 Aug 2015 12:06:02 -0500 From: "Salz, Rich" To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) Thread-Index: AQHQ4ayRRnZKd+mYm0W69zVWwS2qcZ4h7AsA//+sgMCAAF5igP//rJDA Date: Fri, 28 Aug 2015 17:06:01 +0000 Message-ID: <2e7934c3813a42548c26016c1c5373dd@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150828162251.GM9021@mournblade.imrryr.org> <201508281301.49878.davemgarrett@gmail.com> In-Reply-To: <201508281301.49878.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:06:05 -0000 > How's it done with IPv6, generally? We don't see address-sharing with IPv6, although I wonder if that will chan= ge when the routing tables get too big. :) We also don't see anyone willin= g to go IPv6-only; it's not close to universal enough yet. > I agree that it's a lot of effort for relatively little gain. It doesn't protect those who need it against those who would harm them. From nobody Fri Aug 28 10:11:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6B1B3602; Fri, 28 Aug 2015 10:11: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 ZMPOgGPHk-lJ; Fri, 28 Aug 2015 10:11:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 491B41B3629; Fri, 28 Aug 2015 10:11:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150828171144.25381.93164.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 10:11:44 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:11:46 -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 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-08.txt Pages : 103 Date : 2015-08-28 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and 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: https://tools.ietf.org/html/draft-ietf-tls-tls13-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 28 10:13:17 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D31A8AE2 for ; Fri, 28 Aug 2015 10:13: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 4Tl_ul9FmRwL for ; Fri, 28 Aug 2015 10:13:13 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BD31A21BA for ; Fri, 28 Aug 2015 10:13:12 -0700 (PDT) Received: by wicne3 with SMTP id ne3so24816081wic.0 for ; Fri, 28 Aug 2015 10:13:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=UYZV5NeKmlAcwm+s+0th+B8+FYL2U46vGbgXKYaof7Y=; b=aUsKQhvRsZxhO1ifbapn5ROSI5U5Xi4HhqW5b0Oa099K/xhT4qiL8SV46qJsCoE8pE WrzasHoa4v70eRcgQZ9ghxfGEbVmD563mvhzHpKuXVKXG2eeIMHC4J30ja3fsIyXE2D4 6BFmcYky6H1O51pmlTlYyGkKRP81A283twbSpgreK7v4X6Qrsmb8Dxqc7B9vFCIFWM5C ga9RB5Kcdna72eq9Vc+u2TW6QZrB38wzReA62V38ZM8fIDuBSMd8cKJvfLV6p2E6AmoJ duoRes3G3ilJIxuYXc+ZWtT6P4E4uXCCN8gC2W/lUHvfAYoC6+Bly60JmLWWb80cvfdM zjsA== X-Gm-Message-State: ALoCoQmRc9TykQntHnupaPBAS442XGCRiIfaBNjoDFRu28ee/+8kno12UP6h6tJHk0xnlJCBxchz X-Received: by 10.194.79.225 with SMTP id m1mr12913382wjx.8.1440781991309; Fri, 28 Aug 2015 10:13:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Fri, 28 Aug 2015 10:12:31 -0700 (PDT) From: Eric Rescorla Date: Fri, 28 Aug 2015 10:12:31 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10c903ca8da8051e6232db Archived-At: Subject: [TLS] draft-ietf-tls-tls13-08 and plan for future drafts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:13:14 -0000 --047d7b10c903ca8da8051e6232db Content-Type: text/plain; charset=UTF-8 Folks, I've just posted draft-08 which includes the changes discussed on-list to require digital signatures from the client even if you are re-using a previous configuration in 0-RTT (per WG discussion). This version also includes a bunch of other cleanup, as detailed below: - Remove support for weak and lesser used named curves. - Remove support for MD5 and SHA-224 hashes with signatures. - Revise list of currently available AEAD cipher suites. - Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. - Require digital signatures even when a previous configuration is used. - Merge EarlyDataIndication and KnownConfiguration. - Change code point for server_configuration to avoid collision with server_hello_done. As usual, comments welcome. If you think I missed something important please let me know and/or file a github issue so I don't forget it this time. I thought it might be useful for people to know what's coming in upcoming drafts. 1. As I mentioned in Prague, I plan to do a fairly significant restructuring/editorial effort to make things easier to read. This will include: - Reordering the text to put the overview first. - Cleaning up or removing obsolete/redundant material (e.g., the now really old security analysis) - General editorial cleanup. 1. The intention is to produce a cleaned-up draft that doesn't have any major technical changes (optimally no technical changes) but is significantly easier to read. I'm targeting that for early September. I'll keep a github branch up to date on this in case people want to see how it's going. 2. In parallel I'll be starting threads on the list to try to resolve a number of open technical issues. Hopefully we can deal with a bunch of this on the list and get the rest on-deck for the interim in SEA. Depending on the timeline and the number of issues we resolve, I may do a -09 and then have -10 be the rewrite, or -09 may just be the rewrite. -Ekr --047d7b10c903ca8da8051e6232db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just posted = draft-08 which includes the changes discussed on-list
to require = digital signatures from the client even if you are re-using
a pre= vious configuration in 0-RTT (per WG discussion).

= This version also includes a bunch of other cleanup, as detailed below:

- Remove support for weak and lesser used named curve= s.

- Remove support for MD5 and SHA-224 hashes wit= h signatures.

- Revise list of currently available= AEAD cipher suites.
=C2=A0
- Reduce maximum permitted = record expansion for AEAD from 2048 to 256 octets.

- Require digital signatures even when a previous configuration is used.
=C2=A0=C2=A0
- Merge EarlyDataIndication and KnownConfig= uration.

- Change code point for server_configurat= ion to avoid collision with
=C2=A0 server_hello_done.
<= br>
As usual, comments welcome. If you think I missed something i= mportant
please let me know and/or file a github issue so I don&#= 39;t forget it
this time.


I thought it might be useful for people to know what's coming in
=
upcoming drafts.

1. As I mentioned in Prague,= I plan to do a fairly significant
restructuring/editorial effort= to make things easier to read.
This will include:

=
- Reordering the text to put the overview first.
- Cle= aning up or removing obsolete/redundant material
=C2=A0 (e.g., th= e now really old security analysis)
- General editorial cleanup.<= /div>


1. The intention is to produce a cl= eaned-up draft that doesn't have any major
technical changes = (optimally no technical changes) but is
significantly easier to r= ead. I'm targeting that for early September.
I'll keep a = github branch up to date on this in case people want to
see how i= t's going.

2. In parallel I'll be starting= threads on the list to try to resolve
a number of open technical= issues. Hopefully we can deal with a bunch
of this on the list a= nd get the rest on-deck for the interim in SEA.

De= pending on the timeline and the number of issues we resolve, I may
do a -09 and then have -10 be the rewrite, or -09 may just be the
rewrite.

-Ekr



















--047d7b10c903ca8da8051e6232db-- From nobody Fri Aug 28 10:35:58 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7CF1B30C2 for ; Fri, 28 Aug 2015 10:35: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 BUcj5gkYyfM8 for ; Fri, 28 Aug 2015 10:35:52 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6DD1B2EB2 for ; Fri, 28 Aug 2015 10:35:52 -0700 (PDT) Received: by wibcx1 with SMTP id cx1so3006865wib.1 for ; Fri, 28 Aug 2015 10:35:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=z5PLD4wqYR2ALYEDLd021d6LdRm6hAzJ0WILa+nI0Rw=; b=F+TRfEb3ss7eVIE7ETyXCU0SM+vpDNBsyubtBaYVRV6HN+Ab3sU1to835vJCsozqom k8/RCtd9YCvNng744wNaK1OOGNKog0O6HpAjZ0hJh/kl72iNct2gcXM7RhfVkZyX/ukk aISIK6WQuk8xL7Eo6m5gNMjYX1Eei9ER6b5DxqdeXWe6285gxMuavvCeIaP8LWo4noWY ynVWN5bhNEuIOmd3czWKXSRylEx44FUpGethcWsTnGjDVpt8nR9AIHR6KRzwX06vcR2H /cQjLm3tQAJbSJDeQfmy+DP7O1dhuc2WCnAqG++e4fFpkHTzDbdq+vvwSjg6sDIStAB3 HVuw== X-Gm-Message-State: ALoCoQk1tXOKxmUPcxOpqg8gchwjbsCdAF7zVJp9eYTO7kHeJj2DoqdgIA5nqxw22/+izTzkiG/t X-Received: by 10.194.79.225 with SMTP id m1mr13013820wjx.8.1440783351264; Fri, 28 Aug 2015 10:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Fri, 28 Aug 2015 10:35:11 -0700 (PDT) From: Eric Rescorla Date: Fri, 28 Aug 2015 10:35:11 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10c903d9c672051e6283a1 Archived-At: Subject: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:35:57 -0000 --047d7b10c903d9c672051e6283a1 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/233 Folks, We presently have some support for DH_anon cipher suites. I agree that this is a useful use case, but it's yet another mode. I would like to suggest that we instead deprecate it and instead always use Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that the client would simply indicate support for a raw public key and the server could then either (a) spin a new key for this use or (b) use a long-term one. To my mind this has three advantages: 1. Complexity: It means that we have one less operational mode. And all the public key modes would look cryptographically similar. 2. It resolves the question of how you bind to the server's identity in 0-RTT mode (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key that goes in the Certificate message. 3. It makes it easier to do an SSH-style leap-of-faith mode since the server can use the same signing key for a long time while maintaining PFS. It seems to me that the two major counterarguments are: 1. Extra computational cost from the signature. I'm not worried too much about that since generally the anonymous contexts don't do a lot of connections and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes anyway. 2. It's less explicit that this is unverified. Arguably this is a feature rather than a bug. Thoughts? -Ekr --047d7b10c903d9c672051e6283a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
https://github.com/tlswg/tls13-spec/issues/233

= Folks,

We presently have some support for DH_anon = cipher suites. I agree that this
is a useful use case, but it'= ;s yet another mode.

I would like to suggest that = we instead deprecate it and instead always use
Raw Public Key mod= e (https://tools.ietf.org/h= tml/rfc7250). The idea is that
the client would simply indica= te support for a raw public key and the
server could then either = (a) spin a new key for this use or (b) use a long-term
one. To my= mind this has three advantages:

1. Complexity: It= means that we have one less operational mode. And all the public key
modes would look cryptographically similar.

2. It resolves the question of how you bind to the server's identity= in 0-RTT mode
(https://github.com/tlswg/tls13-spec/issues/219), namely the r= aw public key
that goes in the Certificate message.
3. It makes it easier to do an SSH-style leap-of-faith mode sin= ce the server can
use the same signing key for a long time while = maintaining PFS.

It seems to me that the two major= counterarguments are:

1. Extra computational cost= from the signature. I'm not worried too much
about that sinc= e generally the anonymous contexts don't do a lot of connections
<= div>and we don't really want to encourage pure anonymous (i.e., non-TOF= U) modes
anyway.

2. It's less explic= it that this is unverified. Arguably this is a feature rather than
a bug.

Thoughts?
-Ekr



--047d7b10c903d9c672051e6283a1-- From nobody Fri Aug 28 10:51:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2771B3567 for ; Fri, 28 Aug 2015 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH96OmImmGkQ for ; Fri, 28 Aug 2015 10:51:29 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5DE1B355D for ; Fri, 28 Aug 2015 10:51:28 -0700 (PDT) Received: by qkch123 with SMTP id h123so32584651qkc.0 for ; Fri, 28 Aug 2015 10:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=0uRyO6wDDNcEwxIxESxgkesICUio8/Q1JFdLOOC5Vf4=; b=PNPqB2o0ab+7EiPLvTkNVWipgoDN4q41SC8xfzl7kQ8lEMaFiWUgSPCo3dgnj3+Tz5 +V1+QPMB4ximE0EsKDLtJEZc6md9jHPOW98tVdWA1UclDSm4nuQ21a3s8zb1U3JRd+1m 4WJW8QafHv5184B34Em3yaCh4WcohkLcpoQQ1XE5wU3SzvHgDQTaHC7T1x33hMRsJZ/Z vqXLShg5h7ULBfkZpmyWbBH6z99b2tEiJ6anpZtFJfOvB5SELgHdusXG9deL94ffq1L8 mQ1DppNTrY0IwydRb9jXXk9SxPXiT2qU7ZEE4I2ujznuf4gPHTHsikwBuQ+xIhQsFCv1 QQjQ== X-Received: by 10.55.25.220 with SMTP id 89mr17877512qkz.40.1440784288185; Fri, 28 Aug 2015 10:51:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 136sm3845438qhb.20.2015.08.28.10.51.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 10:51:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Eric Rescorla Date: Fri, 28 Aug 2015 13:51:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201508281351.26566.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 17:51:31 -0000 I actually had this in my old a la carte proposal. Here's the relevant section posted separately, unedited, except for keeping the current list of RFCs with anon that weren't in that proposal: https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated Dave From nobody Fri Aug 28 11:07:06 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF71A8ADD for ; Fri, 28 Aug 2015 11:07: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 U7YSYCv-O9QY for ; Fri, 28 Aug 2015 11:07:03 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204FB1A8983 for ; Fri, 28 Aug 2015 11:07:03 -0700 (PDT) Received: by ykba134 with SMTP id a134so10360368ykb.1 for ; Fri, 28 Aug 2015 11:07: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=u8qhKhEa0vQtEOg2epsPdMBInH45biaIPBhsseFU1Lw=; b=s8F+C0ar6YIffg7OQoBSuud5OBflJDTRGMpF5D7hY2iVLSsc1njbNk3nA22YOKqeMz NpWhXjYftDUSOolFbdhJnA7HML1cH7OFHrtIkikfPcR9ymPH/AhkEmaFaUN133NhoYl4 qP8u1hD5XfvhPu/5pxKZff0/BLwd6Yv1x44tecFdUjiDGcv4tAgrRq/N8jOSZ0Cy+8oB AiQ6/y+BUf5ilCAb3zRStSSnRWMngebu5IKoJVFhwDNNg1nLxcOSe1tXaWWJCduzNQvy ahef9zcELtr6us/1hSXPodP9i8SDMezkXMXIWOF2m9r7bI4EWXMcGpZYFdzx4rW07dYk X4mw== MIME-Version: 1.0 X-Received: by 10.13.206.67 with SMTP id q64mr10479935ywd.154.1440785222505; Fri, 28 Aug 2015 11:07:02 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Fri, 28 Aug 2015 11:07:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Aug 2015 11:07:02 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:07:05 -0000 This seems fine to me, though I'll note that 7250 only really saves you space when it comes down to it. You can wrap your raw public key in a certificate, just like we do in WebRTC, and then you don't need 7250 support in your library. Noting you can only do any of these variations in a context where there is some preexisting understand that what you choose to use is acceptable to the other side. Regarding the explicit nature of having an explicit DH_anon signal, I tend to think that (on balance) removing this signal does more good than harm. I expect certain others to disagree, of course, but we can talk about why a vigorous defense of the cipher suite signal isn't a good use of their energy later. On 28 August 2015 at 10:35, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/233 > > Folks, > > We presently have some support for DH_anon cipher suites. I agree that this > is a useful use case, but it's yet another mode. > > I would like to suggest that we instead deprecate it and instead always use > Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that > the client would simply indicate support for a raw public key and the > server could then either (a) spin a new key for this use or (b) use a > long-term > one. To my mind this has three advantages: > > 1. Complexity: It means that we have one less operational mode. And all the > public key > modes would look cryptographically similar. > > 2. It resolves the question of how you bind to the server's identity in > 0-RTT mode > (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key > that goes in the Certificate message. > > 3. It makes it easier to do an SSH-style leap-of-faith mode since the server > can > use the same signing key for a long time while maintaining PFS. > > It seems to me that the two major counterarguments are: > > 1. Extra computational cost from the signature. I'm not worried too much > about that since generally the anonymous contexts don't do a lot of > connections > and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes > anyway. > > 2. It's less explicit that this is unverified. Arguably this is a feature > rather than > a bug. > > Thoughts? > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Aug 28 11:10:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755F1B2F07 for ; Fri, 28 Aug 2015 11:10:49 -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 RWX2109SkCsi for ; Fri, 28 Aug 2015 11:10:47 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC881AD09C for ; Fri, 28 Aug 2015 11:10:46 -0700 (PDT) Received: by wicfv10 with SMTP id fv10so19009696wic.0 for ; Fri, 28 Aug 2015 11:10: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=nKJkRzyARe6aEi3VWSUQ8c1i3GQYcSdDAb4ZjyGCZ+Y=; b=EUsRbleu0i2ipdhtTHeudewLwpCr4Jcjcg5aSp5mO6wGZn7/7/mfinuf3RJQ1MjiTt 87xjXR44CVAujRQ2CA+wg0iDc0BobfabL7yK52Qa0VGXvziorDdRIWq3Mqn4+lyYCpBC /ZUtCRjzkMtUCyCVtWOHT1bDorp6EjW6T56K0T9VC+yqfOs/lnHfLgF4IWnMcxV5w+Xi qZl5haZSYe7QcfhGTy1CtD1h6IQQOtsPkDEPn2wFTzLRbVeq0ywl6txnfEEZRgJPPisl DPazwBa7plExNkJoEx1aLhpzkS32MYjFwN0uyYf3Pbz9Cl6CDIAEEo1Gy0PtiOvKw91O 2abQ== X-Gm-Message-State: ALoCoQnkX24GtMeDAD7l77fWK3hBnb8fYFF063EH5h2sG5867p0HSGirw/PwxF8N1va42bIkBdte X-Received: by 10.194.133.73 with SMTP id pa9mr12702889wjb.148.1440785445408; Fri, 28 Aug 2015 11:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Fri, 28 Aug 2015 11:10:05 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 28 Aug 2015 11:10:05 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e011771a9abdcab051e6300a4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:10:49 -0000 --089e011771a9abdcab051e6300a4 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson wrote: > This seems fine to me, though I'll note that 7250 only really saves > you space when it comes down to it. You can wrap your raw public key > in a certificate, just like we do in WebRTC, and then you don't need > 7250 support in your library. It also removes the need to parse the cert. > Noting you can only do any of these > variations in a context where there is some preexisting understand > that what you choose to use is acceptable to the other side. > SG. > Regarding the explicit nature of having an explicit DH_anon signal, I > tend to think that (on balance) removing this signal does more good > than harm. I expect certain others to disagree, of course, but we can > talk about why a vigorous defense of the cipher suite signal isn't a > good use of their energy later. > > On 28 August 2015 at 10:35, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/233 > > > > Folks, > > > > We presently have some support for DH_anon cipher suites. I agree that > this > > is a useful use case, but it's yet another mode. > > > > I would like to suggest that we instead deprecate it and instead always > use > > Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is > that > > the client would simply indicate support for a raw public key and the > > server could then either (a) spin a new key for this use or (b) use a > > long-term > > one. To my mind this has three advantages: > > > > 1. Complexity: It means that we have one less operational mode. And all > the > > public key > > modes would look cryptographically similar. > > > > 2. It resolves the question of how you bind to the server's identity in > > 0-RTT mode > > (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public > key > > that goes in the Certificate message. > > > > 3. It makes it easier to do an SSH-style leap-of-faith mode since the > server > > can > > use the same signing key for a long time while maintaining PFS. > > > > It seems to me that the two major counterarguments are: > > > > 1. Extra computational cost from the signature. I'm not worried too much > > about that since generally the anonymous contexts don't do a lot of > > connections > > and we don't really want to encourage pure anonymous (i.e., non-TOFU) > modes > > anyway. > > > > 2. It's less explicit that this is unverified. Arguably this is a feature > > rather than > > a bug. > > > > Thoughts? > > -Ekr > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --089e011771a9abdcab051e6300a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
This se= ems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it.=C2=A0 You can wrap your raw public key<= br> in a certificate, just like we do in WebRTC, and then you don't need 7250 support in your library.=C2=A0

It also= removes the need to parse the cert.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Noting you can only do any of these
variations in a context where there is some preexisting understand
that what you choose to use is acceptable to the other side.

SG.

=C2=A0
Regarding the explicit nature of having an explicit DH_anon signal, I
tend to think that (on balance) removing this signal does more good
than harm.=C2=A0 I expect certain others to disagree, of course, but we can=
talk about why a vigorous defense of the cipher suite signal isn't a good use of their energy later.

On 28 August 2015 at 10:35, Eric Rescorla <ekr@rtfm.com> wrote:
> https://github.com/tlswg/tls13-spec/issues/233
>
> Folks,
>
> We presently have some support for DH_anon cipher suites. I agree that= this
> is a useful use case, but it's yet another mode.
>
> I would like to suggest that we instead deprecate it and instead alway= s use
> Raw Public Key mode (https://tools.ietf.org/html/rfc7250= ). The idea is that
> the client would simply indicate support for a raw public key and the<= br> > server could then either (a) spin a new key for this use or (b) use a<= br> > long-term
> one. To my mind this has three advantages:
>
> 1. Complexity: It means that we have one less operational mode. And al= l the
> public key
> modes would look cryptographically similar.
>
> 2. It resolves the question of how you bind to the server's identi= ty in
> 0-RTT mode
> (https://github.com/tlswg/tls13-spec/issues/219), namely the raw public key
> that goes in the Certificate message.
>
> 3. It makes it easier to do an SSH-style leap-of-faith mode since the = server
> can
> use the same signing key for a long time while maintaining PFS.
>
> It seems to me that the two major counterarguments are:
>
> 1. Extra computational cost from the signature. I'm not worried to= o much
> about that since generally the anonymous contexts don't do a lot o= f
> connections
> and we don't really want to encourage pure anonymous (i.e., non-TO= FU) modes
> anyway.
>
> 2. It's less explicit that this is unverified. Arguably this is a = feature
> rather than
> a bug.
>
> Thoughts?
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e011771a9abdcab051e6300a4-- From nobody Fri Aug 28 11:33:22 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E901A1B98 for ; Fri, 28 Aug 2015 11:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Fh16lUJS_8 for ; Fri, 28 Aug 2015 11:33:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D5B1A897C for ; Fri, 28 Aug 2015 11:33:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E85C0284D24; Fri, 28 Aug 2015 18:33:17 +0000 (UTC) Date: Fri, 28 Aug 2015 18:33:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150828183317.GO9021@mournblade.imrryr.org> 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: Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:33:20 -0000 On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > This seems fine to me, though I'll note that 7250 only really saves > you space when it comes down to it. You can wrap your raw public key > in a certificate, just like we do in WebRTC, and then you don't need > 7250 support in your library. Noting you can only do any of these > variations in a context where there is some preexisting understand > that what you choose to use is acceptable to the other side. Indeed that's effectively what you get with DANE TLSA "3 1 1", when the client, the server or at present typically both don't support RFC 7250. > Regarding the explicit nature of having an explicit DH_anon signal, I > tend to think that (on balance) removing this signal does more good > than harm. I expect certain others to disagree, of course, but we can > talk about why a vigorous defense of the cipher suite signal isn't a > good use of their energy later. The signal has pros and cons. Absent channel-binding at the next layer up, it makes it clear to adversaries that active attacks are "safe". On the other hand, it allows servers to detect that a client is not planning to authenticate the server, which has forensic value, and can be used to grant appropriately restricted access. Furthermore, anon-DH has strong privacy properties, the server sends no identity information, not even a public key. Any channel-binding at the next layer is privacy protected. The proposal to use raw public keys sends a similar signal to servers that don't publish DANE-EE(3)/SPKI(1) TLSA records. X.509 clients can no longer to PKIX authentication. A server that does publish DANE-EE(3)/SPKI(1) records on the other hand can no longer conclude that authentication is not done. And of course clients may be doing public key pinning, be it TOFU, or via some out-of-band means. Clearly getting along without anon_DH is possible, since many servers or clients don't enable anon_DH ciphers and yet interoperate just fine with those that do. My view is that anon_DH should either be supported properly (be defined for the same symmetric cipher combinations as ciphersuites with certs or public keys) or as proposed not supported at all. Replacement by public keys is not semantically equivalent, it just saves a bit of network and code space relative to self-signed X.509. So I'm not yet convinced that the proposal is progress, we lose some and gain some. -- Viktor. From nobody Fri Aug 28 11:37:19 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3598C1A87C4 for ; Fri, 28 Aug 2015 11:37:18 -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 D5E4qJ3dp-my for ; Fri, 28 Aug 2015 11:37:16 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2621A1F20 for ; Fri, 28 Aug 2015 11:37:16 -0700 (PDT) Received: by wicfv10 with SMTP id fv10so19539487wic.0 for ; Fri, 28 Aug 2015 11:37:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=VBhGn9lOUai80L0Fy5M8OltHQqJUmO2Z/p9i5abtjLE=; b=mVRHZTITP84o5xddNQIo/iOE4Fm6UxUV2ZVjGMJYXQgi0deWfLtH+7YICdLdrdn//J xLMGK2GDmnJlkmrCVT8wkIof/oThYdUA7nioqSAxn1NzJtNbd2sSTUENwHJkCrLGlwqC aCM+EOlpEGq7SiRwaIBoDAlt5L/8oR7JNmI4eaRHBSj9fHURmYt2hQ7IxHE5PBB82CcF 4dwKglUMz6hsqvmtD2Ui/9X/jKkNbjCZlqRgnn4pG9br2v55ONmYT5aVcQndlh7adXsD Kow3YD+ZNSKHw9wlzYgmEoHPkK8mBELdeatFa0QChxJZDTNwbxjVrjSNY6G4DulkjQy4 VvaQ== X-Gm-Message-State: ALoCoQmqXqh2onfmiBOPXoZwFJfLeju/VXFYF6mF6fpEQ+fe1LsJcZrJ86/fOJ7G35lPzhSicN/m X-Received: by 10.194.133.73 with SMTP id pa9mr12810575wjb.148.1440787035282; Fri, 28 Aug 2015 11:37:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Fri, 28 Aug 2015 11:36:35 -0700 (PDT) In-Reply-To: <20150828183317.GO9021@mournblade.imrryr.org> References: <20150828183317.GO9021@mournblade.imrryr.org> From: Eric Rescorla Date: Fri, 28 Aug 2015 11:36:35 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e011771a96f7662051e635f01 Archived-At: Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:37:18 -0000 --089e011771a96f7662051e635f01 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni wrote: > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > > This seems fine to me, though I'll note that 7250 only really saves > > you space when it comes down to it. You can wrap your raw public key > > in a certificate, just like we do in WebRTC, and then you don't need > > 7250 support in your library. Noting you can only do any of these > > variations in a context where there is some preexisting understand > > that what you choose to use is acceptable to the other side. > > Indeed that's effectively what you get with DANE TLSA "3 1 1", when > the client, the server or at present typically both don't support > RFC 7250. > > > Regarding the explicit nature of having an explicit DH_anon signal, I > > tend to think that (on balance) removing this signal does more good > > than harm. I expect certain others to disagree, of course, but we can > > talk about why a vigorous defense of the cipher suite signal isn't a > > good use of their energy later. > > The signal has pros and cons. Absent channel-binding at the next > layer up, it makes it clear to adversaries that active attacks are > "safe". On the other hand, it allows servers to detect that a > client is not planning to authenticate the server, which has forensic > value, and can be used to grant appropriately restricted access. > > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. > How does anon-DH have different privacy properties than doing RFC 7250 with a fresh signing key for each connection? -Ekr --089e011771a96f7662051e635f01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> This seems fine to me, though I'll note that 7250 only really save= s
> you space when it comes down to it.=C2=A0 You can wrap your raw public= key
> in a certificate, just like we do in WebRTC, and then you don't ne= ed
> 7250 support in your library.=C2=A0 Noting you can only do any of thes= e
> variations in a context where there is some preexisting understand
> that what you choose to use is acceptable to the other side.

Indeed that's effectively what you get with DANE TLSA "3 1 = 1", when
the client, the server or at present typically both don't support
RFC 7250.

> Regarding the explicit nature of having an explicit DH_anon signal, I<= br> > tend to think that (on balance) removing this signal does more good > than harm.=C2=A0 I expect certain others to disagree, of course, but w= e can
> talk about why a vigorous defense of the cipher suite signal isn't= a
> good use of their energy later.

The signal has pros and cons.=C2=A0 Absent channel-binding at the ne= xt
layer up, it makes it clear to adversaries that active attacks are
"safe".=C2=A0 On the other hand, it allows servers to detect that= a
client is not planning to authenticate the server, which has forensic
value, and can be used to grant appropriately restricted access.

Furthermore, anon-DH has strong privacy properties, the server
sends no identity information, not even a public key.=C2=A0 Any
channel-binding at the next layer is privacy protected.

How does anon-DH have different privacy properties than do= ing
RFC 7250 with a fresh signing key for each connection?
<= div>
-Ekr
--089e011771a96f7662051e635f01-- From nobody Fri Aug 28 11:44:27 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911D1B29DE for ; Fri, 28 Aug 2015 11:44: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 iiVduTC42eRp for ; Fri, 28 Aug 2015 11:44:25 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737161B2A36 for ; Fri, 28 Aug 2015 11:44:23 -0700 (PDT) Received: by ykek5 with SMTP id k5so10466102yke.3 for ; Fri, 28 Aug 2015 11:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s+b65pNMsS04pwG7lmrQaNbeJiPQwrupio3IPijiv6I=; b=P5RXQWSuKGqpADb1Cr70y8pmaHEcGnp98TpA4gs1HscWUe278TMtw39EuMhuFRHbqW IB58dJ2VCbRz4FZ1rmg4hDZ3Mhe202oQ82FgPbxiMKAq/f0cVO9Hi75yFSzysGJ2B5av sKAGeVNFT9m72MjMeh5GeVBjTH13LVauGDifNETCvNfMt/0u0ybqQ/A6KFpWTEuArIRG sCzeigGlQdPclsKxcl4mYhTfCKEZsESFOZ1bmYaRwhEJUhguroxYOijZiwkCJ+3k+1dC 24Y+gbsDJvdH5MXeP3I4InRjTtu3D9MXsCIHmjFoQfTe7nHmG8NsoK4Z9TjmCMyrKj39 hA9Q== MIME-Version: 1.0 X-Received: by 10.13.213.197 with SMTP id x188mr9976863ywd.64.1440787462923; Fri, 28 Aug 2015 11:44:22 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Fri, 28 Aug 2015 11:44:22 -0700 (PDT) In-Reply-To: References: <20150828183317.GO9021@mournblade.imrryr.org> Date: Fri, 28 Aug 2015 11:44:22 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:44:26 -0000 On 28 August 2015 at 11:36, Eric Rescorla wrote: > How does anon-DH have different privacy properties than doing > RFC 7250 with a fresh signing key for each connection? Or what we do in WebRTC, which uses a certificate that has no good information in it? From nobody Fri Aug 28 11:47:09 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FE61A00B2 for ; Fri, 28 Aug 2015 11:47: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 7PwTdJvt5f2q for ; Fri, 28 Aug 2015 11:47:06 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841231B2BAD for ; Fri, 28 Aug 2015 11:47:06 -0700 (PDT) Received: by ykay144 with SMTP id y144so9074400yka.2 for ; Fri, 28 Aug 2015 11:47: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 :content-type; bh=FsoNSRKxuNaHkes51n2gTjP4DF0MaQ5/BpgekHPtL7A=; b=QwxC06bTzif2wPomGlqwP013UyAWT85hui6R9gXjPReTc3q7RzWxxB/mb8u8kVxIWI ZYdouZjWKn5jhPfgtp1hb0hAimpvDwF0DO/hh+RKl0d9YIpT9aH15qqNeQFrxZmF3DRg DTANrcNDzhrREyp2P9fATnkUWPD2Ax/EsHYmQXPPs4SG0V/NEtKLuflmcUCGQwU6ldfd 5/YtuiDO0cH420Z3upy4KgJPyUaQz7JjNoSZi0owJVbuMQPdJkvHxZ4j+G0yzZ0gyONK tBnXpvdX1HiPeDaz9pfKf1X2Or6vNdwkJDMwodso4bgXOqeYi3PaK8lWpc8AfWTpY/g0 1ERg== MIME-Version: 1.0 X-Received: by 10.13.225.66 with SMTP id k63mr10509628ywe.148.1440787625695; Fri, 28 Aug 2015 11:47:05 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Fri, 28 Aug 2015 11:47:05 -0700 (PDT) In-Reply-To: <20150828183317.GO9021@mournblade.imrryr.org> References: <20150828183317.GO9021@mournblade.imrryr.org> Date: Fri, 28 Aug 2015 11:47:05 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:47:08 -0000 On 28 August 2015 at 11:33, Viktor Dukhovni wrote: > On the other hand, it allows servers to detect that a > client is not planning to authenticate the server, which has forensic > value, and can be used to grant appropriately restricted access. I think that these are potentially useful properties, but I don't think that we need to use the cipher suite signaling to get that information. What if you could (for example) include a signal at the application layer "oh, by the way, I didn't authenticate you". Or you could have an extension that said up front that you don't intend to check. Those are superior in the sense that it allows for all the benefits of ekr's proposal, without losing the properties you care about. From nobody Fri Aug 28 12:17:49 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7421A1EEC for ; Fri, 28 Aug 2015 12:17:44 -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, 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 dP5rvz4vxU7A for ; Fri, 28 Aug 2015 12:17:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324411A1B4C for ; Fri, 28 Aug 2015 12:17:42 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.256.15; Fri, 28 Aug 2015 19:17:39 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0256.013; Fri, 28 Aug 2015 19:17:39 +0000 From: "Dang, Quynh" To: "ekr@rtfm.com" , "tls@ietf.org" Thread-Topic: DSA support in TLS 1.3. Thread-Index: AQHQ4cVbMAx36sLx1k+2fYH++EoGOw== Date: Fri, 28 Aug 2015 19:17:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.223.51] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:4z1hsljOdNK17ODeHYsyk+dcwjTbkv5HFkip6Hw9SXJ3DdHQ3S5EwJThe3GKyCudxwDKZIdaIqMJLDbvJrUqHDnLV68/nMt6UoDkOiFLSkZlAGpeykRy5iMsedHNm7dk7/fkaajjd02BhOOFdgoSVg==; 24:MS8F5m8jGmJH+p9/Sft408eT3T8MIfLiDW+4msFuyFFAUGAJGESoym4nd8CWgqSVtPk/Go32fC2bRFj8lCQIOEQNEAwhZcmTGTpl9qzEzlM=; 20:M5X7jpc0STpKL5mCgra935HODbPnz+fqhA6ciQZNtP8D49bvKApmgzGuLAGTSRRQRwWMBtn/WhQML9g2cISsEw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0682FC00E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(53754006)(199003)(66066001)(50986999)(86362001)(107886002)(5001960100002)(74316001)(189998001)(19627405001)(2656002)(68736005)(101416001)(5003600100002)(122556002)(62966003)(64706001)(106116001)(16236675004)(5004730100002)(40100003)(99286002)(76576001)(106356001)(2501003)(77156002)(105586002)(5007970100001)(229853001)(19625215002)(4001540100001)(5001770100001)(10400500002)(33656002)(102836002)(5001830100001)(5001860100001)(81156007)(92566002)(2900100001)(54356999)(46102003)(87936001)(77096005)(97736004)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB124C4A9CEF8EAA293190CD8F36E0BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2015 19:17:39.1204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:17:44 -0000 --_000_BN1PR09MB124C4A9CEF8EAA293190CD8F36E0BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, DSA is supported in the previous versions of TLS. It would be nice if someo= ne who uses DSA can use it in TLS 1.3 as well. People who don't use DSA, then they don't use DSA. People who use DSA right= , it should be fine for them to use DSA. I don't see a convincing reason to remove support of DSA in TLS 1.3. Quynh. --_000_BN1PR09MB124C4A9CEF8EAA293190CD8F36E0BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, 


DSA is supported in the previous versions of TLS. It would be nice if so= meone who uses DSA can use it in TLS 1.3 as well. 


People who don't use DSA, then they don't use DSA. People who use DSA ri= ght, it should be fine for them to use DSA.


I don't see a convincing reason to remove support of DSA in TLS 1.3.


Quynh. 

--_000_BN1PR09MB124C4A9CEF8EAA293190CD8F36E0BN1PR09MB124namprd_-- From nobody Fri Aug 28 12:21:26 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B831A88F1 for ; Fri, 28 Aug 2015 12:21:24 -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 hRQhhzlYHe44 for ; Fri, 28 Aug 2015 12:21:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549CD1A8829 for ; Fri, 28 Aug 2015 12:21:18 -0700 (PDT) Received: from BL2FFO11OLC005.protection.gbl (10.173.160.32) by BL2FFO11HUB014.protection.gbl (10.173.160.106) with Microsoft SMTP Server (TLS) id 15.1.256.10; Fri, 28 Aug 2015 19:21:15 +0000 Authentication-Results: spf=pass (sender IP is 198.105.204.3) smtp.mailfrom=five9.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=five9.com; Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.3 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.3; helo=mx02.five9.com; Received: from mx02.five9.com (198.105.204.3) by BL2FFO11OLC005.mail.protection.outlook.com (10.173.160.91) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Fri, 28 Aug 2015 19:21:15 +0000 Received: from MB01.five9.com (10.7.8.141) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 28 Aug 2015 12:20:38 -0700 Received: from MB03.five9.com ([fe80::4d18:3a9c:2936:eea8]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 12:21:13 -0700 From: Ronald del Rosario To: Martin Thomson , Eric Rescorla Thread-Topic: [TLS] Deprecate DH_anon in favor of raw public keys? Thread-Index: AQHQ4bgEnVdiH18dHE2FSZagVw5KAJ4iKpYAgAAHVYCAAADsgIAAAi0A//+U84A= Date: Fri, 28 Aug 2015 19:21:12 +0000 Message-ID: References: <20150828183317.GO9021@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [10.7.8.130] Content-Type: multipart/alternative; boundary="_000_D206012B27774rrosariofive9com_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC005; 1:xGG6zB4LUJWzK6conl3I/GMo030trQb7ukPFrqaKTeKBizsdi6cTyDFA9xsYRtyooPXamZnyHSM+sjC0zdqr14ixUrlgAqhJkk0o/eKF1Ey6WhdePXQ5EDDu+jhozmuegWWSGTmYtAdyCGDNYUyQ3bo8CwNRwiOEJx683Zuhjw+z6iE0VTA8f99H+6nOjZAdzhri5yCD+yZVKmOWg4QPCKET6AnpzuJJaPCWuS6Ehw5uD7GS+Rawqu7Q60RDCRa6HNiZy+Ghcz3JPXQ+AcKtZc6McNTZHhZZYrmEHW7sf4zg3GHfvN452USoxmK2KNMusXBTuQWQsJX7CilMKCT6tUWMcaVZjjkLgDH0ENM+xcUgMP1IFHxpb2+mlnoXyDai6MDz/nCvXEVspuLXRxS61Q== X-Forefront-Antispam-Report: CIP:198.105.204.3; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(3050300001)(199003)(377454003)(189002)(5890100001)(5250100002)(84326002)(77156002)(62966003)(106116001)(5001770100001)(36756003)(5001830100001)(5001860100001)(102836002)(4001350100001)(512944002)(5007970100001)(106466001)(53416004)(2900100001)(2656002)(4546004)(19580395003)(92566002)(6806004)(2950100001)(19580405001)(93886004)(189998001)(30436002)(5003600100002)(50986999)(4001540100001)(76176999)(5001970100001)(16236675004)(64706001)(5004730100002)(54356999)(86362001)(87936001)(83506001)(46102003)(7099028)(85436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB014; H:mx02.five9.com; FPR:; SPF:Pass; PTR:mx02.five9.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB014; 2:dtJxonaEbVmntdBrSjGWu9VWe5MDw0BafzRpQaWq6kHa7+Odwd6q8znFzrssIFyAQqetoBfCbBTkVkO6UzNPrgn/cSnIE546Z9zQijEPXKsWzG5ZPZIBCXOCSjYoyGpzilHc4H/cjTibfqruBGE2mgupVhLwAe73yBSY3VQni2I=; 3:WgA/U2uwNFDF8MPBwnBR1SCCqnU7NOBMBAtZbh0VL1zAdlr+vcol4YINZDlRAAtYu6g3Zkw/G7ZqRNLDrelaNKD8SLoznEamahn0OhIN8MFMtqvblIHLv6XK+mV4MULPSCDAd1mo47QbQMFQmY1BBjYbpr+VwTCZJx97nL9Xd4K9aDSCnGjDC8bmJcKRw3rNlZTLFPi4PYucEbzK70TXahXmYXI/L89lZsSfUyK+eBoTmoW19pih7EYhscVHyTdWPuHPdxQGFLV7IrTzOOmdEg==; 25:rrzPCuAWGMzzUHL6IWaHTmj5GehJwGL3lHk1WXHKleKVAebPfMH9Btm2OiVkxNarxpBJsoSO3eekTLUXs674+0SDAjWgOml0xH3r4TJEyOmprn00VZ87JI55GZsKHlYmWOw3D8Cr3CB/N1LYHa8iJ0zDmnncgSNhCh/j8GmCnQlUgf+3mt+Nmfrf2xfesrdEycDOXnWPNLcgOyu6NIiJw66oKOpQWcbrJV3CtUPjHWK1mbDmC8Pw5w0J2JEBeFsoloWQgAigATR/j7bcsejA4w== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BL2FFO11HUB014; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB014; 20:EWgRstw5DH7MFaeGy2qYdZxkZRbZ8327UhskE3H9LL7czgdSXD+RCCrMFTyozpyinLqEAvA4MMGYEr5eKtQzYUMSu13qeBfUya80nFlUTgK4TAbzGrkvzH6Xtw5bYV/TKsaClVI+QmcDO5yZoONK9fX9NYJau2iIllsDd1x+ikfIOlcZ+4zuq/VWMydmoqkQeIpPCVXv8IauSOJbRdMhfhMESKPBMwAqXXwPWw/zctxel5Gn5JfNgcL6VFSL9KQ317DZlZA8oI5BfQ05FoIvK49Pow4vdYLaXOOWcJtY/D4zHx3dDbmRTgBqxeeUHLjRpjJxL9GQj0RZ+10tmaX10+uDUzUhLBCfEmTsX/1HqVx4ExYpCK0s8GLvh9XmcqSMk5S8ILK+C+TBhEgm29498S3M9G0eTDqZvw6ReIbMDKTueZncRgrAVlyTTTACJ2p42B7cLuSJ/XbKcgmbVML2wyE2B7tl6Qkv6zdm/YOUf81EIFpbnXA53MGJlOYYMH+R; 4:Zie2BU8E6Z8uh2kSIUfHup/kO/nH8KTLwrToUB+pHE8uSV8UqhpVB3QFo97MLWNhrP38BBZdMCXJkAwk6ttQcAV6LtVtM351KULTCKaDCwaFSpD6MA78Mm9ejYd/yw0FU3lVV4Jh4aRjxBgbQ24cO29dfYCBZdyBnLFSsmELwakZVRXySNuaxSNoLcirbgSom/IHeHDsBG0bP7XgMrz8r/8zfcfok7B+i2fYO9+CE6m2ldxB1+hmXi/ANPIt2Khccwoq1qWLptTaxw5TVQZ6X2Oc1RJ8zIxyiKb9X3Fwg04y0git+m90/5eA6gqOkPpw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BL2FFO11HUB014; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB014; X-Forefront-PRVS: 0682FC00E8 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB014; 23:6zKAXpU/1sEsyoWiMrFGQyqF2u6/DncP40ykOBze?= =?us-ascii?Q?SStPnujQohXqgJH3ryosHwlh854B81H7fXFgiZu6kaEjITtXUCzz9ajQ8iqB?= =?us-ascii?Q?nAO2jAl3Y9i3Wp6QQ3jdRpigmRXTRt6s8S2ItmhM06wgMXwvewj9oxpgT3Gb?= =?us-ascii?Q?Fnx6wRHd75nrWM6/lGzvAVq3pmPx0MI+JYxhIZM00Wxc5d1tne9s3mQW8ZSY?= =?us-ascii?Q?61qmtT+8y7gprGWiU/Uc96I46GXkNZZooqMM99UN/bWxBr527b02ba/xqhf6?= =?us-ascii?Q?IPPbbHw4aPlzjVIhRd7ifVoyFIMHbnbSC2OAnvOyHwhisY2zdzCObTrgkk08?= =?us-ascii?Q?2HBuXLY7Ug6izOpgXJMWsfhOjh4QGAExbwqd0kkVMBCMRifMGCCIAnvZjlQS?= =?us-ascii?Q?nVHdgs8+CY+swqUuMiVVpFgtyz2hmtwYRyDm1U0hWilc21VI2P3vRxzU+knq?= =?us-ascii?Q?Zh0T/vrdDtgFhyYsIqcbc0h80i+8TiHNZxCqa6LcZYAENe3EZSyTiWSKLGyU?= =?us-ascii?Q?TfrR/tcSZ4BpKbNpneNz0HB6kJjAPbkJjXthY3ePSAcaQZejM520rbhorwa/?= =?us-ascii?Q?n5ePWcDao0uPbf6Ug8QqioIozuaM65Sv3NTfXyiX238EMmVUzJGCSw1ohwf2?= =?us-ascii?Q?rmeMe4iTBHy4x94qmWUpN/CLyjS8QjJ2Sb5vsDfjv6bGc2WGfsLeHIndnDdI?= =?us-ascii?Q?aRCcmNJ12XvRaWXH8mYj4yiKrmxRXKgSZtGfM8+t+7h69o5wmqrE534uDWhv?= =?us-ascii?Q?CZ+0vRpUETDza2+uxLLdGNRPyEvX79L6QxkCX6skoZsaF2L4uElz1Ub+ennb?= =?us-ascii?Q?l1aLweGHffOMOnVGefBJQoNeLsHK0RGgUAC8AXu0xbrmOcn1d7mKigjjbygG?= =?us-ascii?Q?KxFWiFxHgtHBe7DHvxuxM7gMaxLgeqfi783TwiSIHZ93WVu+2OAPCwsn5iGV?= =?us-ascii?Q?IedmOlFFXr0yXC2iLcHTEtU+IxojzQ2lnfv67L7lroZqwU6VtvqMrZIqsW4h?= =?us-ascii?Q?scIpiILBumCJpOiTL5hd2t3uRSjVzsPTKJecbH+QEyGo09NJeODjIfPBN7yb?= =?us-ascii?Q?/9WQM/PnweMzdepfUFbUOwfjlZZfrkh9ik1lahUJ94SX/LV6Zoeo+h2nAVyR?= =?us-ascii?Q?SAjUt/JL/vXNjZC8NB5TFCCvnA4QGgwWbvHlkHEczRlviHQnQmkxpQpBW+pn?= =?us-ascii?Q?c5W66MKXfQ0qfayTe/nTUMJvcXiatK/SFQZHfJVy6Sp5FNNYp5DqLcey23zj?= =?us-ascii?Q?ifu8fUXmVvxwfdvG86GTWqhyoIySp2wR0OtLGhNx9GagiWFZMaZ8DLLGayAX?= =?us-ascii?Q?7L4JAYve7zYVgQGg3F5k0xA=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB014; 5:EzK61JwJOuVAM478GcP8s37fkkYoMFHk+upx+wtG0YNlDkkybvmHlyt9kKDqveO0K9cF3nOR36FC7HVpm4BidmQzg1rcKKMx62rrHuELzTjQMgX9pcTzBLtnUnz1UtLIGn5kXIvMkthXwncMosciMg==; 24:uGhUSmVZTJfEcCMBUszveAc7ba+RYw72RAZEXO2nwf3wo17BvMhXKni/da4pb4ikruUeyWMR4bulTMsOJUoE1BZKjSGjsbdJIwEOZKiRoF0= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2015 19:21:15.3517 (UTC) X-MS-Exchange-CrossTenant-Id: 91df0123-f1fa-4e71-852c-e6bdacd1a9a1 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=91df0123-f1fa-4e71-852c-e6bdacd1a9a1; Ip=[198.105.204.3]; Helo=[mx02.five9.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB014 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:21:24 -0000 --_000_D206012B27774rrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Or what we do in WebRTC, which uses a certificate that has no good information in it?=94 +1. Anxiously waiting for response on this, as I am currently helping non-p= rofit groups build a private and secure P2P Messaging System using WebRTC, = which of course utilizes encrypted P2P connection between two browsers (A c= entralized signaling server must be at the middle as a broker for the sessi= ons) The DTLS handshake performed between two WebRTC clients re-lies on self-sig= ned certificates. As a result, the certificates themselves cannot be used t= o authenticate the peer, as there is no explicit chain of trust to verify. Ron From: TLS > on behalf of = Martin Thomson > Date: Friday, August 28, 2015 at 11:44 AM To: Eric Rescorla > Cc: "tls@ietf.org" > Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? Or what we do in WebRTC, which uses a certificate that has no good information in it? ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . --_000_D206012B27774rrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3820CDF922F6BD4F8BDECA9BA3290C89@five9.com> Content-Transfer-Encoding: quoted-printable Real-Time Communication with WebRTC

"Or what we do in WebRTC, which= uses a certificate that has no good

information in it?=94 

+1. Anxiously waiting for respons= e on this, as I am currently helping non-profit groups build a private and = secure P2P Messaging System using WebRTC, which of course utilizes encrypte= d P2P connection between two browsers (A centralized signaling server must be at the middle as a broker for the = sessions)

The = DTLS handshake performed between two WebRTC clients re-lies on self-si= gned certificates. As a result, the certificates themselves cannot be used to authenticate the peer, as there is no explici= t chain of trust to verify.

Ron<= /span>
&nbs= p;

From: TLS <tls-bounces@ietf.org> on behalf of Martin Thomson= <martin.thomson@gmail.com>
Date: Friday, August 28, 2015 at 11= :44 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.= org>
Subject: Re: [TLS] Deprecate DH_ano= n in favor of raw public keys?

Or what we do in WebRTC, which uses a certificate that has no good
information in it?


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are= not the intended recipient, please notify the sender immediately, destroy = the original transmission and its attachments and do not disclose the conte= nts to any other person, use it for any purpose, or store or copy the information in any medium. Copyright= in this e-mail and any attachments belongs to Five9 and/or its affiliated = entities.
--_000_D206012B27774rrosariofive9com_-- From nobody Fri Aug 28 12:49:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FCC1ACD8B for ; Fri, 28 Aug 2015 12:49:28 -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, 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 U-NGxMiUe-aZ for ; Fri, 28 Aug 2015 12:49:26 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1181ACD7F for ; Fri, 28 Aug 2015 12:49:25 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id E37B3900EA; Fri, 28 Aug 2015 22:49:22 +0300 (EEST) Date: Fri, 28 Aug 2015 22:49:22 +0300 From: Ilari Liusvaara To: "Dang, Quynh" Message-ID: <20150828194922.GA30171@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: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:49:28 -0000 On Fri, Aug 28, 2015 at 07:17:39PM +0000, Dang, Quynh wrote: > Hi all, > > DSA is supported in the previous versions of TLS. It would be nice > if someone who uses DSA can use it in TLS 1.3 as well. Well, at least for the web, DSA is no longer an option because major browsers have dropped support for it. > People who don't use DSA, then they don't use DSA. People who use > DSA right, it should be fine for them to use DSA. Unfortunately, it is not just signers, it is also verifiers. > I don't see a convincing reason to remove support of DSA in TLS 1.3. Well, no (projected) use. Many features have been stripped from TLS 1.3 on those grounds only. Also, if DSA was to be supported, one would need to specify how to determine the hash function (use of fixed SHA-1 doesn't fly). And 1024-bit prime is too small. -Ilari From nobody Fri Aug 28 13:06:38 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C8D1B2E52 for ; Fri, 28 Aug 2015 13:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDb_WxBAcEMM for ; Fri, 28 Aug 2015 13:06:36 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.146.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF90F1B2E51 for ; Fri, 28 Aug 2015 13:06:35 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id 966E814969584; Fri, 28 Aug 2015 15:06:35 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 86B3A14969561 for ; Fri, 28 Aug 2015 15:06:35 -0500 (CDT) Received: from [96.231.216.201] (port=59362 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZVPv0-000JX6-Ox; Fri, 28 Aug 2015 15:06:34 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Fri, 28 Aug 2015 16:06:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCCE3AA-2B8F-4B81-893F-4DD7CE6737D2@ieca.com> References: To: "Dang, Quynh" X-Mailer: Apple Mail (2.1878.6) 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.216.201 X-Exim-ID: 1ZVPv0-000JX6-Ox X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.216.201]:59362 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:06:37 -0000 Quynh, You must have been reading my mind because I=92m working on something = that will help Joe and I judge consensus on what to do about DSA. Let=92s hold off on this thread for a bit while I get that msg together. spt On Aug 28, 2015, at 15:17, Dang, Quynh wrote: > Hi all,=20 >=20 > DSA is supported in the previous versions of TLS. It would be nice if = someone who uses DSA can use it in TLS 1.3 as well.=20 >=20 > People who don't use DSA, then they don't use DSA. People who use DSA = right, it should be fine for them to use DSA. >=20 > I don't see a convincing reason to remove support of DSA in TLS 1.3. >=20 > Quynh.=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Aug 28 13:21:50 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B188E1ACF1B for ; Fri, 28 Aug 2015 13:21:49 -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_05=-0.5, 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 aUaVPUSBy3qm for ; Fri, 28 Aug 2015 13:21:47 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A8C1ACEF6 for ; Fri, 28 Aug 2015 13:21:45 -0700 (PDT) Received: from pc1 (p200300596D6E6E95AC5239AFE8F93233.dip0.t-ipconnect.de [2003:59:6d6e:6e95:ac52:39af:e8f9:3233]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 28 Aug 2015 22:21:41 +0200 id 0000000000000046.0000000055E0C2D5.00003A9D Date: Fri, 28 Aug 2015 22:21:53 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150828222153.2a80473e@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-15005-1440793302-0001-2" Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:21:49 -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-15005-1440793302-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 28 Aug 2015 19:17:39 +0000 "Dang, Quynh" wrote: > DSA is supported in the previous versions of TLS. It would be nice if > someone who uses DSA can use it in TLS 1.3 as well. Do you have a plausible reason why you want to use DSA? Or is this purely a theoretical consideration? Because this discussion came up multiple times here and I can't remember anyone having a real world use case for DSA. From net wide scans it seems DSA certs are almost nonexistent. > I don't see a convincing reason to remove support of DSA in TLS 1.3. The reason is avoiding feature bloat. I think it makes a lot of sense to question the support of features nobody uses. Therefore I'm very interested to hear why anybody would want to use DSA. "Just because someone could" isn't a good reason. (Also DSA has a well-known weakness with bad random numbers.) --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-15005-1440793302-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV4MLhAAoJEKWIAHK7tR5C1U0QAKIquRmwTxYXv8Q/NXG3skIO 4Hi9+wBsTzU6Vge0fYYMwFQFzJ8Jpp9pxgbyBt+iy6F/XMkai3EliC7kG6DDQs7K KzjE1ur4nQIKSgJdJpIsYZjYlc3pr9mawHN1e/fPr6a5ORSNm8VcqOKBeJWhAr5f wjPsZ2aeX3yWBxD8AmRe90qgN4f9xHFdLj4i212w0YZLZH2Ix3AWChYp/x56QbTb hVLXvfG8EFNWg3ODG1Zp5fOvPz3i92Rnh7U/Ge9KJKgMMtn8/XhTd/fkHTJD0d3B YK+laSoAIlmrD0LErrOkOwsPBKVScoz5ozeBBXlVPDYz3SL6uXPRDfMkw8sWpA0v eIwA6xlt8Js9uXpE1WDuiwdojRib0s/gMfcceKozX0LDWvAGahe2TymOEvFxYi3d XYH4B8SbHBEjdpLv3kkZcn/w8vPB1G7TCFP2quw4QhCem5W37u5yA/xYez8FLSel xuUTWnNZAfM317XzJI1whr8a/wVhQoBS0aR9h6jzKK8oXaSg8dPscL9BdVP1SnuJ 3NY7xZZg4KFo10DS/2C1snDztBcEOfT8o1jLhfD8v4ru8C+iXDStbRCKQEcXJb8N PmoCUJchhg+1XVH/H6JWR6rlm4GoQLH0U9T2VdH1m+g4bpsyrSU5sOJCSXvxNVSO vx5QlQBgJBgK/bQ5nCEz =N4kK -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-15005-1440793302-0001-2-- From nobody Fri Aug 28 13:28:00 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574871A6EF4 for ; Fri, 28 Aug 2015 13:27: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 W_so1nfvuO6M for ; Fri, 28 Aug 2015 13:27:58 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262041A1A62 for ; Fri, 28 Aug 2015 13:27:58 -0700 (PDT) Received: by oibi18 with SMTP id i18so31291565oib.3 for ; Fri, 28 Aug 2015 13:27: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=UtbuPIItp56kclAX8tzobVGuTWJiDfzl9KPPRFIP+p4=; b=vh2g4SE28/PrRNQ4Ia737PbszU+hp/XywmyaL0qAPLJ/EkAr8Syl25f6xAIZzrgEg3 ltgQgdjKVhbf3E4ulOj8B2Y0LgLQe1gLeu4F+JhGHjg3P1FgP2q4orj93ODb1NS6Ti2e iXNWBRNus2e7lqadbNtnDlHI9qCSe5RBCOL7858D1Ac5/4dyvhlN68LnfAYPUhYR/pyS hjHCBe+zwaEOH1NGC76cP5W8TAJ58Fotp0O04PWNSp1bYz0r2bPD8ZKX5DvOLfcjhrdN h2vmpmHuBDxVxP/D6Y2FXilmSBcH/m5+ZXoiss3SdWuGge2zfJO+2AHVQEcYEdiaYrb4 4UPw== MIME-Version: 1.0 X-Received: by 10.202.227.12 with SMTP id a12mr6572741oih.125.1440793677640; Fri, 28 Aug 2015 13:27:57 -0700 (PDT) Received: by 10.76.156.105 with HTTP; Fri, 28 Aug 2015 13:27:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Aug 2015 13:27:57 -0700 Message-ID: From: Tony Arcieri To: "Dang, Quynh" Content-Type: multipart/alternative; boundary=001a1140940259bd7e051e64eb4b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:27:59 -0000 --001a1140940259bd7e051e64eb4b Content-Type: text/plain; charset=UTF-8 On Friday, August 28, 2015, Dang, Quynh wrote: > > People who don't use DSA, then they don't use DSA. People who use DSA > right, it should be fine for them to use DSA. > Can you name one of these people? If not, you seem to be arguing for including legacy protocols with no real-world use case in mind. In absence of real-world use cases, removing legacy baggage from TLS reduces attack surface and makes things easier for implementers. -- Tony Arcieri --001a1140940259bd7e051e64eb4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, August 28, 2015, Dang, Quynh <quynh.dang@nist.gov> wrote:

People who don't use DSA, then they don't use DSA. People who us= e DSA right, it should be fine for them to use DSA.

Can you name one of these people? If not, you seem to be arguing = for including legacy protocols with no real-world use case in mind.

In absence of real-world use cases, removing legacy bagga= ge from TLS reduces attack surface and makes things easier for implementers= .=C2=A0


--
Tony Arcieri

--001a1140940259bd7e051e64eb4b-- From nobody Fri Aug 28 13:48:23 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6AD1A9092 for ; Fri, 28 Aug 2015 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rNaIxZnQ0dU for ; Fri, 28 Aug 2015 13:48:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8694F1A88BC for ; Fri, 28 Aug 2015 13:48:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A4E60284D24; Fri, 28 Aug 2015 20:48:11 +0000 (UTC) Date: Fri, 28 Aug 2015 20:48:11 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150828204811.GQ9021@mournblade.imrryr.org> 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: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:48:19 -0000 On Fri, Aug 28, 2015 at 01:27:57PM -0700, Tony Arcieri wrote: > On Friday, August 28, 2015, Dang, Quynh wrote: > > > > People who don't use DSA, then they don't use DSA. People who use DSA > > right, it should be fine for them to use DSA. > > > Can you name one of these people? If not, you seem to be arguing for > including legacy protocols with no real-world use case in mind. > > In absence of real-world use cases, removing legacy baggage from TLS > reduces attack surface and makes things easier for implementers. Also *improves* interoperability, because the client HELLO carries fewer cipher-suite code points, helping with systems that are intolerant of large HELLO messages or only process a subset of the indicated ciphers. -- Viktor. From nobody Fri Aug 28 14:00:02 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671541B2C27 for ; Fri, 28 Aug 2015 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1B_fg52IH9K for ; Fri, 28 Aug 2015 13:59:59 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7BC1A870C for ; Fri, 28 Aug 2015 13:59:59 -0700 (PDT) Received: by qgi69 with SMTP id 69so7730380qgi.1 for ; Fri, 28 Aug 2015 13:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=ThicZ1RUNPCKKFt7HLY1WkIm4ZvqDpe9y+hqZ/lNwBE=; b=VB9ecjKR/WeAXe9XV99KKmwglddWvmR7mN41gJpXL5aHG1j1LTWBh03uRAg0GsbQcc W/xLurUQsR0IdDGqAZlbH0jMtUiKuAFiNRQLnNgPaKZWO0TgVMPHhtkOf8tRtoabN1kc C+SFALIiissaLpo7wyrcBaCl0zQe/M8CQZDNQbb6eQYwLPh3nYKWj7odp5msAXRKb4Bj LxrCst+qi0GokaBacrFYgc7AhFoSZ3pKPILw+Izckz5qiifa1dMK3IcNEzrhQN5plbNV a4tWxHAf+vk8IBozPd/SyvEqzlfrpiBFeyEdDc9VYpl+0Z90nHkhi7TK4moZZneOO5du yQyg== X-Received: by 10.140.132.133 with SMTP id 127mr21102260qhe.6.1440795598729; Fri, 28 Aug 2015 13:59:58 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id f9sm4140631qhe.7.2015.08.28.13.59.58 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 13:59:58 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 28 Aug 2015 16:59:56 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150828222153.2a80473e@pc1> In-Reply-To: <20150828222153.2a80473e@pc1> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201508281659.56892.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:00:00 -0000 On Friday, August 28, 2015 04:21:53 pm Hanno B=C3=B6ck wrote: > On Fri, 28 Aug 2015 19:17:39 +0000 > "Dang, Quynh" wrote: > > I don't see a convincing reason to remove support of DSA in TLS 1.3. >=20 > The reason is avoiding feature bloat. I think it makes a lot of sense > to question the support of features nobody uses. At minimum, it's almost certainly getting cut from the TLS 1.3 specificatio= n document. It's obsolete, even by DSS standards, and either needs signific= ant updating (e.g. use SHA-2) or dropping. The question will likely be whet= her it should be considered no longer acceptable or something which is perm= itted, just rarely supported and described in another document. I'd rather = just declare it obsolete and no longer permitted to avoid the attack surfac= e and complexity, and I get an impression that this is a common opinion in = the WG. Dave From nobody Fri Aug 28 14:06:59 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA331B30BC for ; Fri, 28 Aug 2015 14:06:57 -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 VPIs_po2Xxgh for ; Fri, 28 Aug 2015 14:06:56 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEE31B2FC1 for ; Fri, 28 Aug 2015 14:06:56 -0700 (PDT) Received: by oibi18 with SMTP id i18so31803636oib.3 for ; Fri, 28 Aug 2015 14:06: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:from:date:message-id:subject:to :cc:content-type; bh=3A2BsTNqkOFSLB+PszrJbwQYzTwOKSDfUmXF7hCBrto=; b=ZbCZpTq1oPvS5nMYtfCVDqWW4wF0eM+JqUnnamJFmUv/OhfWa2vvbvGf07RSoNFqfX iZnQPQMvn3m/5tjuwKKt1sq242Btj7+El1h7CwfdJTBl5TLNH7TEMQ9GRB7Z6OoRFPvK n0Up0TriPb7LYUcHKBKVlaYIPSoPFn/jkMX/DdFWdCnpbDO0qiaF+Zi4GpW68ZFtFeLp fnU/ussO6dbaR+WYVpbPPy3uvgInEtDbuyvOWtMl+1HaL5+VccGWkay5D1t6iK/AW8T1 dTcv2NohaTg5BUg3QIMsWIeudXb2YQk+N8quit+PxeF3wGjG77x3bLyJvQgqpBBDsu4Y eKvw== X-Received: by 10.202.221.198 with SMTP id u189mr3271688oig.68.1440796015918; Fri, 28 Aug 2015 14:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.156.105 with HTTP; Fri, 28 Aug 2015 14:06:36 -0700 (PDT) In-Reply-To: <201508281659.56892.davemgarrett@gmail.com> References: <20150828222153.2a80473e@pc1> <201508281659.56892.davemgarrett@gmail.com> From: Tony Arcieri Date: Fri, 28 Aug 2015 14:06:36 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d62b8b9061f051e6576b2 Archived-At: Cc: "" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:06:57 -0000 --001a113d62b8b9061f051e6576b2 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 1:59 PM, Dave Garrett wrote: > I'd rather just declare it obsolete and no longer permitted to avoid the > attack surface and complexity, and I get an impression that this is a > common opinion in the WG. +1. Most people seem to oppose its inclusion, and the people asking for it to be retained do not seem to have real-world use cases. -- Tony Arcieri --001a113d62b8b9061f051e6576b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 28, 2015 at 1:59 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:
I'd rather just de= clare it obsolete and no longer permitted to avoid the attack surface and c= omplexity, and I get an impression that this is a common opinion in the WG.=

+1. Most people seem to oppose its inclusi= on, and the people asking for it to be retained do not seem to have real-wo= rld use cases.=C2=A0

--
Tony Arcieri
--001a113d62b8b9061f051e6576b2-- From nobody Fri Aug 28 17:41:29 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA81B3756 for ; Fri, 28 Aug 2015 17:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl9YYzTtDi6R for ; Fri, 28 Aug 2015 17:41:26 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0035F1B374F for ; Fri, 28 Aug 2015 17:41:25 -0700 (PDT) Received: by wiae7 with SMTP id e7so11160604wia.0 for ; Fri, 28 Aug 2015 17:41:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ybhgFZ8NPmx23/qPQvSSRNbqzoRogl1oyuP/0UAryRQ=; b=g1DK4rrpnA7Zv5jULysE2DnnAARSrrbkaI8+Y2lif6RgjLnTg/0+vYNJ2ratBbq+gs pZidb3aDP0Lfzd8UI0w+8NT2bfzoj2rs4bSRUbXtNie+UtuEwJ55uZTgfOZJdtZHh36b Lewa1Ja0eLlH6inPCmijT7pAzjJQ7VgLYsxf4IctxyEt97fUYcgFa/U5kPESXVru6jIR 8UF2gPkqNSAVpeGbb4FjBz04giUJSNrRpEEsFYsg22okFYgRHjUYyBKnErIWEm+U5ZZg q8gfYRmXLP6gzqUn3QimlrByNxghdBFM966dCRh79w9TdMshIAGgf+Vo5Lrx5HrsGif3 CTaw== X-Gm-Message-State: ALoCoQnjPT6K1LOOxeczCOvxV0EiChQ+YR8BjqFdS4Gpnbicj/j0UIWpeFStBK6347K4eNcaNTn9 MIME-Version: 1.0 X-Received: by 10.194.78.164 with SMTP id c4mr13418177wjx.65.1440808884389; Fri, 28 Aug 2015 17:41:24 -0700 (PDT) Received: by 10.28.41.133 with HTTP; Fri, 28 Aug 2015 17:41:23 -0700 (PDT) X-Originating-IP: [176.10.104.240] In-Reply-To: References: Date: Sat, 29 Aug 2015 00:41:23 +0000 Message-ID: From: Jacob Appelbaum To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 00:41:27 -0000 On 8/28/15, Dang, Quynh wrote: > Hi all, > > > DSA is supported in the previous versions of TLS. It would be nice if > someone who uses DSA can use it in TLS 1.3 as well. > > > People who don't use DSA, then they don't use DSA. People who use DSA right, > it should be fine for them to use DSA. > > > I don't see a convincing reason to remove support of DSA in TLS 1.3. > What do you suggest for the construction of the k value in DSA? The old NSA backdoor that leaks the private key? Or perhaps a different NIST endorsed construction? All the best, Jacob From nobody Fri Aug 28 18:41:52 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE41B3992 for ; Fri, 28 Aug 2015 18:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7HT1TDttmH2 for ; Fri, 28 Aug 2015 18:41:49 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89621B398D for ; Fri, 28 Aug 2015 18:41:49 -0700 (PDT) Received: by qgj62 with SMTP id 62so39477296qgj.2 for ; Fri, 28 Aug 2015 18:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=6KZDMbBt5srKKMIpYUxXAZM9OfJ1O/7K0FzOSL7UIjE=; b=xTIywFhmgjjGUPTRQPNNhHUZbmdfdsuz4vrdfRRYPnkRuHOa2MSyyX7iggycP21R3l WiogZ5RO9mPAm0CGNN9y4LgZVObSgf5ujObeh4yDsR3tvMrazAHXFDDN6fmI0FT39P+o CEMpCxNTji6QMuoPgGUpd22XpyxCesQnAOxSgz5/cVI8CdTEfnk29TCSqOaGA+a/A60g gkKjdpx6dLnsYFJEmrnPdJQkFHMkirV4HCN6bNbpAwc7vkNYQi5eSEo4q6l0Ua8+AfwD 0QWA4VVCUijfwsg81c+Q26NTzHbXJ4C4kcBO2zUmanneH68qrHrdF+FepsxuIx866XMA ZqFQ== X-Received: by 10.140.144.83 with SMTP id 80mr21376805qhq.54.1440812508977; Fri, 28 Aug 2015 18:41:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 68sm4511495qhf.37.2015.08.28.18.41.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 28 Aug 2015 18:41:48 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 28 Aug 2015 21:41:46 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201508282141.47112.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 01:41:51 -0000 On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote: > What do you suggest for the construction of the k value in DSA? https://tools.ietf.org/html/rfc6979#section-3.2 ? Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite this RFC? Dave From nobody Fri Aug 28 18:48:01 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1291B2B1E for ; Fri, 28 Aug 2015 18:47:58 -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 l4gXE_3w1aGn for ; Fri, 28 Aug 2015 18:47:57 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112081B2A9C for ; Fri, 28 Aug 2015 18:47:57 -0700 (PDT) Received: by ioej130 with SMTP id j130so28912680ioe.3 for ; Fri, 28 Aug 2015 18:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E/GjvQKhOm/O1Cci6z4SeeVfNW0MMSdE8TFpQnEMB6A=; b=yRK9xpyIGaMKyXNthNQc6LqZHXrZx8I/Qytw8u7wBiSEsXv+2DDAiuO9ujBqmlehlL PojjAGskeFJ51pIbT+aE84r51WWliKpLbi8m9plQ4kzrQ+JNCIcZdtvNP3koDHkBXheG RjY571ry9C44ilD5eezd5InPl50fN34q7hKC58lUp0h05p73rItJxXCe9gRWxTYUBGMq Dx8TWL4zIgjKPQMJooGCD2quTPWwQz3vPTPejS0EAJKgECcEO0NbkUgWdCltXlpu94nz b/5k0Z1OQlvIVnLm7UCFJsBbF81pxzc2JKJSE7h2GZu752madGO8EuolVUenSz0jT0fi gcvQ== MIME-Version: 1.0 X-Received: by 10.107.135.140 with SMTP id r12mr16597374ioi.153.1440812876611; Fri, 28 Aug 2015 18:47:56 -0700 (PDT) Received: by 10.36.123.215 with HTTP; Fri, 28 Aug 2015 18:47:56 -0700 (PDT) In-Reply-To: <20150828194922.GA30171@LK-Perkele-VII> References: <20150828194922.GA30171@LK-Perkele-VII> Date: Fri, 28 Aug 2015 21:47:56 -0400 Message-ID: From: Jeffrey Walton To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 01:47:58 -0000 > > Also, if DSA was to be supported, one would need to specify how to > determine the hash function (use of fixed SHA-1 doesn't fly). And > 1024-bit prime is too small. > FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) partially remediates the issue. DSA now includes 2048 and 3072 sizes. Jeff From nobody Fri Aug 28 20:17:16 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 024D31A8A75 for ; Fri, 28 Aug 2015 20:17:15 -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_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMb_HHPojZ4Z for ; Fri, 28 Aug 2015 20:17:13 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021EF1A1C02 for ; Fri, 28 Aug 2015 20:17:13 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id F0E9833D206; Sat, 29 Aug 2015 03:17:11 +0000 (UTC) Sender: geoffk@localhost.localdomain To: noloader@gmail.com References: <20150828194922.GA30171@LK-Perkele-VII> From: Geoffrey Keating Date: 28 Aug 2015 20:17:11 -0700 In-Reply-To: Message-ID: Lines: 17 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: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 03:17:15 -0000 Jeffrey Walton writes: > > > > Also, if DSA was to be supported, one would need to specify how to > > determine the hash function (use of fixed SHA-1 doesn't fly). And > > 1024-bit prime is too small. > > > FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) > partially remediates the issue. DSA now includes 2048 and 3072 sizes. This is true, but if TLS 1.3 was to specify DSA, it should require the 2048 or 3072 sizes (since 1024 is last century's crypto), and existing implementations do not necessarily support those today. Which really highlights the question: who would actually use it? ECDSA can be smaller, faster, and more secure all at once; and if you don't like ECDSA or want an alternative, there's RSA. From nobody Fri Aug 28 21:20:07 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3F81B380D for ; Fri, 28 Aug 2015 21:20:06 -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 pbFClimrjauz for ; Fri, 28 Aug 2015 21:20:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657141B380C for ; Fri, 28 Aug 2015 21:20:04 -0700 (PDT) Received: from BN1BFFO11FD040.protection.gbl (10.58.144.34) by BN1BFFO11HUB032.protection.gbl (10.58.144.179) with Microsoft SMTP Server (TLS) id 15.1.249.14; Sat, 29 Aug 2015 04:20:03 +0000 Authentication-Results: spf=pass (sender IP is 198.105.204.2) smtp.mailfrom=five9.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=five9.com; Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.2 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.2; helo=mx01.five9.com; Received: from mx01.five9.com (198.105.204.2) by BN1BFFO11FD040.mail.protection.outlook.com (10.58.144.103) with Microsoft SMTP Server (TLS) id 15.1.256.10 via Frontend Transport; Sat, 29 Aug 2015 04:20:02 +0000 Received: from MB01.five9.com (10.7.8.141) by mx01.five9.com (10.7.15.111) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 28 Aug 2015 21:19:20 -0700 Received: from MB03.five9.com ([fe80::4d18:3a9c:2936:eea8]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 21:20:00 -0700 From: Ronald del Rosario To: Geoffrey Keating Thread-Topic: [TLS] DSA support in TLS 1.3. Thread-Index: AQHQ4cVbMAx36sLx1k+2fYH++EoGO54iRxMAgABkLgCAABjwgP//nDSC Date: Sat, 29 Aug 2015 04:20:00 +0000 Message-ID: References: <20150828194922.GA30171@LK-Perkele-VII> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD040; 1:F5zFSHtjJm+t7zC99Ez0FAQyPIdfu3LZ8Jr4nq7fpF8UG8ATasJ1zYbLi7twOogslhHlFaxj6DaE6P7cVPZAhJMTFMxMrCNjTXU/zNiREy6Ok/FUH+GK+qpcAq0Af6oIdxB05usjDiqXmT9vMBcJceycSSQDP7O2ZS6Yhl1u5eJUEoCKjkoEZF5K/+vSfSiX9VRMsb4sXrqbyECbrmCfWu+3xQXijUVKXlai+6TVJ+YAYR8I8gB5zby2Dj6D+TdNb0Fz+bJXDMReq/62xULNKIGwscVYOtv669sgdV7OqkjdVAjF2JGsigOogDs+ye4+kG1dd6W9CAi/kKtSmJdi9uytZqzNeUuPv67xxQJLhHdYawql/r42nZEIlTXf7jGwZqeUo9lOae8NhHLM/jxLPQ== X-Forefront-Antispam-Report: CIP:198.105.204.2; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(3050300001)(199003)(189002)(2656002)(97756001)(87936001)(82746002)(83716003)(86362001)(23726002)(6806004)(53416004)(5007970100001)(62966003)(77156002)(64706001)(106466001)(102836002)(47776003)(106116001)(2950100001)(92566002)(5250100002)(5890100001)(54356999)(50466002)(4001540100001)(46102003)(5001830100001)(5001860100001)(2900100001)(76176999)(5003600100002)(36756003)(93886004)(46406003)(50986999)(110136002)(189998001)(5001920100001)(33656002)(5001970100001)(7099028)(85436002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB032; H:mx01.five9.com; FPR:; SPF:Pass; PTR:mx01.five9.com; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB032; 2:cTZKN9bMh0tLRDtAIgc44AXEaeeLwm46Jw2t1P0xFD9692z6Pxzw1/hxToWbvgFPGi4xnjlAnBWsPjRto5dYPJnkMUxIUAt45mj2XoIs7WGal5WeuvpAA9oBf1clKSNGctnosniEUOpL02RwcCh8QznSN83FBSzZat5khKU/qak=; 3:36ZLNLPa66gmq00Qvrp08NR8hcyeI5HrZfkiRmhEJ27PrZsmpKqRgtPQTgWsN8/20ELod9KwQYRxhVsSMqIsC1QvpZEUt6uOdyqXRWuC3bRAZ2J9z414JfvpD64cMeYieMg7sGk4jZ+l5w/jkqomhxCfbB4SNNf9yDGwlT6l58xtwCYp+Kk3BAs0IxM3P3EMnMko5tPc6Zrg3jVCCCA1wd37RbxmRFZI28u7OjSdZslN1EB6oYnD+OQUhKaYFXMsYVScdGWbbwpS3atv1/JAhg==; 25:k1UoFwilRFaJOOnUlduQ9ytVwJObgF8HMkDoSdlCeccHYxUdJzZ0nz2H1U6S5YPrn+CB4taXVggo7YDX4yCN/Nn9yES/lBcWkpqo5kVUstz7xxXFJB7ko0vHJ+TkQaHChlT4Dy34EfjWtKXVi9AZmlziwCRX6dvVJoGiyBkcpC5LQIU1fK/nhJhGzvroc/fZfDvFSj8cUNsmnhaRNL1rnRWSXW/9EszpZ6vGIu1tnnLK9outs0fQM12s72tRQqYo X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BN1BFFO11HUB032; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB032; 20:Ri9CB70rNKLNNncPPk9T9ixOUu58kurxdoboteGDKrVEDg8wUMYQ9alRyvRZmgrzWhn2YbyFlBmSzXJhcNWyGxVcOjXvq1LGjbweYkGQCJn0Mh1BfRP+MewktskuEkfuVoxofyo5py4Khe1dijFLjUlv/Nzca9lv1eUuCsT+I9YmyVjzqFAO+M76zQsw9S2GWFCdRA8tOptVq3oPszUcOPIfy/yeu3A0jpcIm8DXkPPlorTIqwhZNuFSm1vKEOwjTYHc+6ViHScqSJkrGtbOgMevYa20xK6tYt/iyOUPkbDs+TUXcT/0PwLIfSj7wwEp1w0zGgIcFxr1RaktgfTs3xfdoFJGNnCqRDew2Kb/m9dJ6oiLKUInj19RSrMCNznQgJOHqpFmBnQTYmq51Ry4sgbhbGT1lDa+lZA3bfgzC9TrdnF66hLloW6zUYavmisfGpCsDK5+d3FKl3OrGlvNTnhGPwsseli+la2O6nYGVNZKWasWbd7Yywdbt3BqMUW3; 4:DZPQFFzflUzbJAM0qhQ2OUqM5vYhorzg+Y+lDKkc9mQTnKl+oOMLmZjSfhKsqg92Bt1IWgXrYrg40Lrzhs5gt4cYBoiEpZ7brFkyAIvYv14R32setyOajYOeaeKubHFUWtgXyPrpSUCixzt462gGJ+pK7wv/scQZ+epHu5kvep6ok+R112BDrmBaiCceHhDojbf12tiDv1WLCvu4mW19cavqCeSVOsWGrUBIpNdjEKsglDzKhdvMmleeJNeF68ZNuh53nls2urgQG9+nE9k14byDi3OAfxdrwX5kqZEIXtCaozP4Gqfm8KmV1h8KatnT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN1BFFO11HUB032; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB032; X-Forefront-PRVS: 06833C6A67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1BFFO11HUB032; 23:c3DvFdP33xxE2pVPT7vziHvvXJL8T7JtlO1lKGL?= =?us-ascii?Q?I2Aug+ppXpV0n3lQs/YDHUoJB2Hum0cIwD22v1kjhdRl4cudFjh5rNqI27zr?= =?us-ascii?Q?2Tn9uPWXrse0VuCgz1zTvFWtDSwmtdgaUcMVZqdsjWx1XF05EkbcKddCs0wy?= =?us-ascii?Q?oect4EyqMQGq3cQJJOAJHLvOpDwml4gDx/617rWuvFBt99lUsaXcpneBqXt9?= =?us-ascii?Q?hJH/rYJcv5AFsSOs119jRGH15KJ629gDEXtrJr0s0kW5m4VLhiT7/zdV4NWf?= =?us-ascii?Q?kcXtjapLIVlUaEFhDojDpaDO7uwzMLn0EU/BpwuntAmFEAEwX8PgePpDqHfc?= =?us-ascii?Q?CszcToNgh/yMOsca+HnktOxhwAHif6QTeHKaNrpkdc+HueKSFEabGh5YmEh/?= =?us-ascii?Q?6Itputeb5XmKZ/YXytwzG7gbbyE8FnX2JqWxuxyhpt8+iy3EiFh84qCQAK2H?= =?us-ascii?Q?PomohF4Y234MaFsHRl64z2gIVMO9XlKx645fAOY7LZwM/wJ8G7COlJbP7/Ft?= =?us-ascii?Q?YDupzCMt2E4GDAamaoKrA92LudQSZ/Db8jbNk5UUR9AMeRsLcfxRnX9LQn09?= =?us-ascii?Q?91+p0g88uyLSaSYIjsCeCi8Wfo/WcyiJ3ml+Qnm3NMninXdsajyaxvPwkgR7?= =?us-ascii?Q?ti4lwzMYPrfQzMf/QS+n8XdqmPnj8ZBCle8duXbHalM3XXsmXGEJsw98SfFL?= =?us-ascii?Q?MIO/2Lx1WBycvxfPNdQueDjf556dbGhn+c7IhLY29JYUW4+RYBZ0TKRaGmKR?= =?us-ascii?Q?XVc8dgDXAHgbYG4ELlpXfU9P8Qm90KqjrqLLfS9/6BjCrFAgxnyOGMDn/xdF?= =?us-ascii?Q?uME/Uiy6XPtgOWh5d2d5aW2ED4BV1uhohXBiRXLpcN3DmAOMzQPluMOgvwMg?= =?us-ascii?Q?qfSSN/9sRKHqMveX9LD5KQTXrbRQOkTbESQHME3fziPH4mVmXHco68KBt31f?= =?us-ascii?Q?anxGA+bsNCOMFw6lla+qNugj6bK3H4YU/GtcxJ4nFKHSamrSnCTmzwPXaPsd?= =?us-ascii?Q?gDk4q2X7SkA37FTQGw92RdRQWEWm1962o0fepWlFlzMTxO8U1ixhv04VatFL?= =?us-ascii?Q?VlWPJLiFSfmYkT3OWaNkmfCrqYH/l3hgu00Ra2qAvzT+P2zED1aWPfB+8rGN?= =?us-ascii?Q?zS1SusIQtd8v9ApSNLWFkTJeIFclz+w3olqPxmslsPHzpFes/hhWQpsXLz1e?= =?us-ascii?Q?tw409UZjauvgoj9jM10iFi/z3eMZlvUIFl+Z7cKHQzRqjbLdhEXK8KX4IxgA?= =?us-ascii?Q?yWzzrDj3QA4YhSfY4sno7MmsKXov05/kuyX5y05VQ?= X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11HUB032; 5:t90gf7fXo3gHmqKuOloJO9qWCULlazwcv3mYIkwLBDfATzM2Ve7Yzqy4yrCsbp3cfm0TsiPcpVX6yEWH45WspQyoQParCcXSnNNphfMdQ/KrqJZFhzvDaYe3uH9qMDuxUV/yRrtpgF4RA0dpAWCWMw==; 24:TIfU1SLR9h9YSUX7hmaosxhJQ3En24sP8JJvIeG2g/uO5ejMlosTpXX5rS9Jz1WMpCYrj3fAPUDZuc7pXYNnV4TOKaNNCnKmhTQo2Dy7XoM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2015 04:20:02.6097 (UTC) X-MS-Exchange-CrossTenant-Id: 91df0123-f1fa-4e71-852c-e6bdacd1a9a1 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=91df0123-f1fa-4e71-852c-e6bdacd1a9a1; Ip=[198.105.204.2]; Helo=[mx01.five9.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB032 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 04:20:06 -0000 > "ECDSA can be smaller, faster, and more secure all at once; and if you do= n't like ECDSA or want an alternative, there's RSA." > Isn't that a step backward reverting to RSA? Ron F. Del Rosario ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . From nobody Mon Aug 31 05:02:08 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1B1A0302 for ; Mon, 31 Aug 2015 05:02:06 -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_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 lq7FataOlrup for ; Mon, 31 Aug 2015 05:02:05 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3D11B3635 for ; Mon, 31 Aug 2015 05:02:05 -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 (Postfix) with ESMTPS id 012398E3C4; Mon, 31 Aug 2015 12:02:04 +0000 (UTC) Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7VC23Rp028782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2015 08:02:04 -0400 To: Dave Garrett , tls@ietf.org References: <201508261742.01242.davemgarrett@gmail.com> From: Florian Weimer Message-ID: <55E4423B.3010101@redhat.com> Date: Mon, 31 Aug 2015 14:02:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <201508261742.01242.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 12:02:07 -0000 On 08/26/2015 11:42 PM, Dave Garrett wrote: > On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote: >> It looks like we have good consensus on PR 169 to relax certificate list >> ordering requirements. I had one question on the revised text. I'm >> unclear on the final clause in this section: >> >> "Because certificate validation requires that trust anchors be distributed >> independently, a self-signed certificate that specifies a trust anchor MAY >> be omitted from the chain, provided that supported peers are known to >> possess any omitted certificates they may require." >> >> I just want to make sure there isn't the intention of omitting certificates >> that are not seif-signed. > > Well, technically anything can be omitted; it just won't validate. :p Firefox completes chains with intermediate certificates it has seen in other certificate chains. This is an endless source of headaches if you use headless clients which do not perform this caching. In this light, MUST NOT automatically complete incomplete chains, except with a trusted root certificate (self-signed or not) might an attractive option. Except that Mozilla could claim its self-learning trust store is just magically growing root certificates in the sense of such a requirement (although such certificates are necessarily intermediate, otherwise it would not be safe to mark them as trusted automatically). -- Florian Weimer / Red Hat Product Security From nobody Mon Aug 31 05:13:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8341B3B42 for ; Mon, 31 Aug 2015 05:13:17 -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, HTML_MESSAGE=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 7G9oRQzv3LsH for ; Mon, 31 Aug 2015 05:13:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A10E1B3AD1 for ; Mon, 31 Aug 2015 05:13:13 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 12:13:10 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 12:13:10 +0000 From: "Dang, Quynh" To: "tls@ietf.org" Thread-Topic: DSA support in TLS 1.3. Thread-Index: AQHQ4cVbMAx36sLx1k+2fYH++EoGO54mABAW Date: Mon, 31 Aug 2015 12:13:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.219.73] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:f1VXVhO40rHpxmQISE26tSFBkZ0DmY9YyTywdt+J22kVrf7GXv1++mHvmkrZBK5C9wAOr9xyP9YxxcZrxVON3vsc23oaXGT783JadcfQTnTti6x1DIsGBGe2468yCGItHi/06Ct79dftjg0xTaiXZA==; 24:JT7J9gxyUBDMdyWpPOD4WS2BT8KyHhmgF9Gl2dSKMMta7LFIQzsg7N/d/EwQ+gXPDC/L61H6A9aD9M5HDBhE8Lb/jdivuH+jjEeWzFjwQFY=; 20:lIEogkUuh2O38D18CoH8tBdUIzmQ/UJ2JxpZYTqAt2a1Ncg67L9FC8btkF/3OWPufyQcvoVD1ovKapKmo971Yg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(53754006)(124975003)(199003)(33656002)(5001830100001)(19580395003)(105586002)(10400500002)(19625215002)(66066001)(5001860100001)(110136002)(74316001)(5007970100001)(19617315012)(122556002)(50986999)(19627405001)(2656002)(107886002)(99286002)(106116001)(64706001)(40100003)(76576001)(86362001)(5001960100002)(5004730100002)(16236675004)(106356001)(77156002)(68736005)(2351001)(101416001)(450100001)(2501003)(189998001)(62966003)(4001540100001)(76176999)(19580405001)(2950100001)(102836002)(5003600100002)(81156007)(2900100001)(5002640100001)(87936001)(54356999)(97736004)(46102003)(92566002)(15975445007)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN1PR09MB12440B6B7247A82976B0C40F36B0BN1PR09MB124namprd_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 12:13:09.9331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:13:17 -0000 --_000_BN1PR09MB12440B6B7247A82976B0C40F36B0BN1PR09MB124namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I thank everyone who took time to think about the issue. The tone of my message below asked for a discussion of "allowed"/optional s= upport for DSA with key size of 2K or bigger. So there would not be a requi= red support for it. There is a number of validated DSA implementations out there with key size = of 2K (http://csrc.nist.gov/groups/STM/cavp/documents/dss/dsanewval.htm) ( = of course I don't know the number of the implementations without validation= s). DSA with 2K or bigger key sizes were added to FIPS 186 in June 2009 (F= IPS 186-3). TLSs are used in more places than just public servers and comm= on browsers. For the people who use DSA in TLSs, it would be nice if they c= ould run TLS 1.3 with DSA if they choose to do so. Quynh. ________________________________ From: TLS on behalf of Dang, Quynh Sent: Friday, August 28, 2015 3:17 PM To: ekr@rtfm.com; tls@ietf.org Subject: [TLS] DSA support in TLS 1.3. Hi all, DSA is supported in the previous versions of TLS. It would be nice if someo= ne who uses DSA can use it in TLS 1.3 as well. People who don't use DSA, then they don't use DSA. People who use DSA right= , it should be fine for them to use DSA. I don't see a convincing reason to remove support of DSA in TLS 1.3. Quynh. --_000_BN1PR09MB12440B6B7247A82976B0C40F36B0BN1PR09MB124namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,


I thank everyone who took time to think about the issue.


The tone of my message below asked for a discussion of "allowed&quo= t;/optional support for DSA with key size of 2K or bigger. So there would n= ot be a required support for it.


There is a number of validated DSA implementations out there with key si= ze of 2K (http://csrc.nist.gov/groups/STM/c= avp/documents/dss/dsanewval.htm) ( of course I don't know the number of the implementations without va= lidations).  DSA with 2K or bigg= er key sizes were added to FIPS 186 in June 2009 (FIPS 186-3).  TLSs are used in more places = than just public servers and common browsers. For the people who use DSA in=  TLSs, it would be nice if they could run TLS 1.3 with DSA if they choose to do so. 


Quynh. 



From: TLS <tls-bounces@i= etf.org> on behalf of Dang, Quynh <quynh.dang@nist.gov>
Sent: Friday, August 28, 2015 3:17 PM
To: ekr@rtfm.com; tls@ietf.org
Subject: [TLS] DSA support in TLS 1.3.
 

Hi all, 


DSA is supported in the previous versions of TLS. It would be nice if so= meone who uses DSA can use it in TLS 1.3 as well. 


People who don't use DSA, then they don't use DSA. People who use DSA ri= ght, it should be fine for them to use DSA.


I don't see a convincing reason to remove support of DSA in TLS 1.3.


Quynh. 

--_000_BN1PR09MB12440B6B7247A82976B0C40F36B0BN1PR09MB124namprd_-- From nobody Mon Aug 31 05:43:12 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9DB1B3B9F for ; Mon, 31 Aug 2015 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 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, RCVD_IN_SBL_CSS=3.335, 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 8JjtO0X2vJZK for ; Mon, 31 Aug 2015 05:43:08 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15C41B304F for ; Mon, 31 Aug 2015 05:43:07 -0700 (PDT) Received: from pc1 ([::ffff:88.128.80.221]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 31 Aug 2015 14:43:04 +0200 id 0000000000000031.0000000055E44BD8.00007ACA Date: Mon, 31 Aug 2015 14:43:16 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150831144316.0a4fbf30@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-31434-1441024984-0001-2" Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 12:43:10 -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-31434-1441024984-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 31 Aug 2015 12:13:09 +0000 "Dang, Quynh" wrote: > TLSs are used in more places than just > public servers and common browsers. For the people who use DSA in > TLSs, it would be nice if they could run TLS 1.3 with DSA if they > choose to do so. I think we all know that TLS is more than browsers. However the "people who use DSA in TLS" are currently a mere statement from you, we don't know if they exist. Several people have asked you whether you can name use cases. You haven't answered. As long as that's the case this discussion is pointless. We shouldn't keep DSA just because someone we don't know might have a use case we can't imagine. If you can tell us a) who is using DSA b) why they think this has an advantage we can have a useful discussion. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-31434-1441024984-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJV5EvkAAoJEKWIAHK7tR5C7E0P/jWX1J1ytwu28q3ECZHZ5CPE 2pxxRXxRMDMFjQUPDzHbAY+CUKgUeWs+wXfYyQkpys3bej2fG02KUzGDi+pIO+gX ZtEKlJhxfHfH+wFElqsP1Tj3IO25l3vNeajHXbHMu4CS9DkIq6cqTFFZYovrk08c vOejt6Q/defH/8EvDjAvSzb7rlKfTyLHAaBwnCZEDk1ovi1th/rOKznCuE7jsoez lHMb1rrxZLHPqCkwWY89dIvVk+7rwOP7r5+p1tT8c8RF7XA5xtKsnfTzaJTTCdRv oaGjkaShmNGXswd55J2ugUePrFy7WLkP3cB4HhMVMfoW37ex3WraLP8toKDE5TUb MM/5DsyuZtR4HH2+bnk5hJ8xPvgQpvaj2wHlDsuey2oLGzxZI3uhZ2GDbMDRI11u IZHekHorvx+74Aa/FjvWX2YzYusqcvgm185p42qvzy6IoON7qhBWXek7M/RTaBEA nHqZgfdnB0SKKc3MaYGw1+KlacuQ7DVWhAC+oXBdHnUYsXYHrtqS6TGJYn3VYzED iK4QF5DQN32tpNWRhShKIs9tP/16dwgMn+KqUag57kcQpBjH0jvJim6T4ybm/bow hROuMjxpyiBKjGfb7+OOHLopCV8keC6UySEAvFT6ew7uSvfUuY8P7Y6yJI2uBFeh QGjXVOmZ/b6ltZluegxZ =pLt8 -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-31434-1441024984-0001-2-- From nobody Mon Aug 31 08:54:20 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4C1B537F for ; Mon, 31 Aug 2015 08:54: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 B0uPrgy9TC7E for ; Mon, 31 Aug 2015 08:54:17 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724941B537D for ; Mon, 31 Aug 2015 08:54:17 -0700 (PDT) Received: by qkcj187 with SMTP id j187so2873761qkc.2 for ; Mon, 31 Aug 2015 08:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TbTjhyFwm8cTF0ga76sriG0CJv7MwvgIWncpveTcV1I=; b=uqC2qYj41xCVKyLj82AtLlz51FDAWSa4NofAAaTxKWXS7LmRRRq1jig/1GCFrZNnP/ AFznJLkr8KYAvrBTWCemcTHU3/RuFTQFnzLy7KyZ+Fv2IU3pn8AJfx7ELyWPAfOKoJKD loLKvkgVc7bAeUBh2+HQ194MQ7+fk1iGFMTc/ic91i1cq+fCD8YdaZCKPNeBXeEjF9zL svMGUGx0lC3VYgXa6EXDtT2ridmZffNSebZq0+bwwGfg2lV3SpjFnus2wp+ObeAHCbcd Umvcfvx8h5+8B7eNPsgBSpPmuK/aM7ylIhtgQIO3U8br+Iytw9uTb7rnEurbMrDcFYzM 3t5g== MIME-Version: 1.0 X-Received: by 10.129.45.194 with SMTP id t185mr22878309ywt.52.1441036456644; Mon, 31 Aug 2015 08:54:16 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Mon, 31 Aug 2015 08:54:16 -0700 (PDT) In-Reply-To: <55E4423B.3010101@redhat.com> References: <201508261742.01242.davemgarrett@gmail.com> <55E4423B.3010101@redhat.com> Date: Mon, 31 Aug 2015 08:54:16 -0700 Message-ID: From: Martin Thomson To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 15:54:18 -0000 On 31 August 2015 at 05:02, Florian Weimer wrote: > MUST NOT automatically complete incomplete chains Um, no. I realize that this is a feature that is hard for others to replicate, but being able to reach sites is important to people. All browsers do this, and I don't see any reason to stop. From nobody Mon Aug 31 08:56:32 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A51B53C0 for ; Mon, 31 Aug 2015 08:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 MiIhWzXo6x_8 for ; Mon, 31 Aug 2015 08:56:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FA31B53BE for ; Mon, 31 Aug 2015 08:56:29 -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 (Postfix) with ESMTPS id 103778C1AA; Mon, 31 Aug 2015 15:56:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7VFuRB2027067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2015 11:56:28 -0400 To: Martin Thomson References: <201508261742.01242.davemgarrett@gmail.com> <55E4423B.3010101@redhat.com> From: Florian Weimer Message-ID: <55E4792A.30809@redhat.com> Date: Mon, 31 Aug 2015 17:56:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 15:56:31 -0000 On 08/31/2015 05:54 PM, Martin Thomson wrote: > On 31 August 2015 at 05:02, Florian Weimer wrote: >> MUST NOT automatically complete incomplete chains > > Um, no. I realize that this is a feature that is hard for others to > replicate, but being able to reach sites is important to people. All > browsers do this, and I don't see any reason to stop. The reason to stop is that people only test with long-running, well-used browser profiles, and it is difficult to explain to them that things don't work if you just installed a fresh system. I lost countless hours to that. As in other cases, browsers papering over site configuration errors causes ecosystem damage. -- Florian Weimer / Red Hat Product Security From nobody Mon Aug 31 08:59:10 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1831B5423 for ; Mon, 31 Aug 2015 08:59: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 fvJO0LmCfyg9 for ; Mon, 31 Aug 2015 08:59:08 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B838A1B5424 for ; Mon, 31 Aug 2015 08:59:07 -0700 (PDT) Received: by qkbp67 with SMTP id p67so3046270qkb.3 for ; Mon, 31 Aug 2015 08:59: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=J8SizVayc/4dMQIGZ1QtZ04Y9Sui8WM8OtXPkGn/kNo=; b=A+1nUFIDwxJJWC/HyEgOMaC0hk8h27FnosKhWtYtr9MvON15W7G+Evj/JWovwA+PVO 1r8B/F1YE0dod5Aw+9x2Jv5YBofNzK/ysQG912P1Wo+ubBYAfYpNJPfodogvDpJab0DA cudzv1U3teSoOzx8sJJPSr7QEwBkHUOF5WNP+CUpE+ShgncoybRMjDizkfUCsY4pjiie fc/CYPhb69xpSzqic6Pvda4j8llnfRFBQg3e8dfIOe3JgBA2b6KiJ5cLuVFFmxe1yFjD icfcN7IRE2bnCekxGqilRFUnOffVfZaNDDK5Bjs5qdoM/Xn+wTGDdVGE2F90dyfIsY6b u3ow== MIME-Version: 1.0 X-Received: by 10.129.51.88 with SMTP id z85mr10113950ywz.148.1441036747035; Mon, 31 Aug 2015 08:59:07 -0700 (PDT) Received: by 10.129.133.130 with HTTP; Mon, 31 Aug 2015 08:59:06 -0700 (PDT) In-Reply-To: <55E4792A.30809@redhat.com> References: <201508261742.01242.davemgarrett@gmail.com> <55E4423B.3010101@redhat.com> <55E4792A.30809@redhat.com> Date: Mon, 31 Aug 2015 08:59:06 -0700 Message-ID: From: Martin Thomson To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 15:59:09 -0000 On 31 August 2015 at 08:56, Florian Weimer wrote: > On 08/31/2015 05:54 PM, Martin Thomson wrote: >> On 31 August 2015 at 05:02, Florian Weimer wrote: >>> MUST NOT automatically complete incomplete chains >> >> Um, no. I realize that this is a feature that is hard for others to >> replicate, but being able to reach sites is important to people. All >> browsers do this, and I don't see any reason to stop. > > The reason to stop is that people only test with long-running, well-used > browser profiles, and it is difficult to explain to them that things > don't work if you just installed a fresh system. I lost countless hours > to that. As in other cases, browsers papering over site configuration > errors causes ecosystem damage. I tell you what, we'll stop: a) after all the other browsers stop, and b) when the number of sites that become unreachable as a result is low enough (I think that 1/1000 connections might be high) I know that it sucks, but it's hard to turn off something like that when it has a large compatibility risk and no security upside. From nobody Mon Aug 31 09:03:13 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0D1B5255 for ; Mon, 31 Aug 2015 09:03: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 rIwmV6aj94UO for ; Mon, 31 Aug 2015 09:03:10 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5D31B3AB3 for ; Mon, 31 Aug 2015 09:03:09 -0700 (PDT) Received: by wibq14 with SMTP id q14so5046588wib.0 for ; Mon, 31 Aug 2015 09:03:07 -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=BlC17uG6UTkOFv2rSZNgii042aLh1ZKSQ3wh1iq4Zho=; b=PkvnZj7R4Cx9eiDCMXHRPZybmGj5CZXgWNV6anEQCK74W9+7yVRGwME3aabRYioxD9 tLFWmuV7W5QBlwQ5djlfv9sLmSE/NM0NIrDABqJTfN8Llh8kJFXnDyHC7rnJrFla20pZ dm7qFd2rJjOvpda9o0vIP35w8JtcgBsR06tf7QMlgL8N+8i7WHzKekySwK2Vr9DBVy2z xHVjIU5jZ06m7Tnf83omAJw3Wy+/PoTY0T1xY0j73tEIThhLEF7lPcrRWRLvtLN0/h6j rAgUgEHeJopDySQCiVL7YqMheyKHBLzJn6MvzJSTWA1LcDGNoDowMDCBpW0hiYxg3yG3 ozfQ== X-Received: by 10.180.85.163 with SMTP id i3mr21173977wiz.1.1441036987805; Mon, 31 Aug 2015 09:03:07 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id fs8sm18677870wib.0.2015.08.31.09.03.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 09:03:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <55E4792A.30809@redhat.com> Date: Mon, 31 Aug 2015 19:03:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <528150F2-3323-4384-B812-006749D404AD@gmail.com> References: <201508261742.01242.davemgarrett@gmail.com> <55E4423B.3010101@redhat.com> <55E4792A.30809@redhat.com> To: Florian Weimer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 16:03:11 -0000 > On Aug 31, 2015, at 6:56 PM, Florian Weimer = wrote: >=20 > On 08/31/2015 05:54 PM, Martin Thomson wrote: >> On 31 August 2015 at 05:02, Florian Weimer = wrote: >>> MUST NOT automatically complete incomplete chains >>=20 >> Um, no. I realize that this is a feature that is hard for others to >> replicate, but being able to reach sites is important to people. All >> browsers do this, and I don't see any reason to stop. >=20 > The reason to stop is that people only test with long-running, = well-used > browser profiles, and it is difficult to explain to them that things > don't work if you just installed a fresh system. I lost countless = hours > to that. As in other cases, browsers papering over site configuration > errors causes ecosystem damage. I feel the pain (I know some administrators who have made this mistake), = but it=E2=80=99s always best to test with something like =E2=80=9Copenssl = s_client=E2=80=9D. Yoav From nobody Mon Aug 31 09:13:39 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F471B55CF for ; Mon, 31 Aug 2015 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 0IRgvuQrfnMr for ; Mon, 31 Aug 2015 09:13:32 -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 2A4431B4F0E for ; Mon, 31 Aug 2015 09:13:32 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id D16D4B809A; Mon, 31 Aug 2015 09:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=pMWlEcz+XDu5XpAIDpkWdIA+zWY =; b=oeQY/WNC1G5pXNNon5RkJDyG4KtJqguS5Ef+p35wtIJI4Pt5WZQLZxg4XUO gv/ruaGcl4tDWj32YxkXZQ5TIsci9FL6qFq06hCFlbc9lIsnEigI39DzYnXZ5mBt DYvx6I7aHBCi/6ng5k3Pz1Li290i4sb8G8fm1FufQDyZIEW0= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 9B02EB8056; Mon, 31 Aug 2015 09:13:31 -0700 (PDT) Date: Mon, 31 Aug 2015 11:13:30 -0500 From: Nico Williams To: tls@ietf.org Message-ID: <20150831161234.GA17159@localhost> References: <20150828183317.GO9021@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150828183317.GO9021@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 16:13:38 -0000 On Fri, Aug 28, 2015 at 06:33:17PM +0000, Viktor Dukhovni wrote: > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > Furthermore, anon-DH has strong privacy properties, the server > sends no identity information, not even a public key. Any > channel-binding at the next layer is privacy protected. Using raw public signature keys doesn't change that. It just requires generating a signature key every time. For devices/protocols where DH_anon is common (perhaps because they do channel binding) the proposal at hand is annoying and CPU-wasting, but hardly fatal. I'm not sure how I feel about this. The idea that we always do a DH key exchange and always have a server signature means we can greatly reduce the number of ciphersuites, so that's quite helpful. We'd have to apply this to PSK too to make it really worthwhile. > My view is that anon_DH should either be supported properly (be > defined for the same symmetric cipher combinations as ciphersuites > with certs or public keys) or as proposed not supported at all. Yes, DH_anon should be first-class. Nico -- From nobody Mon Aug 31 09:19:18 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6206F1B3E2B for ; Mon, 31 Aug 2015 09:19:17 -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 N-3Wp-ABebLi for ; Mon, 31 Aug 2015 09:19:15 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA891B33E4 for ; Mon, 31 Aug 2015 09:19:15 -0700 (PDT) Received: by wibz8 with SMTP id z8so5438495wib.1 for ; Mon, 31 Aug 2015 09:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tih10md4PGLK1UJPapwb+wseyp/AEnaVE3GmqgBcQU4=; b=Cft08/CwP+FUNYqOIFYunfM+xxvAej54OHoBUWxp7n+QXXEk8d3az94uTi+z067p6s awwmMofZR42Ll0xP4OPV0uPBEXgYzmIfuaCc8jmEOPkqrM7Mll2whMwlZKQ7NE/gM9su ad4MFL2rL9zvJwnNsS7w7Pn3wL2ExzDMsi/2rGfGObx3NegklLozi7c91mJw2ih5uFRX JkRKK4V8qA9Us4vDm/L/IpNm4OKRQPTh3zcmNLHUHl8NI+2Th1L02TUITc3dI9UFHh/Y FhhuiZ5+aJ0hwV92VZVYA61JxILTUBDQbep4RNK+7Ue1MtiI+8VKxn0Rzql0OwYhnu74 hQ1w== X-Gm-Message-State: ALoCoQmOrQDzMDx2BsK7KlhbDCRdGeJOL728d8ZZyrH9maKaMecEw1zsxnA9cCvNGGjV+g4prn2L X-Received: by 10.180.189.108 with SMTP id gh12mr10105679wic.53.1441037954219; Mon, 31 Aug 2015 09:19:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Mon, 31 Aug 2015 09:18:34 -0700 (PDT) In-Reply-To: <20150831161234.GA17159@localhost> References: <20150828183317.GO9021@mournblade.imrryr.org> <20150831161234.GA17159@localhost> From: Eric Rescorla Date: Mon, 31 Aug 2015 09:18:34 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c3420c5e94ae051e9dcb48 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 16:19:17 -0000 --001a11c3420c5e94ae051e9dcb48 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams wrote: > On Fri, Aug 28, 2015 at 06:33:17PM +0000, Viktor Dukhovni wrote: > > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote: > > Furthermore, anon-DH has strong privacy properties, the server > > sends no identity information, not even a public key. Any > > channel-binding at the next layer is privacy protected. > > Using raw public signature keys doesn't change that. It just requires > generating a signature key every time. > > For devices/protocols where DH_anon is common (perhaps because they do > channel binding) the proposal at hand is annoying and CPU-wasting, but > hardly fatal. > > I'm not sure how I feel about this. The idea that we always do a DH key > exchange and always have a server signature means we can greatly reduce > the number of ciphersuites, so that's quite helpful. We'd have to apply > this to PSK too to make it really worthwhile. Certainly it would be nice to get rid of PSK too but just getting rid of DH_anon makes a non-trivial difference. -Ekr --001a11c3420c5e94ae051e9dcb48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams <nico@cryptonector.= com> wrote:
On Fri, Aug 28, 2015 at 06:33:17PM +0000, Viktor Dukhovni wrote:
> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> Furthermore, anon-DH has strong privacy proper= ties, the server
> sends no identity information, not even a public key.=C2=A0 Any
> channel-binding at the next layer is privacy protected.

Using raw public signature keys doesn't change that.=C2=A0 It ju= st requires
generating a signature key every time.

For devices/protocols where DH_anon is common (perhaps because they do
channel binding) the proposal at hand is annoying and CPU-wasting, but
hardly fatal.

I'm not sure how I feel about this.=C2=A0 The idea that we always do a = DH key
exchange and always have a server signature means we can greatly reduce
the number of ciphersuites, so that's quite helpful.=C2=A0 We'd hav= e to apply
this to PSK too to make it really worthwhile.

Certainly it would be nice to get rid of PSK too but just getting rid of=
DH_anon makes a non-trivial difference.

-Ekr

--001a11c3420c5e94ae051e9dcb48-- From nobody Mon Aug 31 09:45:36 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F0B1B2D77 for ; Mon, 31 Aug 2015 09:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 R9xA14kr2gZl for ; Mon, 31 Aug 2015 09:45:32 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B0F221B2BA7 for ; Mon, 31 Aug 2015 09:45:32 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 50FD555408E; Mon, 31 Aug 2015 09:45:32 -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=U/H0OujG/bxpH6 fIKhFcq1kP9ps=; b=niEMCr1mYrC5FV72DXFkTp7oSnu6OxGqoSBVRr8pRUD+H9 65iHvthwcEluq7DKXzYlFZ517qgxFL9tF3khymCwEU44MhP+GgEIuIBnjbWCv2Lx s1aKHu0L1xnFvESF6fVW/xZz6x43LU6qW94wLNCkF9KajbjOkjOdi6bICc2GQ= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id EF98A55408D; Mon, 31 Aug 2015 09:45:31 -0700 (PDT) Date: Mon, 31 Aug 2015 11:45:31 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150831164530.GB17159@localhost> References: <20150828183317.GO9021@mournblade.imrryr.org> <20150831161234.GA17159@localhost> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 16:45:33 -0000 On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > wrote: > > I'm not sure how I feel about this. The idea that we always do a DH key > > exchange and always have a server signature means we can greatly reduce > > the number of ciphersuites, so that's quite helpful. We'd have to apply > > this to PSK too to make it really worthwhile. > > Certainly it would be nice to get rid of PSK too but just getting rid of > DH_anon makes a non-trivial difference. How would we get rid of PSK [without DH]? What would the impact be on IoT devices? Could we have a fake-DH-and-signature PSK scheme to make it easy on IoTs? Nico -- From nobody Mon Aug 31 09:48:55 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70A91B57B6 for ; Mon, 31 Aug 2015 09:48:52 -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 G4vK-hSfSgou for ; Mon, 31 Aug 2015 09:48:51 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F63C1ACEAD for ; Mon, 31 Aug 2015 09:48:51 -0700 (PDT) Received: by wiclp12 with SMTP id lp12so5116008wic.1 for ; Mon, 31 Aug 2015 09:48:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C2znYdArf1K4IIetXPEsNP8OiFQNDE+Bhbg0ubEd8eI=; b=TUo8KGaxaGqnvvUzylEQMjW1bdo4AtqS3L9Eq6dd4mNtmTQ+g0/4jWTvg0rpnoB45C v/YCD/3/IoiJzpT1f/V7Q24hTr0zzTWEomoGuYzPBk4kn1sPVHwsI+xa6S86fr9h1cxR 81RY/3hiWxVTgFMyzOmIK9IvUtB5khQcAy7KVzn4N6ekvnSlfLu8RygsMJ4E1F9aKJ9M 1fQ7onaoSBMm0wMOFJSeS6+wjJ4BhaUBYWWhomUDHXuLYwmGd37vgT147BYPwrj1Sn2x hLz4/ZPQphXxn//OMszfj2jLi0tdIG/g+jyhopDLDNG4El/3LuBBVDSVtkKsNGiA9/8+ zhRg== X-Gm-Message-State: ALoCoQnW2C4VI/9YAkYQOl72cAU7J8canE7ktN1tXl48LWMF8VNJsYkz7jqIdk7w4sAQomgOXVBE X-Received: by 10.194.216.68 with SMTP id oo4mr27503116wjc.81.1441039729795; Mon, 31 Aug 2015 09:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.221 with HTTP; Mon, 31 Aug 2015 09:48:10 -0700 (PDT) In-Reply-To: <20150831164530.GB17159@localhost> References: <20150828183317.GO9021@mournblade.imrryr.org> <20150831161234.GA17159@localhost> <20150831164530.GB17159@localhost> From: Eric Rescorla Date: Mon, 31 Aug 2015 09:48:10 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=089e0141a09233bbc4051e9e35ca Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 16:48:53 -0000 --089e0141a09233bbc4051e9e35ca Content-Type: text/plain; charset=UTF-8 On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams wrote: > On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote: > > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams > > wrote: > > > I'm not sure how I feel about this. The idea that we always do a DH > key > > > exchange and always have a server signature means we can greatly reduce > > > the number of ciphersuites, so that's quite helpful. We'd have to > apply > > > this to PSK too to make it really worthwhile. > > > > Certainly it would be nice to get rid of PSK too but just getting rid of > > DH_anon makes a non-trivial difference. > > How would we get rid of PSK [without DH]? What would the impact be on > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > it easy on IoTs? I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm saying that even if we still have PSK, removing DH_anon as an explicit mode makes things simpler. -Ekr --089e0141a09233bbc4051e9e35ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams <nico@cryptonector.= com> wrote:
On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote:
> On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > I'm not sure how I feel about this.= =C2=A0 The idea that we always do a DH key
> > exchange and always have a server signature means we can greatly = reduce
> > the number of ciphersuites, so that's quite helpful.=C2=A0 We= 'd have to apply
> > this to PSK too to make it really worthwhile.
>
> Certainly it would be nice to get rid of PSK too but just getting rid = of
> DH_anon makes a non-trivial difference.

How would we get rid of PSK [without DH]?=C2=A0 What would the impac= t be on
IoT devices?=C2=A0 Could we have a fake-DH-and-signature PSK scheme to make=
it easy on IoTs?

I guess I wasn't clear= : I'm not in favor of getting rid of PSK. I'm saying that
even if we still have PSK, removing DH_anon as an explicit mode makes
things simpler.

-Ekr

--089e0141a09233bbc4051e9e35ca-- From nobody Mon Aug 31 10:41:47 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9AF1B3E40 for ; Mon, 31 Aug 2015 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 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_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 8Gwtt9US73FH for ; Mon, 31 Aug 2015 10:41:44 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5701B3E7F for ; Mon, 31 Aug 2015 10:41:44 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 2733A2A07; Mon, 31 Aug 2015 10:41:44 -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=CZ9LfBpvsefVPC D3DIZ9QQ4+AA4=; b=ATj4Ayc8taDH7h+RE5/tbTvtFAuB47IGpPxboLGS0+3ucf ptlR1xcoxgE+yLrvn2XVq1OUWUEHLH6N2gkm+zhERJDFa3EafAAdMfegGBE7zDZi 9kOBgP/gw2vZ+oh+U73JGu3yDG6Sx0ZyuXYoxXlh51vaU/bNQXuWPOR47Qe1M= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id AC0AC2A05; Mon, 31 Aug 2015 10:41:43 -0700 (PDT) Date: Mon, 31 Aug 2015 12:41:41 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150831174140.GC17159@localhost> References: <20150828183317.GO9021@mournblade.imrryr.org> <20150831161234.GA17159@localhost> <20150831164530.GB17159@localhost> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Deprecate DH_anon in favor of raw public keys? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for 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 Aug 2015 17:41:45 -0000 On Mon, Aug 31, 2015 at 09:48:10AM -0700, Eric Rescorla wrote: > On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams > wrote: > > How would we get rid of PSK [without DH]? What would the impact be on > > IoT devices? Could we have a fake-DH-and-signature PSK scheme to make > > it easy on IoTs? > > I guess I wasn't clear: I'm not in favor of getting rid of PSK. I'm > saying that even if we still have PSK, removing DH_anon as an explicit > mode makes things simpler. I wasn't either. I was asking about requiring the use of DH [and a server signature] when using PSK. Let's get back to removing DH_anon for a minute. What would the impact be on TCPINC proposals using TLS as their basis? They really need anonymity, leaving it to the application to do channel binding. (The application might be using TLS itself, oddly enough.) Do we really want to force servers to generate an unnecessary signing key, compute an unnecessary signature, and to then force clients to verify said unnecessary signature (if they don't then there's a subliminal channel)?? I think "no", unless the signature algorithm used is cheap [and weak], which probably adds other complications. Back to PSK: How is PSK with PFS going to work? How is PSK w/o PFS going to work? Anyways, my current take is that we should not get rid of the DH_anon ciphersuites. I grant that the existing applications (ignoring TPCINC?) could take the performance hit, but in the longer term it seems likely to be more problematic than helpful. Nico -- From nobody Mon Aug 31 16:06:21 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C61B6AD7 for ; Mon, 31 Aug 2015 16:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4RmjT4FxW-Q for ; Mon, 31 Aug 2015 16:06:17 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27741B6AD4 for ; Mon, 31 Aug 2015 16:06:16 -0700 (PDT) Received: by qgeb6 with SMTP id b6so75649321qge.3 for ; Mon, 31 Aug 2015 16:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=IzeIA6g0oF6/AnE4dXy9sHHj/9mlxexo9rD9cK9tUZw=; b=gE8ECCGIkKAAZ3cL4WrZqZCMBglC63C1901lHNc1d5pY2XXAcNJVMyLwZK7PfjdTyQ vFDip0lOgTAgHhcC57qeVCuRPlwysQhSk4kA5cuye/Kg5GK9cwS7l5qki7xifYOQrIz2 /+slF9dPjBWFbd3osAWU0qeazJZU3H8fSMoPXSicNQltfu8c39ick44F8N4VK/C4nXWP z2Qq/7x8WRN7ITCkRCGNXBOIve4hvnUkn3aom0PfekWj4hDYtAd1nBxmxVkaaNk9A39C /gQBpTAnxa2EGcVMq7ohw93YAKuSTipdE+TNTfaoxLtu2hihoiGF3tV1RbCeMS+If/NR I38Q== X-Received: by 10.140.146.196 with SMTP id 187mr18224585qhs.76.1441062376080; Mon, 31 Aug 2015 16:06:16 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id 186sm9654564qhf.16.2015.08.31.16.06.15 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 31 Aug 2015 16:06:15 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 31 Aug 2015 19:06:14 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20150831144316.0a4fbf30@pc1> In-Reply-To: <20150831144316.0a4fbf30@pc1> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201508311906.14344.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] DSA support in TLS 1.3. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 23:06:18 -0000 On Monday, August 31, 2015 08:43:16 am Hanno B=C3=B6ck wrote: > If you can tell us > a) who is using DSA > b) why they think this has an advantage > we can have a useful discussion. Not to mention: c) why they aren't switching to ECDSA Dave From nobody Mon Aug 31 17:47:31 2015 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7622A1B508A for ; Mon, 31 Aug 2015 17:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 lj0THJXBRbsK for ; Mon, 31 Aug 2015 17:47:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800271A0115 for ; Mon, 31 Aug 2015 17:47:27 -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 (Postfix) with ESMTPS id F24A08EA3C for ; Tue, 1 Sep 2015 00:47:26 +0000 (UTC) Received: from rrelyea-laptop.usersys.redhat.com (dhcp-16-202.sjc.redhat.com [10.14.16.202]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t810lQ5t027171 for ; Mon, 31 Aug 2015 20:47:26 -0400 To: tls@ietf.org References: <20150828194922.GA30171@LK-Perkele-VII> From: Robert Relyea Message-ID: <55E4F59E.8060700@REDHAT.COM> Date: Mon, 31 Aug 2015 17:47:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090401020808070505020906" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] DSA support in 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, 01 Sep 2015 00:47:29 -0000 This is a cryptographically signed message in MIME format. --------------ms090401020808070505020906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 08/28/2015 08:17 PM, Geoffrey Keating wrote: > Jeffrey Walton writes: > >>> Also, if DSA was to be supported, one would need to specify how to >>> determine the hash function (use of fixed SHA-1 doesn't fly). And >>> 1024-bit prime is too small. >>> >> FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf) >> partially remediates the issue. DSA now includes 2048 and 3072 sizes. > This is true, but if TLS 1.3 was to specify DSA, it should require the > 2048 or 3072 sizes (since 1024 is last century's crypto), and existing > implementations do not necessarily support those today. That's sort of a generic statement. I know NSS supports 2048 and 3072=20 bit DSA. > > Which really highlights the question: who would actually use it? > ECDSA can be smaller, faster, and more secure all at once; and if you > don't like ECDSA or want an alternative, there's RSA. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------ms090401020808070505020906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJAwggY0MIIEHKADAgECAgEgMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAyNTVaFw0xNzEwMjQyMTAyNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLKIVFnAEs+xny q6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQA7Xj9AGM6wgP hEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQgKO19b+R t8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj113yK Mm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLsw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQA6qScNyNO0FpHvaZTQacVMXH33O51KyEKSRw3IvdQxRu31YR0ZDGdSfgSoOVDVMSBSdmfQ fdDInHPzV3LO5DwUXZ+lxjv7z3PO2OkfnFkvTXPfn6dxJ5rJveDsTsCPcJ/Kp6/+qN5g+J6D /SaYcFD018B6L42r0Z4VEBy36P4tjRtF14Ex10tl5tJFVKM16qWKQHbpjIgf73s49UB0CQ5l HT2DHKfq3oPfdNc5Mk93w1v4ryVb+qVrZIej8NsrWU+5r4O2IV91edDb/OtHFddZqHFFXKgS 79IHE/hwQ2LW7r3sTX7cDUCg+dfdwO8zeLxuwk2JF8crUoyrl66RGrRIhT8VoG/OJ1Y9uUlO av69V4cG8upi4ZG2l7JZFbcBFk91Wp+Payo5SuF61CmGFrZ386umkmpObtFacXda2O/bVoQ9 xHQrzoTc/0KZTWvlZCLK3Ke/vGYT9ZdW9lOjGsSFbXrlTA919L84iMK+48WGnvRWY28ZaVHp ql43AtEGhXze6iNCbEDACy+4hkQYOytAqDgcxAnQ937mYpeZFPyz/XK9QSt9VNFMuudWxZwD DDJKoQAoSG59Hou9lZ26UrK60nRdAQBmEPL8h2nuWgoPh++XVQld9yuhbsWa39Pck8/lcfz5 HUVGJF5mc/zk38iV7FDlF68puiryNq2KXHEpOTCCBlQwggU8oAMCAQICAlIDMA0GCSqGSIb3 DQEBCwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwODE4MTcz NjU2WhcNMTYwODE4MjAyMjE2WjBxMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTESMBAGA1UEBxMJU3Vubnl2YWxlMRYwFAYDVQQDEw1Sb2JlcnQgUmVseWVhMSEwHwYJKoZI hvcNAQkBFhJycmVseWVhQHJlZGhhdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC2h3cZFHyDLHrwQiIQvW3O1v3sLmwQKSC3YlfJwE0etWUy0cy+XG8cuVlV8x9kWlf2 T1SIikGISMm8UHuUntpuH/0CWziffeF9tmO6pd5M+c/zk+i7gkgvPxf2UqLvKE0q736jJyPm oCPBu8jR74xtZwgIxuHQBx57uVV8/4/VePb3Ef2E8qaDN9V8Rdn51CyryOod/ppJ0so88ReW C5qmDC5/F3D3ku29W/ZqVW84/5F0JKOatO7dqIUdRgx+LWsGvs/gwSlNqsdJ79cdnXDGmWHO a4m+qUqbvPFeYLXRrnFxQJoezPuqcYKmdFmSj2VykxymdauFoQfCOpG17YcZAgMBAAGjggLY MIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwHQYDVR0OBBYEFMHL3cM6QMqQtnjEmxqllSebdX/PMB8GA1UdIwQYMBaAFK5Vg2/s Mcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnJyZWx5ZWFAcmVkaGF0LmNvbTCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNz dWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBv ZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5k ZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRp b25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1j cmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFy dHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEu c3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAa hhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAFe1vf4Dk8Wx IGqLN05k/8sM7o0g1iSPRm++kXaIDGXawodnRBe9t1Xx2FvwuQ/AlvfLy0h5Mt6dQu1hKt8p m7n47e7+bUWPiSD/jW8pAuKiXDViR9nCPiIaW3haMJU23dG3leD2lIm5Nuu/ZpKT9Jxsnjyu i0xfLypICpHiQtqXSDPprL3iUgiN3OK6vgC80Ogl7GHd/SqDHNX1xGZpOZgKPOGcL4hj0BPq BtxICdim+cGLAHgnVm6mjD0fd2WiSr3tYQrc8ngafGWQxFQ3XWawimY5kLoFEZI2ygij7wFq ZVzDoZicaSEIIgGJAkKY6nOuqR8d9XrGoxQdMecgke0xggPqMIID5gIBATCBkzCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJSAzANBglghkgBZQMEAgEFAKCCAicwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwOTAxMDA0NzI2WjAv BgkqhkiG9w0BCQQxIgQgLCHjVz1/S93hh6n6/TDhq/zNnC7vIMxVjGzg3L6JkHkwbAYJKoZI hvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJ KwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlID MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgJSAzANBgkqhkiG9w0BAQEFAASCAQBBzzNYVpsZ06Qx0le2MrQAOL9lzv+k+wbJfseF AUcLdHUC7YPYjMBxAjgKlzME4xNL0J+feJVBwi0MIxGiwdln7nt86RpVb+H1RvxrrtvxhS6F 2EZqk6zhZuykci5ug9pfsokcAid4dubTgiD8IUIzjP6JVZCTvAT3lHSXU0ixqzaaqwv+oJbx sPutc+UI+zZMYwn+2nGCBzxjwFNzOWuWv0c0ET8QeGqOXbxaL4DEONnGPJBpbWCPy9XWRflG ceJj3XYdaDrALR0pzJ1bJqA3ez0nMPfi3Cor1kenCQguclvk9nwEyw/JtrcU6bO86MTyyAmx kTMRhLVY6RxeMEo7AAAAAAAA --------------ms090401020808070505020906--