From nobody Sun Mar 1 04:02: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 260C71A88A4 for ; Sun, 1 Mar 2015 04:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcqhhDmHpF7l for ; Sun, 1 Mar 2015 04:02:24 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A77F21A88A3 for ; Sun, 1 Mar 2015 04:02:24 -0800 (PST) Received: from fifthhorseman.net (5.40.111.162.static.user.ono.com [5.40.111.162]) by che.mayfirst.org (Postfix) with ESMTPSA id 50368F984; Sun, 1 Mar 2015 07:02:22 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 526091FFDD; Sun, 1 Mar 2015 13:02:22 +0100 (CET) From: Daniel Kahn Gillmor To: Sean Turner , "TLS\@ietf.org \(tls\@ietf.org\)" In-Reply-To: References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 01 Mar 2015 13:02:22 +0100 Message-ID: <878ufhaptd.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-tls-negotiated-ff-dhe@tools.ietf.org Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 12:02:26 -0000 On Wed 2015-02-18 13:12:33 +0100, Sean Turner wrote: > The WGLC has concluded. dkg noted he’d received some comments > off-list and Watson provide some input. We’ll need a new version to > review the changes to see if it should be progressed or whether > another WGLC is needed. I’ve updated the datatracker to reflect the > new state. > > dkg, > > Any chance of another version before the 2015-03-09 draft submission deadline? I've just submitted -06. The changes from -05 are: * re-added 6144, at the request of Niels Ferguson, who wanted a smoother ramp-up for people who want to increase adversarial work factor. * made the recommended minimum exponent size more conservative, referencing NIST strength estimates. * added a "private use" sub-range within the ffdhe range for organizations that want to use their own pre-selected groups. * adjusted the false-start guidance slightly. I agree with Brian Smith that this guidance really does belong in the false-start draft itself, but given that it is not there yet, i've left it here. I don't think there will be a problem if the false-start draft simply repeats the same guidance. I did not change the "special form" of the groups. In particular, i left the leading and trailing bits set to 1 for more efficient reduction, since that is used in practice. There appear to be no published attacks against this form (and it is widely used elsewhere, so it should be an attractive target for research), and the concerns i heard were that maybe the group strength could be weakened by the number of bits held constant this way (128 bits, in this case). For people who have this concern, i recommend that they select a slightly larger group, which should more than offset this difference. --dkg From nobody Sun Mar 1 04:03:34 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 67C971A88AE; Sun, 1 Mar 2015 04:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFbTZLGm7k1v; Sun, 1 Mar 2015 04:03:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AFF1A88A3; Sun, 1 Mar 2015 04:03:31 -0800 (PST) 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: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150301120331.16837.45276.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 04:03:31 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-06.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: Sun, 01 Mar 2015 12:03:32 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-06.txt Pages : 25 Date : 2015-03-01 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-06 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 Sun Mar 1 16:41: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 28D671A1EF7; Sun, 1 Mar 2015 16:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR7KbkHl67nh; Sun, 1 Mar 2015 16:41:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D571A1EF1; Sun, 1 Mar 2015 16:41:16 -0800 (PST) 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: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302004116.4584.36898.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 16:41:16 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-sslv3-diediedie-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 00:41:18 -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 : Deprecating Secure Sockets Layer Version 3.0 Authors : Richard Barnes Martin Thomson Alfredo Pironti Adam Langley Filename : draft-ietf-tls-sslv3-diediedie-01.txt Pages : 6 Date : 2015-03-01 Abstract: Secure Sockets Layer version 3.0 (SSLv3) [RFC6101] is no longer secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2 [RFC5246], are considerably more secure and capable protocols. This document updates the backward compatibility sections of the TLS RFCs to prohibit fallback to SSLv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sslv3-diediedie-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 1 17:35:43 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 D845D1A00FF; Sun, 1 Mar 2015 17:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjxPSZ99wADX; Sun, 1 Mar 2015 17:35:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B63881A0078; Sun, 1 Mar 2015 17:35:40 -0800 (PST) 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: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302013540.18740.53850.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 17:35:40 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-sslv3-diediedie-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, 02 Mar 2015 01:35:42 -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 : Deprecating Secure Sockets Layer Version 3.0 Authors : Richard Barnes Martin Thomson Alfredo Pironti Adam Langley Filename : draft-ietf-tls-sslv3-diediedie-02.txt Pages : 6 Date : 2015-03-01 Abstract: Secure Sockets Layer version 3.0 (SSLv3) is no longer secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2, are considerably more secure and capable protocols. This document updates the backward compatibility sections of the TLS RFCs to prohibit fallback to SSLv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sslv3-diediedie-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 Sun Mar 1 20:04: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 9CA611A004A for ; Sun, 1 Mar 2015 20:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgqemzAFtgzC for ; Sun, 1 Mar 2015 20:04:08 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (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 43AC31A0037 for ; Sun, 1 Mar 2015 20:04:08 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id j5so1808732qga.12 for ; Sun, 01 Mar 2015 20:04:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MovSRskBf9xbvv8YSobLptf+o2A/+haSeut+RLheiVs=; b=i77Zjrj15kl0YnV0SxThMiAep49u5/hbQY3/969bf1YJA+HKNcRikOu/eSBddhg/aN s47GDg+j9grR/3Dv0cFwp2Ni80AXxAL0/Qm4OTdZzyChzmjPCCliyANXrOR9/sZHSan6 MPObzrllpkWcZQHGKuH9T4p487JBKD045PIU8ltm6g9SC/qZt4QgUa/1/QmlFRndIVtt rKnFq0rpCXhN1skhUJfU+OWxLAflXHNjQ3sWIr3U5PDqG9XfAIbHtj3f2NzMAovd1v3n BeRcxmFO593XQ0bQELF8fZsgcuNf/puIKc7BFXD954fOQnRB5QbL8qgBcMTXm+qf1Y/A +oqA== X-Gm-Message-State: ALoCoQkC9OLwiCuImWH/2vtV/K69TY6mMdmBetz01xJYn6wbjS5mpzDLfZOIPKhDsIShrQ3X3iZB MIME-Version: 1.0 X-Received: by 10.55.15.202 with SMTP id 71mr5032115qkp.83.1425269047536; Sun, 01 Mar 2015 20:04:07 -0800 (PST) Received: by 10.96.121.104 with HTTP; Sun, 1 Mar 2015 20:04:07 -0800 (PST) X-Originating-IP: [2601:8:b300:a5:91a:d062:7b9:4226] In-Reply-To: References: Date: Sun, 1 Mar 2015 20:04:07 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11473ff849c39a0510464f16 Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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: Mon, 02 Mar 2015 04:04:09 -0000 --001a11473ff849c39a0510464f16 Content-Type: text/plain; charset=UTF-8 There is consensus to move forward with this document. The authors have published a revision, draft-ietf-tls-sslv3-diediedie-02, which covers the comments raised on during the last call . This revision will be forwarded to the IESG for publication. On Fri, Jan 23, 2015 at 11:29 AM, Joseph Salowey wrote: > This is a working group last call for draft-ietf-tls-sslv3-diediedie-00. > Please reply to the TLS working group list with an indication of whether or > not the draft is ready for publication and any other comments you may > have. Please respond by February 16, 2015. > > Thanks, > > S & J > --001a11473ff849c39a0510464f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is consensus to move forward with this document.=C2= =A0 The authors have published a revision, draft-ietf-tls-sslv3-diediedie-0= 2, which covers the comments raised on during the last call . =C2=A0 This r= evision will be forwarded to the IESG for publication.

=

On Fri, Jan 23, 2= 015 at 11:29 AM, Joseph Salowey <joe@salowey.net> wrote:
This is a working group last call for=C2=A0draft-ietf-tls-sslv3-diediedie-= 00.=C2=A0 Please reply to the TLS working group list with an indication of = whether or not the draft is ready for publication and any other comments yo= u may have.=C2=A0 Please respond by February 16, 2015. =C2=A0

Thanks,
=

S &am= p; J=C2=A0

--001a11473ff849c39a0510464f16-- From nobody Mon Mar 2 04:12: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 13EAD1A8727 for ; Mon, 2 Mar 2015 04:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCewydlDyGsQ for ; Mon, 2 Mar 2015 04:12:05 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 BCE7E1A1A66 for ; Mon, 2 Mar 2015 04:12:05 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t22CBxpN019500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Mar 2015 07:11:59 -0500 Received: from pintsize.usersys.redhat.com (dhcp-0-251.brq.redhat.com [10.34.0.251]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t22CBtR3010418 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 07:11:56 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 02 Mar 2015 13:11:54 +0100 Message-ID: <3129450.Wk0h42r8eh@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.18.7-100.fc20.x86_64; KDE/4.14.4; x86_64; ; ) In-Reply-To: <878ufhaptd.fsf@alice.fifthhorseman.net> References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> <878ufhaptd.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2002811.xGXdKPFBed"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: draft-ietf-tls-negotiated-ff-dhe@tools.ietf.org Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 12:12:07 -0000 --nextPart2002811.xGXdKPFBed Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 01 March 2015 13:02:22 Daniel Kahn Gillmor wrote: > On Wed 2015-02-18 13:12:33 +0100, Sean Turner wrote: > > The WGLC has concluded. dkg noted he=E2=80=99d received some comme= nts > > off-list and Watson provide some input. We=E2=80=99ll need a new v= ersion to > > review the changes to see if it should be progressed or whether > > another WGLC is needed. I=E2=80=99ve updated the datatracker to re= flect the > > new state. > >=20 > > dkg, > >=20 > > Any chance of another version before the 2015-03-09 draft submissio= n > > deadline? > I've just submitted -06. The changes from -05 are: >=20 > * re-added 6144, at the request of Niels Ferguson, who wanted a > smoother ramp-up for people who want to increase adversarial work > factor. I also see a change from 2048 to 2432 of the smallest group (page 4, li= ne 35),=20 but no change in the parameters... =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 --nextPart2002811.xGXdKPFBed 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 iQIcBAABAgAGBQJU9FOKAAoJEJKo0bgB0vX1aRQP/31U6dLUqYeIARVcAegve1/p 6dpYzS5dlE4T2gCt68fLqqcG5km7SgMwgeKSYRxYi40Ct1vvaGVtl8At69XMefvc ptf4+JigSp9zVNbb+fEfVeHL2aKA35C6h9jIrD1KdRaIff1HTVudFCLFdTUi4ggJ Cbp3TC/9m/0q96I4CJUOy1+WwWWiz6EoKrk9ADdGbV4yM2VwVk7AN2zTDQgHtD0C cHEIi113omOAAJDTz3obWFxuw8PGIF6UknK8xVm047tpp21Tjaq/LEpDe8TOWUQ7 U/HjZWMEYKi/1R3/c52THKnDEoZq2/CkW7Y5Y9UdLZ4/3iMnY8WFhnuZ7kFDhqGO VFyQtqnz0/JXqIQ5BAmJcCBnt0sw9wPlexS7QeoCpAZaKYNM8PZ8u1/vnalZgVp9 SKg8rpgy1rETj4O9j8FXFx+yQgXIlMpuUTQQ9eT/gqMD7rO5xT0GidyAqrJ3Zz2e zJzHYE+u8/SlJh2qfBty6DTYFNbciFu7dBM2rgO/9ZWKf6QE81ph3+mtjv6iQySQ +pJjG7oDVXFJnZ7o4BdDIJ3IRrd0X/SJVexXkHScwsUVxWLgWlG+7CxpH0DLa7YO oSyjyD2XZQUbw7JSWIRS1nXGpc3/4Tm8TQhR3KMX6l+xpRCoJVvML0HSIw6Llt+B urTwRN1xYz5djVJHDYvx =h7TT -----END PGP SIGNATURE----- --nextPart2002811.xGXdKPFBed-- From nobody Mon Mar 2 08: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 2E54D1A1ADC for ; Mon, 2 Mar 2015 08:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 L3tIT487VPjC for ; Mon, 2 Mar 2015 08:41:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id D0F781A1A22 for ; Mon, 2 Mar 2015 08:41:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 95B8F181D1B; Mon, 2 Mar 2015 08:40:37 -0800 (PST) To: pgut001@cs.auckland.ac.nz, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, joe@salowey.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150302164037.95B8F181D1B@rfc-editor.org> Date: Mon, 2 Mar 2015 08:40:37 -0800 (PST) Archived-At: Cc: dottomi@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC7366 (4284) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:41:22 -0000 The following errata report has been submitted for RFC7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7366&eid=4284 -------------------------------------- Type: Technical Reported by: Tomasz Sobczyk Section: 3 Original Text ------------- The overall TLS packet [2] is then: struct { ContentType type; ProtocolVersion version; uint16 length; GenericBlockCipher fragment; opaque MAC; } TLSCiphertext; The equivalent DTLS packet [4] is then: struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; GenericBlockCipher fragment; opaque MAC; } TLSCiphertext; This is identical to the existing TLS/DTLS layout, with the only difference being that the MAC value is moved outside the encrypted data. Corrected Text -------------- The overall TLS packet [2] is then: struct { ContentType type; ProtocolVersion version; uint16 length; GenericBlockCipher fragment; opaque MAC[SecurityParameters.mac_length]; } TLSCiphertext; The equivalent DTLS packet [4] is then: struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; GenericBlockCipher fragment; opaque MAC[SecurityParameters.mac_length]; } TLSCiphertext; This is identical to the existing TLS/DTLS layout, with the only differences being that the MAC value is moved outside the encrypted data and the definition of TLSCiphertext.length changes to: length The length (in bytes) of the following TLSCiphertext.fragment and TLSCiphertext.MAC. The length MUST NOT exceed 2^14 + 2048. Notes ----- MAC array length is missing. Also, the new structure changes the definition of TLSCiphertext.length. As it currently stands, the length of the MAC is excluded from TLSCiphertext.length. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7366 (draft-ietf-tls-encrypt-then-mac-03) -------------------------------------- Title : Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Publication Date : September 2014 Author(s) : P. Gutmann Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Mar 2 09:44: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 2560C1A8851 for ; Mon, 2 Mar 2015 09:44:03 -0800 (PST) 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 NGNstRWtbpaI for ; Mon, 2 Mar 2015 09:44:01 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::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 B54E51A8825 for ; Mon, 2 Mar 2015 09:44:01 -0800 (PST) Received: by yhai57 with SMTP id i57so15410852yha.12 for ; Mon, 02 Mar 2015 09:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5smJN2oUo+aVMR+KY9xOT5HSzaMKDikgiVu2LnhC4xs=; b=SD4Lh81Vf5SrrTYku62f+r6VB9bhfgkEeLIBu8m9d9Fz7UwB/cNXrc1VEfwV9zL0Cg f4rRQPLEHbDAa6iOheeQFivdYYdoUy79UxOdt4uFW4KGiYTmtdiuo1Yr8Ab7BCOzT9Fy 79Mrs/lFXvlSZrsFXxYa87jw3hhSGrJCTkyj7FSWyXeUBjKR/9qerhi3VWDG3Z3ukden A99JbR3Y0MKwS4J9xZG61+ZSq1PthbwvD0ar9hGheWLq2DnPhP2VkRzMWyn5Ylpg0tw9 2ACMPHf39Tk90o4w/5U16EKUbYwA30e8el/ay5G1F7T4qtOKidMHUwJnisAJIScSm0LI 3o5Q== MIME-Version: 1.0 X-Received: by 10.236.53.162 with SMTP id g22mr26354967yhc.87.1425318240950; Mon, 02 Mar 2015 09:44:00 -0800 (PST) Sender: nygren@gmail.com Received: by 10.170.51.208 with HTTP; Mon, 2 Mar 2015 09:44:00 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 12:44:00 -0500 X-Google-Sender-Auth: H_4b1ps1PKCqNTX0lRfLsGDoF0Y Message-ID: From: Erik Nygren To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a11c2478071a0a7051051c3e5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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: Mon, 02 Mar 2015 17:44:03 -0000 --001a11c2478071a0a7051051c3e5 Content-Type: text/plain; charset=UTF-8 Is it worth adding in a note to section 4 (Limited Capabilities) of: * Server Name Indication to enable virtual hosting of multiple hosts with independent certificates on a single IP address ? I'm not sure if it's critical enough to hold up last-call? It is another major down-side of the lack of extension support in SSLv3 from a deploy-ability perspective. Erik On Sun, Mar 1, 2015 at 11:04 PM, Joseph Salowey wrote: > There is consensus to move forward with this document. The authors have > published a revision, draft-ietf-tls-sslv3-diediedie-02, which covers the > comments raised on during the last call . This revision will be forwarded > to the IESG for publication. > > > On Fri, Jan 23, 2015 at 11:29 AM, Joseph Salowey wrote: > >> This is a working group last call for draft-ietf-tls-sslv3-diediedie-00. >> Please reply to the TLS working group list with an indication of whether or >> not the draft is ready for publication and any other comments you may >> have. Please respond by February 16, 2015. >> >> Thanks, >> >> S & J >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c2478071a0a7051051c3e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is it worth adding in a note to section 4 (= Limited Capabilities) of:

* Server Name Indication to enable v= irtual hosting of multiple hosts with independent certificates on a single = IP address

?=C2=A0

I'm not sure if it's critic= al enough to hold up last-call?=C2=A0 It is another major down-side of the = lack of extension support in SSLv3 from a deploy-ability perspective.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik




On Sun, Mar 1, 2= 015 at 11:04 PM, Joseph Salowey <joe@salowey.net> wrote:
There is consensus to move fo= rward with this document.=C2=A0 The authors have published a revision, draf= t-ietf-tls-sslv3-diediedie-02, which covers the comments raised on during t= he last call . =C2=A0 This revision will be forwarded to the IESG for publi= cation.


On Fri, Jan 23, 2015 at = 11:29 AM, Joseph Salowey <joe@salowey.net> wrote:
This i= s a working group last call for=C2=A0draft-ietf-tls-sslv3-diediedie-00.=C2= =A0 Please reply to the TLS working group list with an indication of whethe= r or not the draft is ready for publication and any other comments you may = have.=C2=A0 Please respond by February 16, 2015. =C2=A0

Thanks,

S & J= =C2=A0


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


--001a11c2478071a0a7051051c3e5-- From nobody Mon Mar 2 10:43: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 42ECF1A700B for ; Mon, 2 Mar 2015 10:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7vlh6XLvtJj for ; Mon, 2 Mar 2015 10:43:07 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 78A8B1A889D for ; Mon, 2 Mar 2015 10:43:05 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id i138so28678856oig.6 for ; Mon, 02 Mar 2015 10:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EVQBxced8IoJGqnCw2Dp1so8RAwlnVRMjxmrsvd7Y4U=; b=XLtIUFWZvFfeYzd+TOGl10SudDEiSFSWCOXo8J8Fyi/l9eVc3LB3HjL39w+Qhuq0Pb Q+Yux3VFeYcfi8KG2C+9VuB+jluoq4JX7biqel2EWbAEx/GBzmqmuS5QA9PrBN5PVL5x SOOVtK5hGOPbp1RS9SSV4RCON0R/uSIsslklRLZOxTaSout0e75TYtNPb21JsJon7mqH mOIMnIII43w/6qDH/5Jp/T8q+S6ws05B4dkxMCeh9MooX95iokpOxT/nu8CwL8iscv5S 1+xVvSEQfElOMJWuBijhiI1lrsE1HKQB77XGuCMXtSXjF39X4AaaAbehGjlOd+8uT24A agCQ== MIME-Version: 1.0 X-Received: by 10.202.9.132 with SMTP id 126mr19214088oij.77.1425321784772; Mon, 02 Mar 2015 10:43:04 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 2 Mar 2015 10:43:04 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 10:43:04 -0800 Message-ID: From: Martin Thomson To: Erik Nygren Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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: Mon, 02 Mar 2015 18:43:08 -0000 On 2 March 2015 at 09:44, Erik Nygren wrote: > I'm not sure if it's critical enough to hold up last-call? It is another > major down-side of the lack of extension support in SSLv3 from a > deploy-ability perspective. Each of us feels a different pain, don't we? We could continue to list the many ways, but I think that we have enough justification without the addition. If a chance comes up, I think that I will add "Server Name Indication [RFC6066]" to the list of missing features though. From nobody Mon Mar 2 12:55: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 059C71A8780 for ; Mon, 2 Mar 2015 12:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUFNLfR5m_0p for ; Mon, 2 Mar 2015 12:55:41 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.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 AF9CE1A8993 for ; Mon, 2 Mar 2015 12:55:40 -0800 (PST) Received: by qcvp6 with SMTP id p6so26940556qcv.12 for ; Mon, 02 Mar 2015 12:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FpG0RTI0i4YQcEWw3vb2rnUSwG/G74hGMmvqJo2CvfI=; b=YxttyO99bpiCmiUvd9HMtfPEXFufKCUm84YNknSn2RNENbqWMW3aH0+6zlNaiP8GlC q++e5i6UAWBLAR6H19N0S4LA/LXZ7Xi/+uUuvy5iMH8lBd4AZpiKUJMBFitDnWjon07g cH25DhWEM+sfL7sXYxr2cyfWevBA5HJvAp4aWw8bpdgGk0EVkrg4i4MB7BBYME3hxtui BTTArFZtkGYPmxuoBzwHRq10AliHIBhz/2Er3d2eTkODPnKVeBR29AYZmoU0dFcKpEcv YRGbiQt+Y176KOOVT15ZETUi1o7J41B7GlChSz1seExRBKCOadnKrJFgAA8teBhohT4d pCfQ== X-Gm-Message-State: ALoCoQnGQAls1UXJ4iTLbm8XjsQlRrd3/M3VA4ZQ09b8BP3dK8J6m6SeqmnFEkjhtlVFmX0QYt7C MIME-Version: 1.0 X-Received: by 10.140.236.73 with SMTP id h70mr53477208qhc.41.1425329739898; Mon, 02 Mar 2015 12:55:39 -0800 (PST) Received: by 10.96.121.104 with HTTP; Mon, 2 Mar 2015 12:55:39 -0800 (PST) X-Originating-IP: [50.206.82.175] In-Reply-To: References: Date: Mon, 2 Mar 2015 12:55:39 -0800 Message-ID: From: Joseph Salowey To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11359476d5b9c605105470e7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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: Mon, 02 Mar 2015 20:55:46 -0000 --001a11359476d5b9c605105470e7 Content-Type: text/plain; charset=UTF-8 I am going to continue to move forward with the publication request. I think we will have opportunity to add this later in the process. On Mon, Mar 2, 2015 at 10:43 AM, Martin Thomson wrote: > On 2 March 2015 at 09:44, Erik Nygren wrote: > > I'm not sure if it's critical enough to hold up last-call? It is another > > major down-side of the lack of extension support in SSLv3 from a > > deploy-ability perspective. > > Each of us feels a different pain, don't we? > > We could continue to list the many ways, but I think that we have > enough justification without the addition. If a chance comes up, I > think that I will add "Server Name Indication [RFC6066]" to the list > of missing features though. > --001a11359476d5b9c605105470e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am going to continue to move forward with the publicatio= n request.=C2=A0 I think we will have opportunity to add this later in the = process.

On = Mon, Mar 2, 2015 at 10:43 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 2 March 2015 at 09:44, Erik Nygren <erik+ietf@nygren.org> wrote:
> I'm not sure if it's critical enough to hold up last-call?=C2= =A0 It is another
> major down-side of the lack of extension support in SSLv3 from a
> deploy-ability perspective.

Each of us feels a different pain, don't we?

We could continue to list the many ways, but I think that we have
enough justification without the addition.=C2=A0 If a chance comes up, I think that I will add "Server Name Indication [RFC6066]" to the l= ist
of missing features though.

--001a11359476d5b9c605105470e7-- From nobody Mon Mar 2 13:04: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 0736B1A88A3 for ; Mon, 2 Mar 2015 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 tP1SSlsyXNyM for ; Mon, 2 Mar 2015 13:04:41 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1E35C1A898B for ; Mon, 2 Mar 2015 13:04:40 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 39FF416593A for ; Mon, 2 Mar 2015 21:04:40 +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 2ED4B165918 for ; Mon, 2 Mar 2015 21:04:40 +0000 (GMT) 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 195DA1E0D5 for ; Mon, 2 Mar 2015 21:04:40 +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.913.22; Mon, 2 Mar 2015 15:04:27 -0600 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.0913.011; Mon, 2 Mar 2015 15:04:27 -0600 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: Interim meeting -- logistics? Thread-Index: AdBVLF14apI1cORxTJWD2EXxiB/ahw== Date: Mon, 2 Mar 2015 21:04:26 +0000 Message-ID: <2016c39a0564413ea2593dbbbe643a77@ustx2ex-dag1mb2.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.45.125] Content-Type: multipart/alternative; boundary="_000_2016c39a0564413ea2593dbbbe643a77ustx2exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Interim meeting -- logistics? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 21:04:43 -0000 --_000_2016c39a0564413ea2593dbbbe643a77ustx2exdag1mb2msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess the question is mainly about hotels, since just fly into Seattle fo= r two all-day meetings, right? -- Senior Architect, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2016c39a0564413ea2593dbbbe643a77ustx2exdag1mb2msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess the question is mainly about hotels, since j= ust fly into Seattle for two all-day meetings, right?

 

-- 

Senior Architect, Akamai Technologies

IM: rsalz@jabber.= me Twitter: RichSalz

 

--_000_2016c39a0564413ea2593dbbbe643a77ustx2exdag1mb2msgcorpak_-- From nobody Mon Mar 2 13:26: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 B66CB1A1BE0 for ; Mon, 2 Mar 2015 13:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, 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 TE53zvnUbYIx for ; Mon, 2 Mar 2015 13:26:00 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (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 013D21A89A9 for ; Mon, 2 Mar 2015 13:25:55 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so24972751qac.8 for ; Mon, 02 Mar 2015 13:25:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xx/J4GtS+B2JMvkuHV/E7yVzaqUj0Y3kjprlzm2TnPE=; b=QSFc6/3m2OrTc2QfQCEspWmJw6f+lC84EYQBOvu7CX9HXo3nra2MWa9vxYUuUQmng0 q8Kb0jh+lkw1501VwaW8uexXQc8oX0YF8G5Rgxii0AxE3XI8lAvH1BQnemGCTGeaGuxJ 9POxDQd0wbiiPHeaFaKO7n+2f4SKcz7IGIIiVpaThtSqhMs0Jjy1rhnHKW5q8Qa5qFaD ZR7cFw696O1cXRBIVutxXt/WpXbFY9d0uRGz5YNswOBJt1eLXB36nMpUpWKrnmXrexjm tsspYI8C+ao6L92A9glNoXlx6hD0SCDtpneKgXqhRYxT90aVcaYJ+ndiD6pO96YUlxOV i4Fg== X-Gm-Message-State: ALoCoQmTjgl6kRLep3qx1scSmbsa99jijP1fzsCGKQfchhAKlQ0ipAeJpOB10KfjWds1jRyplkTU MIME-Version: 1.0 X-Received: by 10.140.236.73 with SMTP id h70mr53721909qhc.41.1425331555210; Mon, 02 Mar 2015 13:25:55 -0800 (PST) Received: by 10.96.121.104 with HTTP; Mon, 2 Mar 2015 13:25:55 -0800 (PST) X-Originating-IP: [50.206.82.175] In-Reply-To: <2016c39a0564413ea2593dbbbe643a77@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2016c39a0564413ea2593dbbbe643a77@ustx2ex-dag1mb2.msg.corp.akamai.com> Date: Mon, 2 Mar 2015 13:25:55 -0800 Message-ID: From: Joseph Salowey To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11359476095588051054dde9 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Interim meeting -- logistics? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 21:26:02 -0000 --001a11359476095588051054dde9 Content-Type: text/plain; charset=UTF-8 Yes, The location of the meeting is at: 401 Elliott Ave W, Seattle, WA 98119 there are a number of hotels that are nearby and in the downtown area. I haven't stayed in any of them. The Homewood suites is very close by (essentially across the street). There are some more upscale hotels like the Pan Pacific or Edgewater that are a little bit further away. Cheers, Joe On Mon, Mar 2, 2015 at 1:04 PM, Salz, Rich wrote: > I guess the question is mainly about hotels, since just fly into Seattle > for two all-day meetings, right? > > > > -- > > Senior Architect, Akamai Technologies > > IM: rsalz@jabber.me Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11359476095588051054dde9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, The location of the meeting is at:

=C2=A0401 Elliott Ave W, Seattle, WA 98119

there are a number of hotel= s that are nearby and in=C2=A0the downtown area.=C2=A0 I haven't stayed= in any of them.=C2=A0 The Homewood suites is very close by (essentially ac= ross the street). =C2=A0 There are some more upscale hotels like the Pan Pa= cific or Edgewater that are a little bit further away.=C2=A0

Cheers,
<= br>
Joe
=


On Mon, Mar 2, 2015 at 1:0= 4 PM, Salz, Rich <rsalz@akamai.com> wrote:

I guess the question is mainly about hotels, since j= ust fly into Seattle for two all-day meetings, right?

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

IM: rsalz@jabber.me Twitter: RichSalz

=C2=A0


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


--001a11359476095588051054dde9-- From nobody Mon Mar 2 13:45: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 9D1281A89AA for ; Mon, 2 Mar 2015 13:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckWN_X0yOCTL for ; Mon, 2 Mar 2015 13:45:10 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003: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 524DE1A89A5 for ; Mon, 2 Mar 2015 13:45:10 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id i138so29644377oig.4 for ; Mon, 02 Mar 2015 13:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mhQWKMn037ldbvV9zUD5TayU6RJFgHShBE+KSo9xZHY=; b=gqEYRfXj5PbJUh0cVsk4GUuLH2SqKr6vcDv7T9gXhwDEQyKi9+9bfb5ql8fUT6In3A 3/vGgTz5dh8CAQtvtY9XqfwvJzqPBc8BTq7Z6ePMi/1btNGye1Ix0ChYCxbN2E34gHpB IcV73Q+VPo1gtWMHRSAce16qHxpI6Uo3PlavYaNZDubWjuNHmQnshptUCwgCbBYRq9s8 x135sWDGljbQs/4BbrfD6i0WiewEDyh1ba41vbkMfCMmO3pkNFgA7L/yNw0WOc5bB7cW F61aCH+J96XQQXeuElOCl0WgOfGjgqgfZz6q8vziZrvRYbCXZt48x0TF84RTdDkyuiHz wGIQ== MIME-Version: 1.0 X-Received: by 10.182.81.40 with SMTP id w8mr9189142obx.61.1425332709597; Mon, 02 Mar 2015 13:45:09 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 2 Mar 2015 13:45:09 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 13:45:09 -0800 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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: Mon, 02 Mar 2015 21:45:11 -0000 On 2 March 2015 at 12:55, Joseph Salowey wrote: > I am going to continue to move forward with the publication request. I > think we will have opportunity to add this later in the process. Indeed. I'll prepare a PR for it and merge it if an opportunity arises. The IESG has a habit of providing that sort of opportunity. From nobody Mon Mar 2 15:21: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 6BA3E1A8AB1 for ; Mon, 2 Mar 2015 15:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 hoolcQaRU7QL for ; Mon, 2 Mar 2015 15:21:03 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.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 C41201A8AB8 for ; Mon, 2 Mar 2015 15:21:02 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id n8so25544329qaq.3 for ; Mon, 02 Mar 2015 15:21:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rnep7eltOBERsI9q3fbjk8KwvqIAxhN4MXVTboZ3WOg=; b=DONxqLA8uFd8AXyutBDZTss4rXZCnAiQwXJAuf3HAfR3sk+rmJ/4FlXdYZX2umVxMH nEeQ199NVGU8+TvThh69TbRah+slX+14dzstAXrDVPxIlbTSF8j1XoEpp0Zn60GWOHgm JJe+sNuVi/Wgjw9rP1MdFHfI16MUfHvZZUgz7oRVvCpRx05cRbnlXCrT0/w1rJowJzzd 7lhB3VH0ZYqXiEL+u8zlqwq91Q80N5OFkeWHbCO+xFaBA5DQrcfSZjhdYEegV8naOSci AyjlEwolc8CelqcAvvvGsKSt9Ac75O6MxMZHVHfotxpG9V2JawiwS/wF4+QCWa2pOP5X /KoA== X-Gm-Message-State: ALoCoQmWGiy0T5Mt2/H3Llv+78snbHSwL7facBemBgRMbNBhWU0RR1yAaiBcS3hej2eVzGL+UCtd MIME-Version: 1.0 X-Received: by 10.55.40.3 with SMTP id o3mr7640322qkh.7.1425338462119; Mon, 02 Mar 2015 15:21:02 -0800 (PST) Received: by 10.96.121.104 with HTTP; Mon, 2 Mar 2015 15:21:02 -0800 (PST) X-Originating-IP: [50.206.82.175] Date: Mon, 2 Mar 2015 15:21:02 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11441516b83d920510567896 Archived-At: Subject: [TLS] Working Group Last Call for draft-ietf-tls-padding-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 23:21:07 -0000 --001a11441516b83d920510567896 Content-Type: text/plain; charset=UTF-8 This is a working group last call for draft-ietf-tls-padding-01. Please reply to the TLS working group list with an indication of whether or not the draft is ready for publication and any other comments you may have. The document does not currently list an intended status so please indicate what the appropriate track should be: standards track, informational or possibly historic. Please respond by March 17, 2015. Thanks, J & S --001a11441516b83d920510567896 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a working group last= call for=C2=A0draft-ietf-tls= -padding-01. =C2=A0Please reply to the TLS working group list with a= n indication of whether or not the draft is ready for publication and any o= ther comments you may have. =C2=A0 The document does not currently list an = intended status so please indicate what the appropriate track should be: st= andards track, informational or possibly historic.=C2=A0 Please respond by = March 17, 2015. =C2=A0

Thanks,

<= /div>
J & S
--001a11441516b83d920510567896-- From nobody Mon Mar 2 15:24: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 5FE541A8AAD for ; Mon, 2 Mar 2015 15:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oew4MQkd-wYt for ; Mon, 2 Mar 2015 15:24:33 -0800 (PST) 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 5EB7A1A8AAB for ; Mon, 2 Mar 2015 15:24:33 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id CF8C62AB5B; Tue, 3 Mar 2015 00:24:30 +0100 (CET) X-purgate-ID: 152705::1425338671-0000765A-5CD806B8/0/0 X-purgate-size: 1109 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 800754266C; Tue, 3 Mar 2015 00:24:30 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 707871B1F3; Tue, 3 Mar 2015 00:24:30 +0100 (CET) In-Reply-To: To: Erik Nygren Date: Tue, 3 Mar 2015 00:24:30 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150302232430.707871B1F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 23:24:35 -0000 Erik Nygren wrote: > Is it worth adding in a note to section 4 (Limited Capabilities) of: > > * Server Name Indication to enable virtual hosting of multiple hosts with > independent certificates on a single IP address > > ? > > I'm not sure if it's critical enough to hold up last-call? It is another > major down-side of the lack of extension support in SSLv3 from a > deploy-ability perspective. Your notion seems to be based on a urban legend. SSLv3 (the protocol), in the final, after-the-fact publication of November 18, 1996 (which the IETF failed to publish for 15 years, but finally did as https://tools.ietf.org/html/rfc6106 ), has _the_exact_same_ support for extensions as TLSv1.0. Implementations of SSLv3, however, do not necessarily make use of that capability. SNI has only limited value, and provides an additional attack surface, e.g. https://bh.ht.vc/vhost_confusion.pdf Personally, I'm much more concerned about newer software that breaks horribly when no TLS extension SNI is present in the ClientHello, such as Microsoft ADFS 2012. -Martin From nobody Mon Mar 2 17:59: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 492841A9096 for ; Mon, 2 Mar 2015 17:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN9PbJa2Uqwf for ; Mon, 2 Mar 2015 17:58:58 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::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 86CBF1A90A7 for ; Mon, 2 Mar 2015 17:57:11 -0800 (PST) Received: by yhaf10 with SMTP id f10so16726861yha.8 for ; Mon, 02 Mar 2015 17:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mDGTRf9x9Bxr6PFZQoiAeXyGKoAq69F/IoTfNHtuhW4=; b=pRdgj8VAnq7IoB7ckdyLS/Q8GNOk6fEPw25jtK4oTqZpBi93Iv3n6NLE2n9iRZLsQy DhTN7if3mHpgQBjLc+P2xvxv4g1EEqdAyFPgaJCjt5F+OAAQoKmJyNbIkpGrgPLfNbcT ntxv/w8ZpahpnjSWAoWnm2akdhXpnMrsSCcW9QfSCI1VXmxKqss+zMlRmMR3RQFvhxQ6 l1wueL7JnXDBatrj861bxFwMTbOHE1s6feZM5EUVSNwI19d57pnms7JbHbzwiwxZBUkE 4csohJ2+VAGzaS0cxWGWA3HQj4euPHq+ZQqevrHg1fSKOqZZWMkR5g02EFQnhF7NcyGy GjrA== MIME-Version: 1.0 X-Received: by 10.236.1.38 with SMTP id 26mr28520795yhc.163.1425347830746; Mon, 02 Mar 2015 17:57:10 -0800 (PST) Received: by 10.170.126.210 with HTTP; Mon, 2 Mar 2015 17:57:10 -0800 (PST) In-Reply-To: <20150302232430.707871B1F3@ld9781.wdf.sap.corp> References: <20150302232430.707871B1F3@ld9781.wdf.sap.corp> Date: Mon, 2 Mar 2015 17:57:10 -0800 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-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, 03 Mar 2015 01:59:00 -0000 On Mon, Mar 2, 2015 at 3:24 PM, Martin Rex wrote: > Erik Nygren wrote: >> Is it worth adding in a note to section 4 (Limited Capabilities) of: >> >> * Server Name Indication to enable virtual hosting of multiple hosts with >> independent certificates on a single IP address >> >> ? >> >> I'm not sure if it's critical enough to hold up last-call? It is another >> major down-side of the lack of extension support in SSLv3 from a >> deploy-ability perspective. > > > Your notion seems to be based on a urban legend. > > SSLv3 (the protocol), in the final, after-the-fact publication > of November 18, 1996 (which the IETF failed to publish for 15 years, > but finally did as https://tools.ietf.org/html/rfc6106 ), > has _the_exact_same_ support for extensions as TLSv1.0. > > Implementations of SSLv3, however, do not necessarily make use of > that capability. Actually, the RFC you meant was RFC 6101 (https://tools.ietf.org/html/rfc6101). The word extension doesn't appear in the draft, instead all we see is a forward compatibility note, stating that extra data may appear after the hello. It's true that RFC 2246 doesn't mandate extension support either. But RFC 3546 defines extensions for TLS 1.0, not SSLv3.0. Of course, you could say that SSL v3.0 extensions should be supported the same way as TLS 1.0. But there's no indication that this is actually what the documents mean, or how servers and clients are actually implemented. > > SNI has only limited value, and provides an additional attack surface, e.g. > https://bh.ht.vc/vhost_confusion.pdf Multitenancy is incredibly common, especially given IPv4 exhaustion. Absent SNI, there is no good way for CDNs to function. Sincerely, Watson Ladd > > > Personally, I'm much more concerned about newer software that breaks > horribly when no TLS extension SNI is present in the ClientHello, > such as Microsoft ADFS 2012. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Mar 2 22:03:43 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 5420D1A0155 for ; Mon, 2 Mar 2015 22:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrfrY7EI3IzD for ; Mon, 2 Mar 2015 22:03:42 -0800 (PST) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::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 E807A1A0154 for ; Mon, 2 Mar 2015 22:03:41 -0800 (PST) Received: by yhoc41 with SMTP id c41so386629yho.13 for ; Mon, 02 Mar 2015 22:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MPioH7HESdzI2KxpJGiLuj3xTf2uc8+jbe7sY0wK6CQ=; b=KiXxuywQq5NJlnoQY0460/etpBmzZp6zadgUEO+vOrQD/UaUHQypgBJp3JkGpoNQxn FwFpSXMj5Yb01WhnbHW1Yuw7v50dWkWCyWyWObJuvZ8IUf3FIsHuds7J0e/Iomhg2XVw 7srW5m2zfXzsdyXh10eHtYlSRfbHNMcByaNSS5UHeXqhoRL2YjXf98vRnisu36tkczZl YCZDVl8TknvENEHHnLrbT8bt495u2dSrGKxBTo5Bq1fMx2EU9dIFPbdeJi4DflB1lqSW daUFHC5qHOMYesB3yKNSBUX6ASRWolQfUVtPgdP91nBDCTtvyjqPSB3MJy7xOabQYQCm 1vew== MIME-Version: 1.0 X-Received: by 10.170.220.197 with SMTP id m188mr32085379ykf.58.1425362621195; Mon, 02 Mar 2015 22:03:41 -0800 (PST) Received: by 10.170.58.198 with HTTP; Mon, 2 Mar 2015 22:03:41 -0800 (PST) Date: Mon, 2 Mar 2015 22:03:41 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] How to reduce number of verifications X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 06:03:43 -0000 Dear all, Right now it looks like browsers will need to conduct a lot of signature verifications. First, they will need to verify the certificate chain. Second, they will need to validate OCSP. Thirdly, they will need to validate CT records, when Certificate Transparency is deployed. Most of these signatures are not online. All of them can safely be done with currently deployed RSA 2048, or a 255 bit elliptic curve. None of them require more security, as future cryptanalysis cannot affect today's authentication. We should consider carefully studying which combinations of algorithms for which signatures will provide the most performance, as well as how we can minimize the number of verifications that will take place. I've not done that much in this direction: it comes down to the marginal cost of batch verification of Schnorr-like schemes vs. straight RSA verification when we don't have online signing. Sincerely, Watson Ladd From nobody Tue Mar 3 06:07: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 247121A7D83 for ; Tue, 3 Mar 2015 06:07:53 -0800 (PST) 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 AHHQh2uqsTIH for ; Tue, 3 Mar 2015 06:07:52 -0800 (PST) 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 F23C11A1A4C for ; Tue, 3 Mar 2015 06:07:51 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id a108so22911114qge.8 for ; Tue, 03 Mar 2015 06:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AnBVn28P33pCh9dHt3aqB44+tUl2HlLp1Ql6S/2Q+OQ=; b=QkY6iA0sBzUk+qJItGZnFqZBjFHKsAE/8yVzDJyFIcAG/k3D47F2jLzuI6qNRutHAi 8ihlI3pHZfLzXDQS6klP0G1PcitgDMQqSfCIEg9gHlaYQpKldq37I7DNA8fEDCRzw9uD HddSZwmVPOpEuL1C/KVSMyzH5HkLf49B9O8NSPAfNbt9R8kXaUK3weaij/4JIQrHtpsL klMwVgns+fvcAfjntbMb4S4LNsnTom/ltihd1idQKqdGjLILwVd3yl8ZvXabmdyMVZSp F+4TTcNAURUVC+PYe8QEnHUX2C9prnJQlhHAiTiR9A3X1pfpji2xXl7dg26Wf6wx+EA5 R/7Q== 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=AnBVn28P33pCh9dHt3aqB44+tUl2HlLp1Ql6S/2Q+OQ=; b=BaysbsoqvlQiYPM2U2FvyeSKWNXk7S4ekseZCrTPHeNn46uDtpdguJEvbGe3oJQZyM lhknojOFgXJk/dvY+lxHjkQbsqlm9+oiv/LsJiEkUzOhyvtFlI54q0JwIZ/IwLE+ZtLH +PKgJZp3WCaTdgahM0m7iF/7ElXXOCf/UjH67j5M3WA4xdBmIWI0w1tj2epmxwDag/7L jnLlY12MkRg6VLBgL5HWH755zugtGW9QE0bCr3wn74bHwgTNifTmnQzAGpYFymWHV5j3 ydGxrMcvz6WE4Gszd2pacaK9jGlHpkUDG4z/sQdBzN6pvZwV27Kwx/oMS3xFICzTHmJ1 UgUw== X-Gm-Message-State: ALoCoQklFj3T+ro1yWgrnzYhF5v41W4NsMZh5yXYfZMUthY/4GpZobOMlqV8IiC2Xw/pq3MdwlL3 MIME-Version: 1.0 X-Received: by 10.140.38.100 with SMTP id s91mr54828475qgs.37.1425391671075; Tue, 03 Mar 2015 06:07:51 -0800 (PST) Received: by 10.229.184.66 with HTTP; Tue, 3 Mar 2015 06:07:51 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2015 14:07:51 +0000 Message-ID: From: Ben Laurie To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c13334388f15051062dcf3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] How to reduce number of verifications X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 14:07:53 -0000 --001a11c13334388f15051062dcf3 Content-Type: text/plain; charset=UTF-8 On 3 March 2015 at 06:03, Watson Ladd wrote: > Dear all, > > Right now it looks like browsers will need to conduct a lot of > signature verifications. First, they will need to verify the > certificate chain. Second, they will need to validate OCSP. Thirdly, > they will need to validate CT records, when Certificate Transparency > is deployed. > FYI, CT is already deployed for EV certificates. > Most of these signatures are not online. All of them can safely be > done with currently deployed RSA 2048, or a 255 bit elliptic curve. > None of them require more security, as future cryptanalysis cannot > affect today's authentication. > Insofar as CT is also a record of history, it is possible that one might want to re-sign existing trees at some point (or, rather, re-publish them with different algorithms). --001a11c13334388f15051062dcf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 March 2015 at 06:03, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:
Dear all,

Right now it looks like browsers will need to conduct a lot of
signature verifications. First, they will need to verify the
certificate chain. Second, they will need to validate OCSP. Thirdly,
they will need to validate CT records, when Certificate Transparency
is deployed.

FYI, CT is already deploye= d for EV certificates.
=C2=A0
Most of these signatures are not online. All of them can safely be
done with currently deployed RSA 2048, or a 255 bit elliptic curve.
None of them require more security, as future cryptanalysis cannot
affect today's authentication.

Inso= far as CT is also a record of history, it is possible that one might want t= o re-sign existing trees at some point (or, rather, re-publish them with di= fferent algorithms).

--001a11c13334388f15051062dcf3-- From nobody Tue Mar 3 11:02: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 A0EF81A8770 for ; Tue, 3 Mar 2015 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, 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 M2HE5Dah_lcN for ; Tue, 3 Mar 2015 06:41:34 -0800 (PST) Received: from itu4out.svc.unicc.org (itu4out.svc.unicc.org [206.155.102.67]) (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 085351A8765 for ; Tue, 3 Mar 2015 06:41:32 -0800 (PST) Received: from TUCM03.TUECSP.UNICC.ORG (unknown [10.81.38.70]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iccpfxor04.svc.unicc.org (Postfix) with ESMTPS id A53B8614DD; Tue, 3 Mar 2015 14:41:30 +0000 (UTC) Received: from TUCM03.TUECSP.UNICC.ORG (10.81.38.70) by TUCM03.TUECSP.UNICC.ORG (10.81.38.70) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 3 Mar 2015 14:41:29 +0000 Received: from TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) by TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) with mapi id 15.00.0847.030; Tue, 3 Mar 2015 14:41:29 +0000 From: "TSB SG16 Secretariat, ITU" To: "3GPPLiaison statements (3GPPLiaison@etsi.org)" <3GPPLiaison@etsi.org>, "'Susanna.Kooistra@etsi.org'" , "'tls@ietf.org'" , "'mankin@psg.com'" Thread-Topic: COM 16-LS 142 - Outgoing LS from ITU-T SG 16 meeting (Geneva, 9-20 February 2015) Thread-Index: AdBVvyr6FfGB7GpJSXCJzpgWrIHy9w== Date: Tue, 3 Mar 2015 14:41:28 +0000 Message-ID: <0fb6887f5f964458a8f8e4c1d8db7fe2@TUCM03.TUECSP.UNICC.ORG> Accept-Language: fr-CH, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.102] Content-Type: multipart/mixed; boundary="_007_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 11:02:00 -0800 Cc: "Campos, Simao" , Christian Groves Subject: [TLS] COM 16-LS 142 - Outgoing LS from ITU-T SG 16 meeting (Geneva, 9-20 February 2015) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 14:41:37 -0000 --_007_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: multipart/related; boundary="_006_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_"; type="multipart/alternative" --_006_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: multipart/alternative; boundary="_000_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_" --_000_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Kindly find attached the Liaison Statement COM16 - LS 142, agreed at the I= TU-T SG16 meeting held in Geneva, Switzerland, from 9 to 20 February 2015 i= nclusive. Best regards, Rosa Angeles-Leon De Vivero Administrative Assistant for ITU-T Study Group 16, IPTV-GSI, JCA-IPTV & IRG= -AVA International Telecommunication Union Place des Nations, CH-1211 Geneva, Switzerland Tel : +41 22 730 5445 tsbsg16@itu.int tsbiptv@itu.int www.itu.int & www.= itu150.org [cid:image001.jpg@01D0550D.53D92560] --_000_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,
Kindly find attached the Liaison Statement COM16 - LS 142,  agreed at = the ITU-T SG16 meeting held in Geneva, Switzerland, from 9 to 20 February 2= 015 inclusive.

Best regards,

 = ;

Rosa Angeles-Leon De Vivero

Administrative Assistant for ITU-T Study Group 16, IP= TV-GSI, JCA-IPTV & IRG-AVA

International Telecommunication Union

Place des Nations, CH-1211 Geneva, Swi= tzerland =

Tel : +41 22 730 5445
tsbsg16@itu.int

tsbiptv@itu.int   
www.itu.int & www.itu15= 0.org

3D"cid:image001.jp=

--_000_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_-- --_006_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3939; creation-date="Tue, 03 Mar 2015 11:11:38 GMT"; modification-date="Tue, 03 Mar 2015 11:11:38 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAmAFEDASIA AhEBAxEB/8QAHQAAAgICAwEAAAAAAAAAAAAAAAkGCAMHBAUKAv/EADYQAAEFAQACAgEBAwgLAAAA AAQBAgMFBgcACBESEwkUFSEXGCNRVliW1hkiJDFUYYGSl9LV/8QAGwEAAgIDAQAAAAAAAAAAAAAA BgcAAgEECAn/xAA2EQACAgIABQICBwYHAAAAAAADBAIFAQYABxESIRMUUWEWGCJBVmZxFydFRldi gZGWl6HW8P/aAAwDAQACEQMRAD8A90+o7XyrFbfL831O3pabc7RwzcvmSnkOsrdTTHgB/hZBBLHE hRkco47ipIGzSRSpGrkjerZFuN/ieaUE2q6BqKXIZwcgcSa5vjoa8BhRb1YMOs8zmtWadyOSONPl zka53x9WuVPPb0jhA3Cv1LvVytTofQOl2Omu8bf2mj6NaxXN7IVLf2wSQIdHDA5wscIMawxvav4f u6KNEjRqJYz9U7cVW56n61erJGirKGq0mtrdfvrGztIK2vrKk6wXPVktkQQ+KGBsdcunLiWSeP8A pUFX6uSRnnQMOT9I3f8ALmtq72yfqdq1Z7aby49jgElEas1nl8lehMeTChgKGF1oNzOQzRBzziET RBBDS5tXStDzBsrOjrkbTWNnS1ilqPe5Php6yFWxSG+8OeAlnkz+TsTUgEYVRzjjM5CkebF/56fq b/eD5Yq/1Jq69V/6Ikiqq/8AJE+fN+rqqH91Ul6yxHmpNCtX+6beF6SV5TLxkb6edpCL9EHsvzjs EnX+jkkIgb9kWVnzVet9F/SqzCFPquG83swJ4mPFsAVJOGKiRERssRg9nJEQj0T5dK2R6SKqq5zl VfnQvtBt9n1nq+b9COEWEWJDJywdv2bdBBKQ7Fc/hGheBmaGNjPxg2hddEGrJUmHJ+bKlGDnGjfY EwB4NZ1DZLRZDUmNmTXSBYWe02W2jqwKU1JXjFNh+EamTJyEFmUxxWyPJWWiJprwmZjwWn2Tbder GH9qW1xs7hkK7Wa3VSWR27e5fnOAEZStIrAGMvSJMsRJgS6o2m2JwCvnObvbb2I4Rzc99Vu+vc8y tpG/8ctZcaunFsoH/ZW/UgBSlLHX7NVFSeGP4+F+fJhi+k8+6OG+wwO2y2yDi+PzT5q9rbhsH2+P qhCAkTPHVfs34SZrFX5T4T+PiKfVrnnp1pb3pHEn5SLe+wWe1W1rM/relwviE3teOaSoV8lXrxJx 6izq0Rg1/nR6ws8qcOayDdYCzy/sc70Xorf4zfwa7g91pePdJCBfehMzNdZw00KQNIHsBbhsTn56 3z0NmlahC0QkMU8Nw2WfNnQjzDIX2PK/R0XGKJvZtlorcSwmU7HYaFYFTZCMOJV3cV6jjFsjVMwl 1g7LLjAcxmM6EWRkXiKV/MrdXk17xTW9cu6kjJFnK+hvGT2lcUJMiOnl9tNeqdtF547ZpxwoAvcM gXpLFGxJ5skjIo5JZF+scTHSPd8K74Yxqucv1aiuX4air8NRVX/ciKv8PK2j+3vr0RiNX0RvQR4s ri9CPk78smnvxjoNOZG2UGgEpp6uO4srU9j2uDCABImnRVcxv1a9zej9PPYgr2H5gTY6avhpOl4O 9Mw3TaSBqxjjaeqRqOsQo1c9GV9xAqFwRskligIaYJDORCMyeVc/UGHyajrA+dgEn2836lnEf5PR 7Vzo8zNqx8qKTEzVuhRS2UP7sis3TPrmusEMUVR0cv3RRnWOXgGr3Ytc2eLqdjQsVvqzSdUGtkBb VVJzOSlTaHNdlVwbidoMvtwLR91JZ0RIxiRbLv5lqTX9g1uabdfer2UhRdSaIx646xhtTGBCcVJB hdpYijdYQeDnYl7WLKRRylNqwnsnxM7kVh3QfeVq8wqElZbaKUewgdWGQmQV81UfVTCR24txGeUM G6qmBad+0TxNSFUkY5cHTPZnjHH3ZWLoOrmpCtrWz2+bAioNDbWVjXisFeUQlfT1Z5cDR0NGSdpE MTonSo17Wq131UGVXb7bZnNceilylRvN5+on1EzpwtgIfZc6I0uDrotmNWAhiyCWx2Ql/DVkIOTL AcRYCuUl8cLU+uxi971DvIfI/ZWh6dz/AJN2HnfBPY6c3JQUE2sn0EmS0L6i3tM9S3UbgIc6eTnQ 4izTrH95VSFuiFGMSRZICmfKWiWbAVl9vNUWwvRllh+MSgU9jY/RTBGU6C0nkVla0V2Ju2BVsBwk FU/sFcnxnIzDmrdsqHEsipG0EhRlHjKMpCOzl2u+lGRrt3tZDBa+rvKUqlUeyAbLh2Q5eawHOIsM /nm+u/8AbSy/wPu/8t+HiKP9MT7Nf2b5l/h+0/8AreHhr9VrcvwrL/cSn+X5P+f/ADj/ABDvrN6f +J4f6Atv+2/+65+XSVeyftZw3ee+/rV2TL6wuw57hW5VNTdrm9EM6tdXaG7LKRoBNbFYGfjGLHk+ RRpfn8itb9lY74cJsPXP1O908zT9Uu8YFqG6+kEfSb+vfc5jVPqxHEjhNQuF4JrWhS/tDYg7MWaK J/2R46oqou7n8B4U1j3Jxbl0ita5yMZgcp93qiKqMb9qxrfs74+G/ZzW/Kp8qifx8X0D+oJpuQFH 4Tp/ph1nCj0pdiNlBud0YZ1A+ggKelVEyGdtLUQTKM5qzyUllZAzyq+aCOGN7WeCprl3d09aFymr dopbzQKsVOJgm40wLFmmabedzkK4AUrrrEXS490RPJFgrRDFhSMiRNknDTqaW3sJealjrNxS73Zl tyghqNweuWuVlUE8YMwc1wkkvJQefbDdwNgzEiyXalgcwxoxt5OnfpVezWHqcnur3aev3RnQWK5W 9JdJ9qRli2vvq+cOJra+HR0DZ4i6u6rBgXHsnBjLjbCpo3n33Erodb7Yd8pMIuwh6Jqe58P2VcVm m2zprXlTspYsgWeSrehElGGbb52MwR6KGk7YlJaiQOVuytRy7uf6mHsHz7farlug4p69c7HHgFl2 Mc4mguq+SwZZ3LBBp4RJC7m9fCOA14I76mnEggnfZFzMfGWwD249Sr/pFzjO18OsQs13LmY4gVdC ZPKBUbrMgFIaPlrg+CWGUScWf8jqs6aX8CNImFKkH/2OxrWaxulFR3GnD21ihnvtxp7tVvdkOSbN aC0Xu6q21SOzsVfqqFYJCsmndlHkhFcMhYZlhdYeMLdfTry6qNtJqq95DRanbUrTSK4kW17A1YxS 2VXtEtaBZ+m0NccrGDdMMmBjZysVdaOTsElmjvsL6/HA+42Cu8hynpd5S3mcvtrtR4tdfZ+LQdJr ydHZSy0WwksXUINzOOPWE0dLHY1wNnO0SobEKwuf8UFo/YXd3bPcTK0sfYL7X7m10TOXQV1NsLbQ 52HQGAgCVBEdI6xj59NSFDOW/gsiqmGvSFqiOJT4lWzes917JuG0fK/ZP1u7NTWV3TPoNBTxVFo6 uKjOjSEgqh32ca1bAEaRPvAYMGNYtesEkJh3+qVMvvjvC+nT7Te3nqpxrpxw2ho2wA9b7jULlLjB FzTHN0TcgMzYQ5vYlEhEJHTT2wRJcREUJD6+ItjpX7msidY1+eN7URQlr9bUoUFy9Zqt67bxQvhW +Wy7AW2mlAWcjVVMBNcjLtUtMCZ7Rj2aimrsRkwX0foO289G/sLV+9qEa1pbYKnL1HOpwoKhFVwb kbGJsshK4wNdO0ZidsFYvhtptgH6X9RoB9/7SWJpk5tfHZczzlsRJaR28c/QqTPHt2yodE+SMgmG znewp7ZJl+72O/M9j43O4Wi0XMt10jWYTV8O0lTy7r3tRaZSDqA3QrSr34/eOc5lpAe5y+fGDHKo KCEavnBrbMCwmav2mInZKkzRGsF9WORYnh/Hs9z/ABUFw1oP5DtGdo66ar0Vxpz0a+1s7kOb7fhn kfGwYYeGUgYQAUQQcgiOFJ5KY6LtHMeq+9jMxot5R18HAaS0yPLceTLOp257pu68kK7sq6KOJ486 ZaphWhF/K9r47mV8w7mfLlepw38dl33mFeVtdaHr0tdHIVgme1rnFAa2gjVUtnFGsNGUmnrlSnbg J4rKlWtJphkDQ1ZkG0S0Odd0bQaWxsKwL7mwTiVBwNW+m2XYrByzuazLtkKUIqpU7NspMiQl2rJi Ky6x1ptQGSv2GOxvSOe4/nNL6/3FTR7SDqXefX/cN7xdA9I0OqxVs6i2N9t9nDXSWud0eip2ylLO 1x4T4WC1skbXNQsbGXFzHq/OPTrEc99fv2Ww3HJ+nXVFWhd2vubpTYyq0EImtzeh10NYUVqwNicY p9pBYQwzFFzztY+Nksqpg9Sbqvt7L1Uw9dIQTreM8I9oqjq1GgJsZmDtLfRGRVYGh/MPHGGZYSsc 0WBXufKiI5qKip5ARGcAh9V/WmPuuNsP3s71a7THzjbWdlai5oHZRXlvJW5aOmBESY3XHG/sVjSy SGxtifBE9AyFZHLCzmFiL3WVgr3/AKy99YMLKpWuyON5K+DmpXr2GUWNorzODYRpKi7PhV1dhwTV gZWc07PKslsBiLFPFgp6LIj0iAGGXavXFFMDRPyusGEIug1l8KhF3bu3pQSZUOumVWvC1GLldhmN xP5oNd/cF9ev/LVn/l7w8RV+5fdv/g/ZT/u6d/7+Hhb+yjY/6u6l938w7t8vz/8Ar+vTPx4Fcc0d f8fun2r7v4Bpv9v5D+eP8uPZp4eHh5568d88Hh4eHk4nAqIv8FT5T+pfDw8PJxODzqm0VGwlDWU1 U0xJlIQttcI0lJ3L8unSdIUlSZVVVWRH/dVX5V3z4eHloznDr2TlHux0l2yzHux8M9M464+WfHFZ QhPp3QjLtz1j3RxLpnx5x1xnpnxjzj4Y45MNdXjzFEDghwEGqjjZ4RoYpi3J9vhxUrGNeQqfZ3ws rnqn2d/WvmOWoqp4Bxp6yvmGEkbKKPKENJANK35+sg8T4nRwyN+zvq+NrXJ9l+F/ivh4eZ9QnXu9 Sfdjt6S75dcdse2Pnr1+zH7MfhHxjx44x6Y+mcenDpnr1x2x6Z7pd0uuOnTzL7WfjLznzx2Hh4eH lOL8f//Z --_006_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_-- --_007_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="ls142-16.docx" Content-Description: ls142-16.docx Content-Disposition: attachment; filename="ls142-16.docx"; size=56663; creation-date="Tue, 03 Mar 2015 14:39:06 GMT"; modification-date="Mon, 02 Mar 2015 09:15:43 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAOTvIBnQEAAAsIAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lctOwzAQRfdI/EPkLUpcWCCEmrLgsYRKlA9w7UlrET9kT6H9e8ZNW6EqbYCSTaR45t57Jo7s4d3S 1NkHhKidLdllMWAZWOmUtrOSvU2e8huWRRRWidpZKNkKIrsbnZ8NJysPMSO1jSWbI/pbzqOcgxGx cB4sVSoXjEB6DTPuhXwXM+BXg8E1l84iWMwxebDR8AEqsagxe1zSckPi7Yxl901fiiqZNkmf1nmr AkzVqljmqdKuCVDHPZHwvtZSINX5h1V7s+SbOQpSrnviXPt4QQ0HElLlcMBG90IbELSCbCwCPgtD XfzTBcWVkwtDyuK4TQunqyotYadPbj44CTHSzpq62FWM0HbLf5Aj4qqG+P8UjW93PCCSoA+AjXMn widMX3uj+GbeCVI5h9ZhH7uxs+6EAKt6Ytg6dyLMQSgIl/9P0Bj/aB96yW+Mf5BPeWJaQx8EG+tO CKTzHprn6V9ibXMskjrHwflI90f4w9jbozupcxrYQ0B9/E/bJZL1yfNBuhUUqN9my0VEZ06Ob2xa wvn6Kh99AQAA//8DAFBLAwQUAAYACAAAACEAdISmQA4BAABxAwAACwAIAl9yZWxzLy5yZWxzIKIE AiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAKzTyWrDMBAG4Huh7yB0j+WkC6VEzqUUcivFfYCpNLZFrQVp3CZvXxG6Gdw0UB81mvn5JKH1 Zmd79ooxGe8kXxYlZ+iU18a1kj/V94sbzhKB09B7h5LvMfFNdX62fsQeKA+lzoTEcopLkndE4VaI pDq0kAof0OWdxkcLlJexFQHUC7QoVmV5LeLPDF6NMtlWSx63+oKzeh/wf9nCIoEGAqF8xEWIeTqS yWdhNcQWSXLt1UMup0NHkZO5mAat5gVRN9hnB6afoHztFWib3zzL0z2+aYzCO68Gi46mWOOOb9Kb j1roj/Kx27maU6OGRN7+8VyHnmOkyzlJuCN0GvVxFITwKRKjj1K9AwAA//8DAFBLAwQUAAYACAAA ACEAOD2xOJQBAAA5BwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8VctOwzAQvCPxD5HvieO+aBEpl5aKAxwgfICJN4lF Ykf2ltK/x7Rqm0IbgWRx3LF2ZnY2sW9uP+oqeAdjpVYJYVFMAlCZFlIVCXlJ78IxCSxyJXilFSRk DZbcTi8vbp6g4uiabCkbGzgWZRNSIjbXlNqshJrbSDeg3EmuTc3RlaagDc/eeAG0F8cjatocZHrE GdyLhJh74fTTdQO/4dZ5LjOY6WxZg8ITErR0TKaS6s2RclMA7mlXq1UkcRlJ11gLmrJ++Lxgo5AN 4148CdNZuJg/hnFvPKCgdt0PWjhj8w8Eo3hF6OkJ+j4nWMHrMyC69djDDC0wcoznjFz9T5SCI0fj 9gwmkoD5hrCSXFqtKOtfTejf8mM9n77R9cLB86bcgqwrO68e7I8N7pAuC8yrBVxX0DawqbvkRz7l Ze0ugYN6DULyLciiRhVnI/CaQa4Vpvy1ahnZQ11JDH2aACWUxvYqdkjntxD7DcLpmXYKX3Xn/zDw rf8thD3UZWLi9UIDLtohbOt9CPTowZt+AgAA//8DAFBLAwQUAAYACAAAACEAJzWJoJMaAABgtQAA EQAAAHdvcmQvZG9jdW1lbnQueG1s7D3bcuM4du+pyj+gvA+xK7ZsWfJ1tj1Ry5d21u322Jqd2mxt bUEUJHGbIrggaLV6K1X5h/xAviWfki/JOQcgRUqkRd3cdrenatoURR7g3C84gH7/85eBxx6FCl3p v9uoVvY2mPAd2XH93ruNX1uXO8cbLNTc73BP+uLdxkiEGz+f/fM//X542pFONBC+ZgDCD0+HgfNu o691cLq7Gzp9MeBhZeA6SoayqyuOHOzKbtd1xO5Qqs7u/l51j64CJR0RhjBek/uPPNyw4AbT0GQg fPiyK9WAa/ioersDrj5HwQ5AD7h2267n6hHA3juMwch3G5HyTy2InWRC+MqpmZD9E7+hyoxrXjm3 FKARd5XwYA7SD/tuMEZjUWjwZT8G8vgUEo8DL35uGFTry/HgXPEh/BkDLDP9jnlp4JmZPw2xuleC IwgieaPMFLJjxjMZcNcfD7wQaVLErR7MB2B/EkDQW445V0pGwRiauxy0a/9zAgs1ew5Ylslp1MLl JvPQ5wFo4MA5ve75UvG2BzMCljGgOkOx3jgDi9OWnRH+1W3P/rlT9uI3NkRJOTnZr23ApR4FAKDz hW/s2gdu+EhGOvmq634RneTLpvC8j5xgeaKLTwGsg6McSMrt9Yu/352EhgNL+Rmee+Teu409+A9f 6roq1PcSgNBHj6c/0ZdN6UUDP/V95oYvP7wHm5x8+mP8KZlDQpgr5Xbwsgd/AYaZerVePTL4ZG4D Z3PuHhzmPnt0Usu5XT/OA1HdP8m5C8zKuVurVo/zxtunWRjsYqS0gi/Bd3XukbYH1cNm/QQpQrfu VOqmedpQxeG+fgjAVVh49rZ2zL/xJytSRKtpQXj8KFRPxIxVApyk0vEMLYyg7Ozim+eiyyNPT39z N4FKG4QKfd8DjgrPuIks8AHM8toPhdI3sifNZPMer44f7/jRAD850rtE4QNq24833HwqhEIPWiga 1ZZH2Ycv/E4yP6NBhfyxfGjTY768U1J26Tr8GtO5dmiAeNzvwT0B02uELn+38bW/07y15LdwrFuC y+DU9T3XF6zjhrpFlMKr98nVTXKFrMLJBKfii8bgxvnybuPoqHqwf7DBnNG7jePacawm8Ey3Kxx9 YZ6E6VVP9g4AEDJwgwF6J/RaO8Y9wJjpTjFLfkO2O9fRkRIMbnRE6MBbro52pGesU3Dq3D5eKR70 XedSwQuIGwfVGN+5kc7n0BpivoC/Nl7Sl80+EFU0wgBQwvkRMZ8ef9lRU6DOueYsUtNObTaowFAQ oMHVaZBMC66WhuY/An8QZ/wApLDc2yvFvfgdA4HjhAyzpok9vqWUHPYF74QxD7JQ6GNmVm3PDS5d z8MR8JqpUzFoC5iluu6QvvDTUDn3MJK51kpop4+XXXjN3t9NfUFjjMHipzAAzNvDj7IDSPNIS+Ld l64a4F/w7uwLUWVkZZ2j/jyhPLvjlwOwOFdCDhheoCl1NAHnjzehnVn8CN72Jc6KhvB8hm4EwU98 M3C1UMxzIfw+Rqdr54R0BYNE15q7nrneRUgWa8TTXsL/9F1KQNOfjXYYw0JmJ7E3aILo38B6gye8 C5g/MsQT3gVd30PA/djuERufxbMQ/okNHVve/Ti4oG8QOfvgLHNeBAKQObu+bV3c3zZa159uGzes dXFz0fz08eOvt9dNusfg6tMt4T0fVWu1+kEJqpJfe06qBg965CVBAyR84HjbQlnHOEUvioNySF7i aSQZ0JJVD9n//dd/s5sHVq3v0+VFMT0pGKJ3l46r8O4HYYNl47oPDmJyLxFwPRfD8mIdyixsrNPh WswRMo2jIOtXy0hxfa9OMd0MKa6n6RPffO6ANGs2TAjXbob0NyWjsR2b14iUA4hyPWVEMuK+wqHa yoj52UOrcXveuD+//g9jtB4umq1P9zla9oxme8A9r8mDKRzWYMQx2AK3yR2Q0QDETqhHCJ4eWr+e /4ndXdxffzpnkywoB/hsf69a24F/DostVrHu1A8Py+rOcyrI35xEQ9E4Zix/WvImefR8dvrIZPDL 22l89L1UHaFCwktqDUGeHQWLPh5Z0PAr1gfoyggR2TwwpFLZSDNmUQLsm3mAesoDSIVJ6EI+gAon 6/MBr5/2y3iT1duH9RETYDQ8t5cM5whfm3CwJJnXZX7mDUPLvQs4nV0Audywz6TvjXLs+gsyweuj wScY2PW5d8osNYod3FpNfe0gqanOMPWHuab+m+dTJRxnviGn7NAa8oEQmlaoFiqAkhWxkNpeJAIX 11XSoCi/T0BR/J/nFKypSdhcJj5NC9UvEYT8rvQ3w63TYnkqZHGtdljG0Twfi4sJoc9qu4sFhSf1 MkY/yVO/YVCYMjFP0OFK+OKRb7MTtsP299ilaKuIqxFcVw9euk0pWKqbZAYtHH0bZoy98RKWhuxm vEDiahMqjI1DHCMY42CXSKaNA4lk3hd2PWRhq3Fz3bh+wKS11WhdfLy4bb25omd2RccpAQllpLAT ZQH3YddoFxaEBxp6Ec9xXMN2m5kcSfj7LT1HfrHiuvXrTiu3SgF0uZq8Xwz97Cmv9PrUB197/Ukk Tsql1WLeBXOOc40LHE9oJUFNm+1YDefTStvJsLBWtnDodSvlj8LnpzT35iFf/XdVefXPNy6Q6bLW zQPjIBTneAGTG7g+kK03ogWZS+l5crgTBcyRA2wADOnZbqR0Xyj2dxvXh6wrFXM8rtyu61CnIdu8 F91Tdn3RumS3ssKqtaOTLfZnLenWNqtd3d39pYRFmpbbwtKV7eMpYcNq5/XjJkV4eLNl7jXqB4em lyu2UyiRDWRYLHBWl1YVZR6elNEDq6cZPdASZfaZlSBLtRlKkCLn8sHrhGDbicx4nVRnPSHky5Cf /eoxFX1nyE9c0X02Rq+XpZdgabhDJkbLRdzP0YFRkpVn2kuSLbsAf/MAiDYIz9kRQTXVX/fXlnTq 1f36wVG9mp+BpWitz8hA/3aFbmDCm+SsDydO601rXqHWWBf+/atN0yBaQm9SjaZpvclPWFPU9uV7 JfjnD6OgL3xL6gKdmW6qeNOZ16Mzrm/aMX8Id3MNyJZQmlRfdVpp8vPJjLPBoJ89NGrbrNmqz3Y3 caHsTXVem+o0gkBJQOxFKczhydF+k5ixLMVyKFXwBGJPJbwJaZ+grJ1aMZCC/P3hqnrI7CLhVJGw zBB5zNtccq7J0s+Tyz5LTHCrWKq+bwOBr72AatiLNj3ngnew733dpuf74MVkFBBTz/py81AfBNtL C/dIYFnQznyCcbkhQ6o9OR0y2IrdBK8bx4fN6nujg2fH7N8jX+SZj5yAYbp5bS570Khf7FNFbg32 YH8v6ed82h4ssQryGquC6zUGTelr7uiFmk5ODmnuC3ThvSo+FNMWyNdXbqhdwPYKwjkRTmhg8atJ A/qHiA+FO/97jSjUinsuX4Bz9aqph70WDbp8X704oUrEQhqkedvMnbfjueNGcXwrkCE6tSS5sE9a 9bAbVemNjthpfsg36BPcsrMtCwe51xITicAKgHKj8vrsXw+rrMZOaifwB5zKisdJBPKSf1k1Dgns iwF310ShBBr+0/U6zT5HwPaqRRrSFj03LjLn6qfxi+WHdn1Q3hZusszPWj786e7i/ub69g9sAzHX 8tSJDU2lR4bm33wtnK/SF3hAwwZlNgnQckiFIuAKN0IV4zVNUpWJhj4AIOVhzyTxaaaYP4nEJHdX NGoB9sKnTb4rk6UCRmaQQouRGGf8Y15Nxi7pub5V3PWDrcaOWxLaoisVzY8ws1Qa94jHhb3wazPM 3osFBDkf/52UAPxjjkRZMUr2Fk1tJdsQrBaXqNakY6QCzfgF24CZ7nP/c5jfvZX/4khGM+o4mQAN 2y7gFcWUCLwRtnPgh5sH+Ey9GWyyltOPrQtTlDKp6w5lG32wXFKNUKmeHnO2zUqbxEz7x6S1SOay EIm3CdXZ6FEP45rQa53vH9d3r4T/NGrm4a0K+w1Aysibg8Ed5rmfBdOShdEAsl33qyC8Ix9NBh5+ hkrcHjGst7r0oSO6ru+athxs1nHhGezJga9CORCsm/T0JO0722zYd50+40owOipMdHDIzfNspa0g uU/tPPvrlXzPHeu6chL0/I0EGYyxDQmQ0RJMJQP9wXJEj3WVHIA6CQZ0pYMp3EcgRJdxQBdPWJMh TLkHEx/yUWWSGyX37ixifmZiA1PWGAm5PnM1JDROaCkcIoXHultJ9VqN26qQIS4dmCM6eUlsGbSa zb1qrWx6kUIrm6C7xDi3XIJuh5zxuqEPWcjEjqVQb+OZWJvnExIY4Mk7FwoHNJ66p/iAxDFXtMrP ZGu6AyJ3rAsTWi0+Ur45qzD2W59rq50hc4ECIBlhALQg/c+S56cUpeioMtEBBQA78MvvSOm5Hw5B U/DOcxGw8SzUO/sdUOq6i+QA6wBGgHc6ZOy4l5CEBZ7gQDVPaBaF7LMvh4vahCWVJ1te/SA4Wuh2 JtBak2L9Uv1GKK8XrT+TkrjhX8gZ4KlYrm+awdpCD4XwfxyLwUI8nxAwR30HV42O05G+j84R+2+N S3cHkBoJNCbjuIDMreDwLfb7bgPpRhJgIEX5IyTkeFaaOTLKDYyJ2WU9T4YhLuSRJ76/bDJARGz9 cHrV+D71qkF94LFEgfMJ+xB7dJijRoGW8ZFqEHBqwfD4ljZuDTYeh7Nu5Hn0PoZr8CIErLE26qGE kA08EVhtjIXsCBNqMwtBfPhfJt9ZqTKFuZgCHSIMLMH9JkiTmmQf/ixGbADPKxecEOoWJ2qMlRGQ NwRO6Sc5eK3AUQcSYun0Cb1ZCk9SErNKjZA0h9AwZzpm7jDnzG3ueZQlaBifdfBEuxCbAdF4KOEI iKc7mD8SuPEs0zPRfSWjXj9mOOLZbivx6FK+sBkLD9A0GpDd2MoKRUKF+MkBH7EQayvSFwhuICHc zZIJ5ebiUYDdySFfGErHDD50dZ+gpMCbOGF6VmwzPe1kdlsI0pcYMRCuSPJ+BiDRCj+vRhLpZFWB eZzo3PGeoI5CelKfpRAdukBrmAAwyyUetgVNLISEqzJBUMAAjDI82HVj3XywX12fYwpC3AV/YBlP wq9YH5dzwxhYlshRGNGok3D7MtQYeymcmkk0SY7NqWHhokZy0RysvF+YfTxnoTmdrhOUOetTn91T caY6VYxJm71ykOYrTs0FOndn/jr9WrHaFNhovjW35rWJ8zl718ZKUxpkwaxOwa9F4TaqFibraNXz 2KzPNlbkwNKTz7P8y45euFes/TcwC3GpaBwigDlAs4L+aR0YgoUMpOvrGYvPJRBArzll+zCKrbBr UzjNVtUQq1ViZAefRCyfa/NjZyP41fLA0Gg9M073Vntc9QRWsGE8jwch23QrorJt3Q4ELwyX8wYC gqwdsO2RgM+uCrcgeYn0WPcwBEgVBJJ32GYeaVasl5Za1ikurYZnWymJtWKK4R6g6UiFR9H+nAG2 +/Is9qcpnXJt+NrmGGUB46mslco1se73WJZVU+l2GEAoUyq312cUEWKqWwpoiSS+SM6fcDZzC0XB EI6MPEwVTJIPlOVYU6VK4oy+ghRw6kfIylLOrxlkIqwW0u9KuR27Fjv+tYNUB0682Fm0BRReWsli avIDCYu9vFQH5zD59YXF3oZMDjT8w5Lv/3HB91FCskyY8aMUmR+OqF4QzPEPR5BpSX44gj5lfjgi +T5zY9kfjqhV437SzO3Dg/14C9Z8v86QtZKFbQkAFPMMgcqTL+E4cvxwQa8hTj0hddJ7EPZx4cxA 8wRXk5wjunreRDuBzYRm4ne+d9Q4p8XfEl5gVucwGQJc6MrkWnnhN5oWC2FO620nPAM+Grv7lZj2 0uPNtvuLNKCS4D63UMwVGiwmFOk+kv14i9eEaExwYrYHxNoiRoRmTXh1YcKMkG/lMcTT4z0haOtP Ln5Isq41A9rGuC3wxjl0aYAz6IczpxptUt1cWgJokbmDPydi8v8hRJjii3AiLKJy/DktU4pOFWVX ic24KFkek7NK5lm0LonVxT/mXonutPUlSO3VlrQWoVJRVWvl1Y/UosL6SzrpjAhzy7ZRsln2pPTS sD7L7kwogLVE1ujvaLQNzO2ukRVLM0AJ+kAHQy1dX9Fn+ethS8Mtkh7HgZSHSn22vyZViMgzHi+q uOKsy3aM13pmHDCWYZ2xGKbokG1DHOtiZl0zUwESXwKP+/bksGX5PUMFVrjMtbzETyy7PPXwW33m rT7zVp8pMLRv9ZmV12cSFmTmM+N1tGUF4V7Kr7yCesgK6V1I0nJ1DU/i+tf1XapbyHqkTH8/UFp2 VxCDAfd2byZP55kfTnEeaVr7IRRwPm8zs8yHoUPdBryAxD8me4mLx7FCB3G/zvxcSRi1TShnGZAI 580cpNhmdy9iIkXlg9b2avi9Jmb/53jbxrxknDOTnAPdSubZ3fXE9S+oMnr7qXXxv/9TpeN875L1 8OXFZn0mwsUtMn+PXGouEQ6PQtOGR701N3U0eCLAxjlwKbE5yeMq3llsI+IiORwx8gWlh53VpYf3 6F2WZmvcyLqqWaWbhPTy01vltBaqVlICHbeQKSQ5usLq6e2zWKxlRE2spTGP0SoA1WLmouJ0VSdV XNhOQSVKb5lmGrPnkdqIOfag5DQIU7DV3mKcflg9bhDLsnub9YXvgJkXbED5punHeMvx33L8txw/ BvGW4yf4ve4cf9pQv/U5jCm3lmje1K7n9bbFHauGgZ54FB66MUcEc+RSBZGUWSBOrQyhnzRrxbZI Mb1UtCgGSI1cb700FuMFb9r5AwjQZtNeuq0nLl+sDp9QDNydQKgB9zG9WeE+hW3amUZHKEQKz0tA RgiXfsdlVbMHC+w+Ao2WJj5uMTM/MbNKQVnhuqdc3cyioEOncyw/p25GTl8m5SrZee1+f5n6t9/6 v1/JofEzoLxetLAUTj9SFbcYmaVl8lnbTFR6uF0kZK5mWDwCqpvfugBbQm/Fvg40lz6nqohwC0/G 0X3aoeAnO0iee3/Ft9/c/gNJDu1EMdtocbeElZICQ1eeEN/xBtb9tw2sZetk6XONQKQg8zb73OgI sD43O/VI9FzMUME9aiOVSVdMXFuKS1P3l82FN1W/Xk9W+27tkeGtL3pSW4OUJBynkEHRITfmjJtx HxV1YWubX5mcbXPCtU14Nnpoi3UkHjeGOwdTWY3jROqH83C/1L9ziUqK2+XEKW6zxEBpSiR/vPin RkRp1L/Ls/bux8KhRJdOkpEkE7jAKk2bsTk7hpbtC2oe2cNwOPPFcNLqRFj6LlxHqbDzSOEDKWHF obNHGSRbt0O2yb2eVK7uD0ImtFPZgjcH3J5mYo5ByTGnVt5JDcKQih2mBIVTS2Y9Xt3JoIVfF84n 74QftinMstAj7mJ/giqJ4y/oLMVjbezEgXIyoj3tWxU8ygbvjudLy4TZTR74BIQQEhexaAbpg2vM ndR88GzJdENufIDAmIwCW+rHR/XQcXsdF/BUtPSeUOS7NKl35gxBX+JZSmhAc04SMhY0LXVIVElf 4lFQgmswwOFPAIBOTkKJqFb24R3zW4x4ZmMYBdTShVKVgfXTBGjcccO9UDIqGJkGZTyH7eCofgga MDVfM1gNBQU8PbIMJJN244MTADGVAf0apGU7vBpPl5BoC6Oij64Yis6iHP6Os6Habv0tHyqdD+EB K7iySWZ2EPR5iCcZU0BiDYozPjQuf20pOX7LfvX/AgAAAP//vFdtb9s4DP4rgj/dAd0SN2naFUuG Lj1cD+iArC12HwfZpmNtimVIcl7660dKspf0LUGSuwKNJUqkyIcvopiGEqbKCm6FKk/YAthC1TJj pp7NuBaPwFaq1iwDk2pR0SbGDcuVlGphLj92Fpd2RL969BF/GP4bkd1N9DDqdsfjbtyLI1pJdKfZ hr8VkWwiw2fimHFwb1cSFbicczmMHngi4W8tsjjqhPV/cW2BkiP82lUFw4jXVvnlH2nDmEJpQbdM n5XOQBs3U1WzyYhyKoEEmcdhFJ+6UcVTCOJTJZVely8ht3szJ8paNdubXYtpsf/hokSXwM2B/N/2 5KcI2XRCIm85BhUZ5J2YiyVkrb9ulfrZnNWN/3Iyc6GNvVPo+5imkq/P3OJYyXpWrq1vEEp185mX WdCwVN+aWatgG4MUcTSc4hdlMBdxvTj+4BXcIA/OTl1wehENp23TgJLgLB6M+x/o2LXM6F33L8a9 hvjgaVf9s0HfZYvVrTo3wBG4VyOcTm42p/63mYVkcaq3UGdL7u0wRdZKk8D1U885XKXc9GOQTUn0 tn3X3fOr6/OWeA05r6V9vn3yxPAqHPC8EFhY2pAMfk/iE2tsQmEhKpUWv9q6YEOfLexUyx5u75kB Y6jQbdTGzVrni5jD5A3sXXz839hvxtZ/hv1WzIMeDhC2nMmmSFQaDOg5RKMrRmjvfIeEw4UvSs88 13hNwhwkS1WZQmXfFr5dRbYoRFqgTJ6ZE/aOJStmC2CwhLR2l6HKGXdmFFhRTMF/Aqu0SiGrNbA/ jmVbXkt5sClKHw1rniQa5pgYkB2q1p/s3QmzysF6LPXqKkPVDgcsd55Ff1qF+cmM5bY2R1LylTMP VVqUudIzV7FcbGK7JjVG74oBqp9IYQrIdj9lC9AED2ZaCSkdeKjuJ9hXahcIVa0rZYAscOnWqD7D i4+IJSxYqleVVVPNK0xRVnHNZ1iptHnPNs3rrJdq+nhaaD+319Pg0d3qaSA5uN4SvZOULSCOxq5T x1aKVVigEC50BTZDM8r0VGL3nq8YNe91Sb2XxQKFrdsn9rXXiQdMGMYrxD6l620ODnrX6qdKVaBd BL1/AcijX0G7Qra/aCfZh+wrPdT2G2z0/fvT8G7o9Ld76AeG16W9iLnBDJu0UndE5x6ZnsBQuHby DnLA5ialaz70Jh7HiOlLgY2x/icLHsmVsi8xuKZ7bXvsemnUdnr/yFzzg31nd0CqFDgeXPQumg1f OBmCbzGk92PfJdIDh1h6fZr659LvZXp7/V71Ngyj81P/NnAattNpbd006IN127D2gXLeDVpYYSVM pm6cqZRadzpHlDARNkWNe4PmceChd8NEZSs3QJaaatHoFwAAAP//AwBQSwMEFAAGAAgAAAAhAA1C OxzNAQAAVQYAABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWzElM1u2zAMx+8D9g6G7onkoi02I04PDTb0 VqzbAyiyHAu1RIGS4+XtR9tx4n4gSJvDLpYlkj/+KUpa3P21dbLVGAy4nKVzwRLtFBTGbXL25/eP 2TeWhChdIWtwOmc7Hdjd8uuXRZuVANFB1CEhhgtZ61XOqhh9xnlQlbYyzK1RCAHKOFdgOZSlUZq3 gAW/Eqno/zyC0iFQwnvptjKwPc6+pYHXjowloJWRprjhVuJz42dE9zKatalN3BFb3I4YyFmDLtsj ZgdBXUg2CNoPYwSek3cIWYFqrHaxz8hR16QBXKiMP5bxWRoZqxGyPVXE1tajX+vT68t6sELZ0nAE niO/GIJsPSg/TUzFGR3pEIeIcyS8zDkqsdK4Y+JPbc1kc9ObjwGuXgP85rLm/ERo/JFmLqM9uOcD q7vaH2DtmzwtLVwm5qmSnm6gVdnDxgHKdU2KqGUJ7XrSHWu2nDw5SZvFnSePoL1EGQEZLZkiZ7O0 d/Q0pTet+JUzIW7S2/vr751Hv7TSpWzq+NbyOFnqIY/YDcFLRQrJaa3pyFFWwfhywQ8Og9eoZDDh 4NB/R9XvVqDAReOa/uF4el2N+E/FvCvqVGGTSVj+AwAA//8DAFBLAwQUAAYACAAAACEADJymzMwB AABPBgAAEQAAAHdvcmQvZW5kbm90ZXMueG1sxJRLb+MgEMfvK+13sLgnxlVbda04PTTaVW9VHx+A YByjmhkEON58+x2/4vShKG0OezGGmfnNfxhgcfvXVNFWOa8RMpbMOYsUSMw1bDL28vx7dsMiHwTk okJQGdspz26XP38smlRBDhiUjwgBPm2szFgZgk3j2MtSGeHnRkuHHoswl2hiLAotVdygy+MLnvDu zzqUynvKdydgKzwbcOYjDa0CMhbojAg0dZvYCPda2xnRrQh6rSsddsTm1yMGM1Y7SAfEbC+oDUl7 QcMwRrhT8vYhK5S1URC6jLFTFWlA8KW2UxnfpZGxHCHbY0VsTTX6NTa5PK8HKycaGibgKfLzPshU vfLjxISf0JEWsY84RcLbnKMSIzRMib+1NQebm1x9DXDxHmA35zXnj8PaTjR9Hu0eXves9mZ/gTU0 +bA0f56Yp1JYuoFGpvcbQCfWFSmilkW061F7rNlyenGiJg07Sw5eWeFEQMdoSecZmyWdn6UpvWj5 Y8Y4v0qu7y5/tR7d0koVoq7CR8vDwVIHeXDt4K2QJJCc1opOHGXlLF4u4r1D7zUq6U2ud+i+g+jP 9EuEoKHuXo2n97Xw/1TKp6KOlDX9++U/AAAA//8DAFBLAwQUAAYACAAAACEANOaM2oACAAA0CwAA EAAAAHdvcmQvaGVhZGVyMS54bWzcVt1u2jAUvp+0d7B8OYkmoRR1UUNVUdpVKioCdjFpNyZxSNb4 R8eGlF7tHfaGe5LZ+QG6UkTLuk67snN+vu87Pj5WTk7vWIbmFFQqeIC9AxcjykMRpXwa4M/ji8Yx RkoTHpFMcBrgBVX4tPP+3UnuJxEgk82Vn8swwInW0nccFSaUEXXA0hCEErE+CAVzRBynIXVyAZHT dD232EkQIVXKUHUJnxOFKzj2GE1Iyo0zFsCINp8wdRiB25lsGHRJdDpJs1QvDLbbrmFEgGfA/Qqi sRRkU/xSULXUGbALb5lyLsIZo1wXjA7QzGgQXCWpXJXxUjTjTGqQ+bYi5iyr43LptfbrwTmQ3Cwr wF3kR2USy0rl2xE9d4eOWIhlxi4SHnLWShhJ+Yr4RUezdrje0fMAmr8DyOl+zbkEMZMrtHQ/tCt+ u8SyQ/0MrKrJ66Wp/cSMEiLNBLLQv5pyAWSSGUWmZcicOrLXGnfMYyNR7ptHKhoG2HWPvHa39RHX pgFsMJ7TmMwy/dgzWDMVyAMolpFeZNTEzEkW4E+URBSwYz3fwtoamhGtrVCmqfva6R1bh1N5nCUw bJS5A0Tua3vGvpIkNEcigSoKc4o7DWRjdBm5J0WcRd2EWIBqN15IQzahUzM/VeSeFClXGsb07olq 0ODssofQ1w+o3xte9i5uhv2zcVHhMvE1K1VUEiCabizWcrTdw67nrXNwMQAh4uIabGle5/DV20R5 9Iea9FRzGg9qsLfaRr/hNFqJ5tUwLhKbYQxws+W+9Zz+A0M0Gn+57g17FwiZfwk+YxMK6L8You5N H3lt9PP7D3Q9Ql6rWWx7f3e0ynvvFP+8nV8AAAD//wMAUEsDBBQABgAIAAAAIQCJsDhEhwMAADkM AAAQAAAAd29yZC9mb290ZXIxLnhtbNxWS2/bMAy+D9h/EHxe46RrtzZoUqwp1gXYgKKP7SzLcqxW FgVJjpv++lHyI0kfQZqethxiSSQ/kh9pyienD4Ukc26sADWKBr1+RLhikAo1G0W3N9/3jiJiHVUp laD4KFpwG52OP344qYaZMwStlR1Wmo2i3Dk9jGPLcl5Q2ysEM2Ahcz0GRQxZJhiPKzBpvN8f9MNK G2DcWnQ1oWpObdTAFc/RQHOFwgxMQR1uzSwuqLkv9R6ia+pEIqRwC8Tuf2lhYBSVRg0biL0uIG8y rANqHq2F2cZvbXIOrCy4csFjbLjEGEDZXOhlGruioTBvQeabkpgXstWr9ODgfTU4N7TCxxJwm/DT 2qiQdeSbEQf9LSriITqLbUJY99lGUlChlo53omaF3MHh2wD2nwLo2fuKc2Gg1Es08T60qbrvsPxL /Qaspsirqdn3BXOdU41vYMGG05kCQxOJEWHJCLJOfFtHYxw2LpHN49I0iz+k8h1yfLz/OcKlW2g0 TB9oFHuFO4ZncypHEcMXi5v6FM1+0gWUrjPIxANPl0KA+9aujz8PnAlj3RWgq7CVdHUXhBOQZaFW 5GsHCn6c4QDtdr/bHTqN11O6MCL1yxk+EWMlwU63VcHhWw1xbKdXPtLDwZfJwbHHD0eXZuWw1q59 MKrctcZR+SpH3kuj7Fj93+42E+7YGdYVb5KwAd1C+xpL7g3s4yg6CAtNGW/4YCABo6WlgxpH8sxX ZyfbBJyDYldrI2b5jq49a2v5s180sNZkg7Qdfn2BtNbly/KAGoDCqq6DJ3arureH5zyjpXTPJZdP mkTXDnyamDwqJRwHbci4DraRP7YcDY6aKIMk7hC61nzWhw1EUldrYsPzNUDMefzNOWxNvFqHgYNa uJWPDah+dLXV1IZbbuY8GpNrKDgBQ6iUBDLick7wluFGUEmocxSnW0ocoEBYIgUVFpT/OHLc392o uyAJJ7ZM7jhzXnF6c0sY6EWoco9MUbtkOaGEUctrmEqgM7QSKhUMkVJcBc/+YC7SEn2nzddBj6xx 4Pn+XxpiUwtcN5y1RCIf3BIFjmDt5p55z1eJjD4tGgZLhLPIJTZRitzq0miw/BNJ8AYQHYANZobj pZSWzHebhwptYIimxvktqmNpKGIk0pfKa1XC5f4y8eY4CnIw4rGWoAFWv/dCwcKr3MzZdqj/E2Xs wscP//FfAAAA//8DAFBLAwQUAAYACAAAACEA4Rxm1vtqAADIlwEAFgAAAGRvY1Byb3BzL3RodW1i bmFpbC5lbWbsfAlwG9eZ5msQkqiLpCUyoiUCaIgmQcoUZYgUT/EA1ZR4gBIp0qINSpRAECIRgwCI QzB8yK7ZOXJUeSaTsZNJVbKVSbJOZnNnNp7K4VXiTOLEOWwnjmNP7EjxFd9OnEOVSUb7/+/vhz4A EqQs71Rt7aPExut+/b7//v/3ukGJMRZmWhu3MDZUpPXXH2XMmmRM7h85yJjEHvyAxOxrGCvV3YPt znWMfd7K2Cfg/nsl47XHrt/APpFay2AC9tu7GfsV/D+kDB6AYXcywIpcX9qP4x6+GxHWM1b0qyHG StjiDjwLk7IiqZgBKNtowTP4aZNl1rqjCK81SpWsCo7/YSlj6zje1/goyWLZOZ5JJIMLLN373yJV 73pmG/thiTfd+74j6eLf7W/4B+jj/bslwsAjMm7ns7zDeo31ccurRX3q3L+9RLzQ3NZetmUitBBM yIeDaflodMEfocu6RnNKOUfjfH/HZbXy+Sx5j5Y8OOKI0lqPVFu2w6+9G/5QdJBtgKt97NWixy3X WD3JZDCSDEUjHcVw1srWAv/6Y35UbdbN6qy3McQUs8pMP2ZcHXOWXacbMx5dCMrRuOwPh+XoaTk5 H5QX/MlgPOQPy/5k0h+YD87KyShcCCXkcMi/FmhaD7MibVbQ1Rr4X5Tt4RHP0Aj8TyPoM/5ew0es VcciL/iZZsGjRu/tKr03SF4dvaFENCInkkDiAkgMaM3IM0E5kZp5ZzCQREIHJ66XA9FYJh6am082 yoMwOhWYl/1ywJ8IEhvpEDALdyEe8kPU0X+kHM9Y+Kd1cER68QqOJAoFp0h9MYxDKaOmUFc0Jx41 3gTHyCXeT3OIq4hE3AvpaTIgX8jnEWgDLunSJf0RLVC7V+HyW2M9yGr18ovMhgIgvVk5FOHaxhNn QrMp0PdsNJBCqTaCZPTcCo6E1khbNIL+C7rpE1kI3aPnhqx0jfVPJivFe64Ex9/h828Bjm/XzT+u ql/YBLAJPh6JJuVYPHgGjQjFkALjMNv/afCLUDIBIgLvnAWRxVLxWDQRbJBnUkm4IiZI8NviwVg8 OpsKoBvjVNyjshJBKZKEjHaC9oUj8CrZYhG/LqwGR5DMyRJp3PK+JryR/I50JSyYLHEdP4O/aUai ArHwHouJAsQWNGAPr+J48gzNEozxQNNLtaqXuyA7aHqJyzF/PImSAkmCMRLn5BlIj6CG6NfbUYk6 3w8sSI+Yzy+THK6EJR3hCDJY0m4dQiw1E0bnQQWnQ8n5aIpsx5+Cz/HQLXQFGIIY1Mili3RrMYP6 6O1CfnrtkqyFDeSTLUWbXI+SrTLPNVfCo/CIo/7EcyyQxUftlorYJjj2rneyN/gFrBIk9kqRh8+J oy9dwnRKo0XOWvquwuPutryi0ojjNH7wk2QBNMvyGI+r1wvRoo1bDUYr3Puqjo/V0gc5f0WyWtm4 u0Hrlycr4uPyZED0rUzO+nFLYWgVVOFaZ4/Vy7MItu1FgYI2H7Bu5xW12db1Yx5h/8ymmVetDn91 mdUm+q3xSPO9cZnVJvp+7tEYr5ZCzsedXgL5ZjdL+n72MS5pL9z9z+wRJjNaBywl6Xw4S0n8Nmax 4KwkoTcvU0KYj3KPRgkdYMhLnH2W1cBVpNBiuY0NHp7oP3rYMzF45LDHK0/0e/sPHBkZuf7w4AF+ ToZPRw7D+PXA8zoefTcwrNDXw89GOEPn8QevbYKfDTwfF/NxWE2KH7rHLNs4e5rbvKBH5hlwadkK ea1MthcsOCvJ9tXLtGbkNvdolO07GPJyhjVaUPJI4QXgBSQpu1tkWEOWsi3AxQa+4jFL4Ay72YIS EHfdA6Nyx/yFYYxsmEeg/7UB3Tsuu5v3yqCRjXAWsTfkyZxn2DdXgP79ZdDFmIcNY/rZ5jxjnjLN o8fKp2vS30p0/Qi7T7ot60evX6au0Upzj0Zd1zDk5f3gR1dxu70NkB9hOZ4DvG3kP5tAEmUwFo9r 4f9m7jeboW+Wz/tZWvUFmhN1t3ycIZ7zycdIcwOf/16g+R26+ccnPIcVz1Fl0Ee+Pt5/YOLIUfRw ohq9eTNg4XET0F4Cv8nv0cvzcXAv+6iJA73Hr46DlUU1B8c9B5xtNnB2vXKjPNp/dPCIghEFY5M+ UlEs0keaq9R5ruJZXMyz9zp3E9WpuVnhHKs38Ip1cu58VBXo5mvBuWjdYZ7voEl2y0fC5WRn9o57 uL/dJxnz8Gq9A6NX7tGoD+Ll71VPRwovWO4pmDEFfSvzdJyRxq4sOts4TZ9lt1g2cZoQ7RHWH5kL hxLzcjQSzmzm0RFXKZi3KFrSToiRr89m+aI5CkUwPa3LeyhFle+zoxaMKmL+I7BeD0X84Q5ZpRYy CUoSUQXFa5iRejPN37+CNJt18Rq7j/1YrXRWZh+kixfZEYa68MLd97HX2FgqmMClY12ivmMTcIGe ijUcfsLVNvFp5OtF9lG1KqM5CtmYntbCfH1AwlmJj5XUn+TvL7KvMvR3RPqA9Bpr2uNuQYskPsz0 P87pF2ML06/RVJj+CxacdeX0067si8xmQa0h0gXLa+xQMBI842+Q22XMWeIH902Qq1yOZrilibt3 54lyL7J5wxjZUJNUq2Nu4vskYsze6+SDwZl4yh/PyBBB96E0MYIjFWgdaB8U1+knF5M8QMMsJGlN evkkTVLMXeVZoIZ9JOsNq1tJWuAH1w3i3qXHbYJxn34LGP+6AoynYdxX3gLGB1XLWw7DDuM+lB13 GXysAKMO8uhXlsW40uf0dlQsobWtJjrWMLRXq+SRMAt4GVpiseQd9AyOY3024ZnoH+k/PAERfC1U YbjLTJUZ1WyYBcrgP1ZnZh+wSi/z6kLMWcgH9LTn84HLkcdO6T5WzJ9lrFQetLKxS0d41PHC3fex ndJ4NBUPBDt4RVfMqynkxcyxXfoLNT/QXYU41lNXKL7ulFCGq8kPZSpNX+W7mIh0wbJTGpy4nmGd sTEP9T9RswONNMZS2v+1S08y3B8SYybk9XlHvWgYNX7IiCdG/dkwCvNWbiS1S5u5FYlRhWWqyemt WFEhy5rkGi5sWUtd1+Yv53y2gcWhFr0MrWJSmgglw8EOWr1jNhf7S4X3jtqkhGqFNFMhiek5KWSF k1wHq7FC0nUbWCHpGvUzKXnHjTszYtQPDKP2xOnppZm/n6p2SqNkw5h96ph/h3W5NiYakSe847I/ Misr+CEZjC+EItFwdC4jU+VHO0b0pAjltTF7BmsP7OOTEnwSQKu63Eq9TfqUaqmEeU8ea26TvmAY Y9zXEJbwv7gkxZiD0XA4mkZUfK5RnMdz26RfGGY1em63OuY5aaduTComB6IL+OQxwcVyOhVPzgfj 8qJaFydkqm7wN+4pUBWGcV9IiOSCv0l+tNalpyb4eW1Bu9NsafmVClW6w5KodIkDfFJInqHn9pg6 9lG2Vzc2EPbHQ6fFc6S6o8HTHfJg/8RB+XC0UXY3tbbXy1P4HBtONchNh0ZHT6zj+qbnh/gJcVD3 pPkNXBrIp2Y5uIqgc6ImpGdQVLeKHUmUCtlWrmUPS1W0bspax+VL8ErGuqT0qOVGNUKsLKbVcH6i UrtaVdwIMySvSFURlZ5Rqwqas5CM9LSvrrIOQ+y8/Mp6UlpJ1VsJWr78qncSeLv8e39c8BmSBdb5 k9Jjy2Jcjj3dJT3FkquqymSGun8P5MgSrvskzHAXRMa47Kdn/8loB0Yg3OnSr+QxMuSr1N4jfVrN kTRTISvSU1woR97F7fKpVXCHe2RI0wW+b45Ij1ruknh8mjyEiQv4QJ/AKFPK/YR6uVwNcN8QMxTm SqP07Ywfn+QyXo2+d3J+Pg76LuVaQvl/kutbTVqocJ5zaG+zmMcPbe8mn84/Ln1D1TnNVkg6eqoL 6fyTXN6r0bmg6QKnCZEetXwSMnc+up83jClMt0bL26nVB7gUV6PVOs7P/aDVrVwPKOEHuFZDEcjm C5Sd9Zql/I6fUbvo1XiFnvblSup+dQUjZi4kKT0HhTT8AJf9ajRMzwnuBw3jcwJEetTygITFhTzu aWqQD0w0c7ul6gFXSPQeIua/3Mrxfumw6ts0T2HeNHrfTit4ikt6NVZwNefnCbACrIe8DLXwlOSJ xeLRM/5wB5cDapyqqHwrgCek96l6pnsLyUJPYyE9P8Wluxo9l6k0XeDrbER61PIUX2djnM6t1p+Q 6F08MTKfzz8hSaq2aQxWSrljNhrGGN/GIOt7QrpKIuujMeOH3C3yQjCYDEXmZF51UcwUR7FvnIuV MmDVGcbsUcfcIlXqxoidXPNeKmEJ7RIi+bXQutB9/r3VJ6Q9vEoWOPV56W02jClsIZrW305vucjt dfXe8mbWW9CWL0pK0D8bDkWCHarmNEnmyuJN6e9Ub6F7C8lCT2Mhb7nIpbv6WufNbK2Dkr8otclD qUiQmwfnRdP9UlbwprRXtUiaoTBXGqVvp4bbLfexP65qrbSN81NmOcI598Ld97F2y4FoJAm1bQdF Q5RD/mdSZZZ3qdql+wrJQU9fIe22W85JOCvRvJLdnmqVpq8yfJqCSOck4GU+HkokQ/6IfAhifDCB uwnaO7W0m4JxUuwg5PJYq+5v0HyF3lLQ023m0UhvOZ9/J9BLOy40/0DKnw6GaM8Df+e+w7LT8qK6 B3WlKSJ/bwaK0N/F/J5UIhn3h0N+Tg/SSm8E0x6FkbZmy69NtBWyiKVpy7WIRy0468otgvZuyizf 4utMRHrU0m6ZCIY7cC8l37vqZZYnubbFWJlV5WiszPJ7jibGXNvilptkyiFix8Uo0TKLw4ISFXe0 N7XDLc37WrMRRh91zBQFeDbRKCqkbU1Ky2ubpLPTJJ2D/pu5dPJbHr29duVpIck2Ay16yfYv+EOo K/ID+j6J2d5eWpKiS5ZWdczvJZtuTEBEhMY5HhF6I8lg4JZoJNgI6zvOuTE+0KqO9hjXMvy+Ez0R FvuReD3fM41my/0mzeWumpst3zGNKV7q7dGylb21gpnNeERd0NvdlyxiFK5YjfstEnuQtYCk6Drt y7whXb5+xXGp/a2Lb2F/6+KK9reugXFfeQsYT68A4zyMO/8WMEQ0Ww6jTLooffO/7KnuIOi402Ku KQq/r90PNQXVBp0ww6Cl0PvaepzV2lK7et/l6KDdshJbWgu57PJtCbPcSvTcbrkyeqY5VpIhSVcn LeZ365d/F2+pd+tz5y/j82dgfozfYv6lnwNnLEEDJfneqclYbjKMmcgTVzOW5DLfFqD1acZyC98d EWPG8PUlOTnvj9yUwDwisjLqTLxJift92jyUQTOWn/AxYp5MNCXjWGM1SU/CMpY3GD4JE2PxORKM j+OXycIZGb9NBB3vOPT5wzC5jnahMMdouQg/Y/Ulzon6XDzZofNUq9E3vkRGFJw/yFfmggrD0yh1 nvxPlYz5OmOpt5BV0TwNnHpaDSJFGv+X1EooYxnmlZC4Y0LZ29a8B1br6h4UyZuq31y0fzCg1TfK k0GZ9g1K1ay8skznZ7eCBPQeiZlupXcPwt3DhucXhfJkIX9Zyl/NlvZeHuc0CaSjqTBKzVirvU8d G2I36sbOyuHQTUH8wmwitbDgj4duCXJtpSKzwXgi6Y/M4rbMTEbGrbAQ78wGT4ciIXogi49p1a+S 4qUEfov4NH84rOJTrYRaQA2in9CTW/pOofjmBFmnsFt6vo3XyGLEGLHmxDnFGg1/a9+VpKeh2hNh +o6j8AqyCbyLnniKM0s9w36v5XO8ChOy2m2wvjJ1zJct+hiWiok3ra9MpPwgR/mIBb91o6Fkn4g3 yOn5UGBe9sfxi6dh/oVe0GWdUo+vFIDOktFANCxD8MK9mTn5dDy6wL+rGAPtxoKBZOgM/76rH7QK ZS5+q3VWzn1qjlKiapv0QtGGVnwke9KdWOegLCla0FNqipmkCXqfgT4LfeA9hECaF0/M6Cg0TE// xTqTruBdtD9H+r4yUqf9j8+D1OlNapL6HIg37c80irc/xRsIZrv5vIXeuRL3Xbm8eT2f/yGgy62b fwL0mQzezL89G0rCkjyQUI0hgcagJZJGmV7cUP1D+Bl9Ax37qBHhtfTtbU2/2rMPzU+1nIMjlnsf 5CFLXI1o+TL4XnXMzdJ2oy9pr36ghYciiWAcTLyDLCHXTrVcSPyIt0GQrlyKrjZ49+Vqybwuw4XZ yr9NgO9/5x6NWr+dIb3PgdapnhVa5xVJtlTQiWoGv5FMMaBRlifn/Uk1KCfkEFwGY0jEYCAP+/xe 2qUgP0JJ4ZHkRp9I1vRdZDqn3wXFO4THk39aoYKia+TZlPvxrQr8RHdTNhD76qQrPE8RmzA0GVyr yqDLUqGTQZbnTh37eakleo1n9Z77VrzyLk7bH0A/kzraIPgGgkH8cwGQPceqear0RxJpCLx4xlMN qhk8jfKH8AxR2D87y5OqP5zlRY6Fg/jXKsLBpJxKyDdFoulGTjlZPvmhyIpYH2k7RoJHyrUkcRxD 31ukPRPhG9pdlFtFlNXmypUeRXqt9hVvXmn2gvrOjY1/sLzL5HXL7wSuzOu+Zlmd11GVaz7mW6NU FBnXKGPuRrX+NXNWUTRrivqXx9nK48Lfctw9QOENOtwp7u+hxAme52dxTytCL6TMBJPpYDAiqoNE MJHA02iY6qlANBLBogBfSKPCIrQQC4eCGDTw23rC38VfpNHqMfJqUeGL5z7UozxprAzwKvm/sBcR Ucyj9LFesz4cIywQz5JOxN+yMOrnrfj2NJexB2TcqpOxVgLz+Bv0g6Tw/c0GkHEmCvLkfw7ijD8U 9s+EQQnBRCAeiiV10tH8i6Qo4q2QE/KBOtfqHG2s3kvFHGK9RzKlPK1x0aFy8UnJoeOCR8s98lw4 mkjgk1BeHB49eEBOhGaD9Y3q3KRXUcPR20wiWuPnTQyrbnyqTH9vRPBo9g9PUeyKeP5qPfikyYM9 4MFkO2YKTxYFrpgHa+u3XE/W5vwox80AhbN6CvmLwcI9IWMn5qH6mZUD8UwsGZ2L+2PgmvTHj2RI FGBioQT+eSbIKn75dCoc5vdjzQ83wuJO+H0yHYW6H/IPZB586ifytdkPyZfFc2+ySLIs4aXamxCi DiRPpaqLxlCmN2YoYcGUfwhf20cQs4rqXoscVGGIVZ+g1mhlb8XL6Qnwe0EPtD+u1dWqFrIrTbOs jBb03qK7DRbkMtSd71bHfJBN6MYk8uoVtJ7CtRhUaFkV86hiHHxTMGP8O0V+rnvx7dqVaEzUY0LT ogYz65FqKLEWyD+ziFYUjymKkda1KIc9rVK8Etqjdz0+Atqr1MlVy2Vg7uRS/FT+fII/ep/QRmk4 CRXnDdavx+FpgNfVyTgUeLFoPEnLL4yv86GY0UfNvog7i0lae2i0aDlM//YJnqX1M8V3EZ9FZF7O 95b3JVEfF/qrYyvXyd1cVp8HnRw36iTph1VcHksmswdzN5z2h8N86ymJf9Vt1p/0g0NGkrxkiQcD wdAZECm+nwfTkca0PCVy5cpjl2b5+UeTXGnNQh5BNkQRjJDFvVqGFvsd5BtiXi2TXxl5f4jL+5sg 75N5fcBghMn5eDQ1h38NjWcLDBszM/HgmRDfP6oTmQeWiamFGN5db8wowqF0XqK336XskCIA3UFa 0rIB6Yzu0mKRqP/EX0zTIq+IcFh/aL6AR+HBAkefVTDaaV5ujt7fLDpnqlCuVIQi7Txm0o6QM/7x wkTMHwFL5n+DcSEaD2rxiqsPU3b/mSAUaaYyHeNOIhENkOrwr5HxWXCUSWL0Rh3lME0DItui7PE6 3oP1nDkKavoVmRdXkuQry4/X4pl4E17TK65ZtdqSrl3Z3PBhLvkXQPL+XMnTCjzX3OU6vT9kzb4e pY1/MJAy8zyG8XmStX4tlUf2olah2sqolXx2LFbcuZ6Qz67xLiFjEXv02Vz/SciX8ojen4RNiOuX I38ag7116jMQPBbDsXZtKWBMHB4dXSs9B8M8G/+avcZuZjdxndzAxthp+I9vY+OZmxk+UeGvOCzZ LvG/M6e1ovPG66XnjP1Ldxq6RX9SPwDZ/wmHnjfUfilMDEMvnVP7d0D/DVYkwIqgCzf04D1iONxw h7gdh1+69Ifs7byr0SqpXXH7OrV/0TDdpUvn1X6P2hfT0fRIETW1K+7n1GFTucv2VTwBJ+gpzfbv 5H1Htk+APdn+ed6/Y8n+G7yf7RJBgttLKkHmfpY8lUCNvJw+J7hU10eCl+sjA44C/R5dHxlaTR8Z vqNAX9ct2EeBvZU+CvS/tC+vsn+F+Tf388n7jlX2e3T98wX65/L0HQX6pbr+naY+dHPs3+wfZv9Z xt8oQJj7d2T7yG5uvyfbP8/7jmwfyc+NH+b4Yo4/WYJE9DX371D7b6j9HrV/Xu071P45U1/tivEi vIq+mJ6dpRNiOvafNIGYjv1Jje+iXeQUiujMpIt8xuztsBaUdJd5EnJos7Ei7SNv60z90jtNfWM3 p2839feb+m2mPiZSfYsV6J83dqVzpv6dxj7+VXjPxm+zdxXI5MXG20wN1ff8+f9gD//bb9gf//hH 9sX//hv29OMvsA+cfYmd+8Lr7HTPC+w3r/+ZnZl4lvWWPcP+au4l1sQusKO1z7J73/cqe/ONP7ND lT9jF9/8NXvj9ZfZb379Cnv1+WfYr5/7Jbv4h9+zV19+nv3yoQfY9z/zEfatu/+G/cttIfaZyI3s c6kT7FPvHGNffXea/fjzn2Av/eIJ9rOvf4nd//6z7N5TQ+yjvgPsux+7hz1838fZk9/5Gnvs377K fvGT77FnnvwRe+zcF9mPvvgJ9sLjj7APeRvZiz/7MXv91V+xN4GG1195hr30q/Ps+Wd+xt59bQn7 /e9+y/62dQd78zevs1defpa98tIv2UsvPM1efP7n7Nsf+xt2j1LHnrvwGHvy+19hHxlvY7/77Zvs oc99iHVtfoo9+/TD7LevPcv+Z+QQ+x8zCjv/xLfZL5/6Abtr/jPspw98mv3ip99iLz37U/bByVPs wpMPske//ik2vOnj7JmfP8ReOv8jFjt4Pwu2fp3904l2GHuO/eBzf88e//aX2FM//hp7/ukfsud+ /l12318dZz9/+Mvsye99mv37D77AnvjGh9kzj/4re+q797LfvPwL9i9nr2cvPPM6+/qnHwQ53Mu+ dtcse+Jb/8S+8YF3sgc/kWKPfvk97Gf/+x/ZvcEekOlh9thX3sce//o97IdfuIO9/PT32I++9Jfs c//4I/biz7/DPnznt9nkrofYvX/5QTZfFVjWLv5/+3+/4ZfK3v52laW4+Kr/K1iW4o1lxRuktx3r qquKN5duLr4KPr7NWJaidaWbNhdt4J2VYlkrrbu276hy2uTa2mG701a1c1f11krJutwtVkvZ+k0l G4uuUk+sCKtib73T7nP7Ekm/fyEajS74Q8mE4vbZ63ZUb1viHoulbHNJScnGYo2cwljWhqraYZ+7 zZNMpxYXM2pbXFxMR/0J33BtVXVT7k1gDes5EkmPWgGsrdfVuZTkQiydjoUUz1A0k0lnGwKmYwtD 7tqqbZW6e6wbLOtKD5WUbFqv4wnbslhbdzlcvgWYNIMzZ6IJTyIm0DJ4hvhb8Pls27eKm4ClLcBS SWmxxTTdMlhbd8lKKJZZ1DESS3iGYjB9Jh2LxUBvoZA/Go3F0tGkz35NJZpDEWeppGRLmRlpGSzr djtoSC8zRFuMJtx+f9KnKIobms/ng99gJUNJn9txylq8eRMClZSuy0VaGqva6U6mNZYIKJ2Ohnxt HW1KaGEBuEmnkUNgMeof8vk8HXesJySdmRtafqzKPYqmGWqLizG/z+3xJWOxIY8/BQaZ5tdRb6i0 mhuvJ6CS0qJ8TElLYFXblAUDUgaAEm4wyPQizr3QMURA4nK69waVpZItecXHWx4sawMwpRcfeFLC 405G08gMPxFzu2MaWKbqBm4P2K4/uit3RrXlYlXu7PAb3CgNnpWIcsPXziU8ghxAEkAlWw6nk+66 pQJXDlal0xPVmfliLOR2h2JoA/qWySQ9C/ycjqeS26sy6cWou0bv2bpmxuq0tYVS2SkXY0mPz2+2 fAILdQCvVYc1pEOH6UrMY8sPZsLaand70JjprnTIYzISXVsMeRYO8wihyu9sNqK4ndkosjRWRa0v 5BN6yCx4FL/JxwxgRzWeSkpu7M1eyKR9eTkzYG21JRZ9ISIvE/V5QgbLNrZMr2YS0Eh+4lpaseUx ED1WpdOXTrujOH8mncTItwQOXteLr6TkrNl4PM7lsercMbAidBx0oAXz7fp29kY9UsmhGw+fNXp3 zN27HNZ2TzSz6PdxmzAFBmMDpvSaUtvtN5zVjVmMenKcWsPa5vEvpheTCaDJB0yZpscmOlW35yLx tuWwsEUA87vLl8KqlIdg/sWhoVTU41OZUvOhmhMJL5PJx5Roh26oEmiZhGyyjyxWr5sP8Pn9mLYE K4hhaKnjBvPLh3aWJABuVpcfq9pD9pfweNAoEEXDSak/i6nUWYP5LYHWS2ALbmORJbDsKEGkBaKh jp2UsZ05LFLHsm3LWa7uzJDD4NIq1jUelBs4fFs0lUUyASFW3dkbbl9GXdQO3VGj+ovbYIuEZXX5 ESoGZUQ0pUqNzy1anDd+TNUdxtJvybblsMMHOQgDNniQ3jwIaycaBgjQl/YhloZDGPoWnAumHcod S3G35TAqKzrkcS+gGbuvMWNVQjRHAfoWM0o0ruLEASgYDxpaJDJ33K+4IXPG64xBihqYBdk7pgg3 aN7v0jHGsSbcaHk+dyaV8SEWMZSdP9vmgrFhz3B0MTIXgasHTYEKIlWV8GQsHJIYfNx7jFhbQVuZ xSF3OoVYQR2SDicSDgSdkKKPh+fCEcGnwdduhxgVS2ezH2ZoJe0f1kwRsRqUdCa14ImdSZ1J+aIR wslCqC0QWXD7aoKzc+p5GHEkG0EObVq/uezmeWhjt04F4tmkmXDHlO16rEpH79bBipN7t1YMVlRU b6uoOJ1FCkdu7W/e2sn/dW/f22ydImAu0AmVq00by4o0QfHWczpIaAllyKnHGnSfNo6cQihiJjxm uhSYCwTmwuG5yNwOisBUuFfvrLLZa6HJDmfd9go4Mx8gMI+SDR6AtVOZlJwdHR617ZSmCApmDQTG pKrslY46yYvnsM3dQma4eYNUucvm7mjTtw5XHQD0nOHu3JY1e8Cy+8ckWRu4A7CQJWpjklO7VCWN z0ILBGZnbuOqOrRGqtzhNuCIZtsrVUYwKLZlaw8mbVNiY5JNG7RD8nIgnHV2tkeq0S5VSadmoM3O BA6TqtZI23RUGhtIwRrkUhRCZNI1w6mbJbs2Zqc0HiYkmHa61cjXMcSaPrGRoDZDgs0F0Q2vWITA 13ZdFqsmGdtj5GsckXDSqamaXiNfJ6enp2+dKCWoUouexjztGulWTIlOgbVVjrnqjHwd4xzNTHtn HBDPDHydnJqeukmFKlkn1elndjnrdlTZ9YwqViuUFX5ZYO2tjXpOG/k6OTsD5E97J5ThE4NGvian br1JOPAWi1XRrrnU9LGtSmeTddJpiCXudhWr2pcYmjfydZJDnarzOEe93Ua++rxkgKSt7dolyIoV k1NTU92StEs7a5fmwexdauhgOxV32mSHk4A0esrp6T3mHW0x8tV6m0A6dNu8VJW90rFNakycCcbP pOa2Sr3Z056mSrCOoR0qlrNjKDhm5Gtyesp7yuHeMzDqHe0y8GVdJ6BKb7p1UEehUxo87l4MB4Px 1JxUrUmx2ppKZ5KqcTBbWzRi4qtv2jtld030eaF1GfkSGXnjtbdONUm12SvgKBGlFxIA5O2tVlf2 /C4J/HmoSsVydaQi3Ua+xryjw67pEYTyGvkSWJu9p7yjWyXNNMC6Z2oXApAEgoClnd8OWJmQnRIm 8yTCwW4jX41TLtcUQo2Pe/fl4WvTLTefgqudkkb/TunUrCMZTNXHI3OVRr5imVAtLcdYm3/WzJcT uDrGocbH8/BVetPNQARi6fly+jwel8ul+Ia2mfkaUkM966hBLANftQpwhUDjx8Zz+Vp/7eQxvObd auBrotfpPn68N1Zj36Y7z/kaUqpVGR4PhFuMfNlcozjbsWPHRo5dbeZrY8PkCFyBAUZ9TU7VKxDb QGWVZr58AksJBsImvsaV3r7xYyPQBkaaTHxtvnlyYGBk5OTYwIFuA18nZ2fd9bOQjILtJn0tetwC KxIImPiqqHF5OdIAYhn4Kh4DqIGBnoE9digk9HydnJlRDs4GAMvIF6SVDlcWaxawDHx1jyp1fYgE rdzI13wftLG+umHFdqTdyNfM9HDvdCAQjpj9K9ohc6y9iDW7z8hXT1+Va6APkfr6THy19PV1DdS5 lKrRnr5+o75mpmt7p/PpK+Su5XZ4DVPqZwDLwFfPsWOKs2cEkPoGTPpq6du9A5D6eoCUfgNfEERr e6fAOMIm/0r7EjL3r2pWe3w6h6+R/dt3lldUdFZUVFQa+ervrK7b0WSt6OwaGGg38jU9BVgzgGWK GzF3Nm7IMMDEV8sxKLqs/B/814J5G49rVn6+s6/PqK8+FWvWwNd2yTnk84t46Ix6Z0x8IdYOu93m gB+bTVcmKTZ+xmHbQVh6vvqmAMsLhc+cUV9ym9/vVLGqbN5pM18jnZJDO5GnuaTmVjNfU6O1dd7p mZmAUV/OjnQ2f20fnp5uMvLVNdBZoGixE5aBr1HvsMDS8+XoSPtEXt4rz07rsx7whVi6E3maDFit Rr5aka/x6emZWSNfcodfUddgbFtt/eigng3CWp4vWervaTXyNTbqdR0fn+JYmoq3S70+n4OgoD50 9EKGrZPtDvVnu9TV16k/kftjrwOsnkqpxi5ONCCWEvFOTU8DVvY8BIy5oY6aLFa9wzuodtR2dV+z 8USe1o5Y+jbmPaCcQKwZ4z5lIKGre7e7pnoqyju37t5V2dy8tRnWWy2tTVsrKyutRWvyt7Iia2V5 d3dFO7R+Wp9VVEyOTygjo1MgxJ7Bffv24bpvfn50z1jE1yH2pZhkrT0ISXh80mEb4xGwr7W1p6en u2W+aKktmo1ru1paWrphVGsrxjFIB5DOBnqHjyEWaGwWQzCsPFPuUCrldghGYU1U44SKaXzEdbBP hWpFqK596gLB3ErXDA52cbBuA1hfjX3EyxlDMFx6ziWVM4ClX3/tVUbHx0dOKNOcLRWqZbAsP9TG tRVXX71/v8pZFmvk2JjNNjKaZQzWuXM1nnQwlVb26rAqao8PjPfVyToJtrTsWytWCIZ2qKxi62BT E2AZwQCrT+7lfHHGQIhzKc9C5EzcbxNQfB9gp31kfKzKoWJxZXUP4sPGnFZaVFleXt7U1JTD2cjk AWXiGJchMgZrxYgyBKVpStF2bhBrm9J4bKzG0SfYQgkW59sD2rjWWlHBwRCry4DVd0Q5ATaWFeJs UomDeUR1Gzd838bpGOuxOcc0rPmefNtbmzsrOzuzYFyKiNXa1wpk9tQNj2exoC1QeZ/YmYUirG3u E/tsTiRQsLUmD9S6ysrmTgLjUhSMdXf17J6+9oDNPj11knsYYE3XdPQGIsFITNtxULEkm22f04Zl C2K1tHT15DEMWPKD43I0DsY11t2zv+lAncNVqygdbpfLVg8uhou3Xk/vLG64DOu3YQlrm3u61yYM Pq+9bznqLJcqIU4AGklxP6qsvBuKN7lmx4mGA+6JAwcdHtsUxClvryc6Ax42F3Xpnz2r+6I1joNy NmR0tZYe2lIK7dAWseW6qWjQoVwrWdvbkTPOGAixYv+eWqXmQGtXyxioa+xk3+SES57yjvd21Eyj h0UUnbayWJ1K1XCDUNe+tWuKita+853XHhXL8C1FVtzfcV6NchRCvLp5l6xUtTb1oKJ7IMRBXT4y pTgna9w1U+jNcwu1+fZ7pXqXsqdHmMY87oJVWHtDapjaVCRZrVbpHQ6l3mrtV4XYWV7jdvZVtKhW 76ofwNXLyEGXzXPcCx42FzjeISK8Ectq67B1Cayu/fubmiqultUHnls4FIBJ1yjydqmyGU2xs9uh 7KrYr3pYd71rfIRjnejw1GOJA1g+kbhMWFK1x9PQo2FdXd65u4P8+VAx54r/6qxSHA2V1ory9gaX vbtc9bC+vn02Rx9gjfedGG47foo782mbYnrilsWSdrU5u9QQj3yVt9erD4zXEE8czCpVOxXHdqu1 VbGVl5M3ozvvdu0ZGxk/NtnrdrgOehFrptedDbo5WFBd7WrJYu0brFAjYpkqP44FKZSjXWO39Zfz kMixevYo3oGRsSmbp/eAawKLjpmgR7+FbcayygoFXi7DrUWkrHWV1koCI6j2fqu1r6ajra66uRnB uAx77M6evrGDiuvIWK+LR/qAqyrnyZ4OS2py2bpaCGtf+X6KiJsrsRoQrZJ7c6e1QamyK7Z6cLCu bhThduVE96jNU+MdGXXVnMQg5bCrG0NLYEnV7pqmFuKrgkLH+vLKdh2YilVpd0rlu2AJb9sz0F3e 1bMfgnedW27sG5/sVaanpqem7IaAkQ9Lus7tbNkHWF1da7kES9da+9s1MA7V39m/VxmAaqhif6PT pdirJnYPuJyy0js5MH7yhKf31NT0Kb+rMxfKhCU1eOS95ftb9pFhHCqqrOgnMGoUD6119naewpoq uk70OuRhpa3DMd03cnJy2uWEw7TDtYLnywDm9kyUN+3jqfLQGshXzTowguq0Omua1Tqgq6ly/w6l rVZ2uWrtthq3p/d470F7Xq5ysaRqV5ttlAzjBsjCANbc3o+VIK8GeeSVHHXNlJn3N/XtqHW5lIF9 I40Hex1til2WlTY5j66w5WBJTY42D9/lv7F2rLmcg/Ujb7zu5FhWp7MZaqmK5pZrnYqrd7e9pmdg YGzfhM82NTK5R6nKK0ApH5ZkrenAiFFqGaqDSoaDIVp/NlO2T7iuLm9u2lUlK476nop6paF1YMzr 9NQcmzxW48Z3fPK3PFhSMzeMo1VO135rZTvOz/GaO/FjMyiv01W1y1nrcuwYL9/f0yrX7OsZOagM T4wNHHG5GpZ+7SwflgXt/fARp6tDrmtseAcukNXYYZWaWxqurXPCAsvZ2Le/fF9PT9dBV99olUup GgHWlJqlXjnDlg+Lv4c2ZG9ourbDY+f2VVO3p75+R1WN0yG7amV7TX29y76nFayju2VAqbUpw1Xe bshc8vbl3qXLh1UE9l66obxOsTU0uvZUN3AMaHanEzC3726tgEKgr7cWQGw2u8cjOxv/D3tfAl9V de29ziUtqBAiwyNCCDeMESl4ATViFa5GKSGll0HBgEhIAqRmuCGJl6gFXr+2zw6/Pu1gbV8Hba1D n63a+lq/tvroZG3Vah3q8BzAWdSKw2t9duBb/7P2unfffc+5uYEM/b3ft2Hn7L3P3mutvaY9nXPu B5addGy0ujLXLWWFXFxFR/gDMc/zyxhYdWUppk/QQKOG48ZB3U9YsGDivCVlS2YsOuOExaedflbU P67JH3JxjcA44qdKJ5TNjFeVz1+4ENMLE/yFgz+/ZnzjF88qO+X0M2bMnFV2TF72+SEH15HcraPS 7SZML48tqphzcukpgo4RGVSYhp544pTy2UuiM6fMDnYUTsjBNcI/J8mEcdMqy2PlZXPnH7Ng/EKe aYxnjOPw/4QTT5pTUcXzz7JpvchJg4vrSJ6ljcguKiqaNp25VF5RVnns7OMmznnfnNnHzZ1XWVHB Ojlj4vEyZhcSXFzvwdlFQDjmmImTyiZjfV9eji0CVsqpE2ULsuDg4OJuHXF0YEUPHRw7bvw/TeAw btxYL9QVhQYH1/DiYvdMtf9CNq7IGKPuAxKycZXk4eDhhyxckdEjQx8e7IeQhWs4L+gGMNi4jrQc xkAEG9eoAeVgFq5hIweUg1m4hg8sB21ckSPs57QHImRwDXdcbv+HNK73Dh9gDmZwFb1nYHUQQXFF Bs7lpoPz7jreZre/QqXfk5PrAU/emh+Ht+b91NhIQ1EmNXGYpPANAk3J3XER7pWpt7kokzrG1PMo k5K74yL4griU1RdlUqWmXoQyqYj/7j4RvhaM7xajT0dxLOG4hmlYzrePcPJHmrwGvT+J7zVyn/Cb 1IBVynEVx6SH9/ykDr4RoOGnfh/xBfLI1NXUQ53URU3UatXoS1iY+kTi/fT3gwcPPnheVWpvXVWK lrCMOH5n33FzrueIWscvene6hxcQnfB85jVE+9MC3jsP4HuvHB6eQOP3LUxda3Akm6pS13LErSqG ievNwMH4gKOE6997+Ql8P+pz+BxvUWruZWP9POpoG4SX5nEZysmn47V1D02gDRyPW1mbwnUzX2t3 zJlDD5XMAa93mHu44t4Gvtd4obxIOYOE9+iEna4gkS1eEoVcTuf4GhP2CMtgelFGThDJ29Y7swgq J/8bitTMEmpiWUVpBV9TfF1F7VxWT7lfVAwMQ8pfDofE32pOI7IFpH551d920QGOVhD1KaIbuEoL 17vz/OWpGyYUzUfUDhfNZ/tw5ATWhqVVJuifK5PLDND+kckQ85IOj5cKZ43BhStwXXmx0AGeQu3e /jLRNr7341W1KfC4o7Qidgzd7LkyAQ/C0mNM2ravfDKErSGN7Br+cynHEzi+yTfP4+u7EYFV0/Ng nHY/GD+L0382PraWZOxwbXUT5+PsK+Et2/hvM8u6jRb5nUB9xPeS+NqgfCH9dOlGBL2gG9+9dOm+ hIRulIXRnSBozkF8Kj8HfosncAGfh9Yc+DsN/OPzwL+R86t9vW9iPO20nf/WUwv/Q24L/+2ibf49 WAa4t515hxqoB37WU4Nfo9Gv225aNPuW1eLXBR8RodsYQ5W3uIJvKMMV0b2nea1jw9CrDcMu1zSi wsDVhgu+atqlRfMu3zEfwQdywfeSSC7f13nCd/A8jO/PcR48ghZG/VFcuAs5QD+F3z183exzv5O6 OfVhTjf4d4XTy1jHzuZrA+eSXBuy2crc76K5/l2B3e1LCPJCzXouAcSMlFJ8FYkLLu23ys3mqX1V WWgd8FLLYDfIK9+1jcJUHLYMXZnANgEPeW0LuGqTNp2aD5KnK3uVseK36XDbap9snXB10taPChK6 9Ro2d5hq2uBrGHZ6jElDn1y9O94TPwh9ux34je+w/eB7GPZMCte7Kwl618bW2uzrAnQOlouyjK1r jQs5NrL+iL03spY1cE51FDqG/ofJ1JWNa3u2rdkw7Ktdz9YfTbs6qPCCfDF4Bt79DG0c3v0VZUWF +GLBNVgyf/8wkXkRX/dzhdEBMh/DsPFN+zC6P+DBx2d7AddfiHRlPtTGKZQk+X4T64B6JNWObuNB ehsftpjxpJnLARdaJeNvo9G6JMPazn/bfYhzCB6o28eFNi4FgKHYUI677b5+wifKiK5UZcawXJ1R 3bR1Kp9fUT+mMLStlmkbbe/6HIVh673tG214Csu1kULGPW1j24HdVxtHkC1pH7SOpm0abV5ovxQP 0vl4oP12+aD3tK3C1zraHy1zeWX3T9u7doR5zsue2NExkVw7+mxE7KiEwu2ohfPQ5yRr13ZfP0XX RFfFg9q6oLTbOuTyzJYLri7d6zhOjAjd0QC67zV0A2Y+vwWrV3oGy3dt4MKFfC1mOI/y9RiH9rM4 HWXY76Nw2q8nfFQJcx/MJWXEUkvHvAX+oN34DPUN9X4e5fBFF2W1EYnJvGkuZXRc+a/6FKZ3Ohdw 9VTl6uq2rf92XYVbiH7jqnOhIB1BBH/B5ycol89RT/iMssEe2+z0LNMW+E0Ai9JrKJSDvsbM/fT3 zOKcftX0CzHzS2EIuxcHp4OD0gHeI+g2gdKB8sGmqTfcMY5vRMQH4Ar+A/cXI/2L25b9MSbNXY0E 0VRhaNErdGGw+DFYuPvCDw22fsBGQM9J9I9DE+x1MGSkYShww16wtw57wRX2AtxDbS/YM8AV3/uF zg61foAW8Eev6s8Hy4YHA3cYP8aYNHBpfYyvYemgcfdkkvH2VL5Od8Zd9HOe6Q/S6LsGyB9nWQnq 27jrtg8ba912wI+9wu9w/D1l9smB96WDA3l2UZX63RXYFyf6ghcl9FbnbWdH9g8//shIzrztnEhx BOU6b/vAozJvA/8wbwN5ux97d/qI1iiVtUXprgv/ctxdXAf72S0PytnIVQ/J2Qg+6YmzkRfnVaU+ OlfORjaWvX8OrpDL1aVFM4tmCqWV3Ob5nbWppNlrP4Szi1MRAde/e2ru2QX4HZZWmWBOesCRyWUG aP/IZIh5WdjZRSgvw84u1nwh++zi5u8XdnYBfoelbR9h22ch8uzNBm17LYSWIP9zEcf/wxF7/ZdT tv/5FqfvMGXqf1waEiT+B3QW4n/y9aFQX4S2gBFh5buEMnqPOm8NqN7n+iLVV/iiGPscV1/hi1Cu Ab4IdIKX0Ncw+4G+BtnPSE6XcDxrY36/cjUzqsrYwiH6ojhi2n7iub4ImbB0mN5D5+Zw4UdJdGEL p9eaeqp33yPskwg81TtX5ldyXMZSXENnsgxXUJxTy+hDfqqW5YLyWo5ncNkH+d/ZfGcZ5zL1oqYM acGB9TFoh63gijzOBFVeyCPiWQ3Usetr1HboLyLa694b7ik85BWeHW08QfYKfoEnFwTw7SlP+Gbb q8u3BIm9uv4gzF7d9odir2gLGPsce0UfXxvkuYPqBux1PtulqxuwV5SrbsBeYTM69wqzV9gM7BV2 lm+8mz5FxjsN/Wiv1Yhpe63OtVfwOyydz153cPwm31jO18f4ut7UU72by0y5kESnVO9cmW/gKLYY 5bXVib4OFpN8UB24MT+GbSCifZDuP25o2BdAww5Dg637Lg0JjmOjgiMIPuAC/rMB8D9aIPyouRfE w+cMfJz5uvA/USAPa2m1z8GFNN/HBRzwR6iv/EMMW28cHREaSgNo+Hk/8BB744A/KQD+PYfJQ8Qy A39GAPz7C4R/Jkf8wlQQ/JkGfmUA/Cf7QL/LnwoK9q9u+6mmTV/nQ2j7Iy97bQYaXh9k/6p+Ef61 iv2o6xfhX1GufhH+FaG//GtJxYD516WIkL1/d2mufwW/w9JjTBrtXb27lWQ+tBn3PPkRCFvvMB/6 PMnzoqp3rszRpvc5j9ACf6ERdMAWSgx8zWP9gSuizneQxv1Au/eE/ooA+lOe0G/bjUt/gsRuXPhh duO2D7OVfHy/n4TvHRyruAKUwOX7dSTP1obRDb++mjkQZ+5W899V/HcZ1WXNM1f7MlnDuVXpOaXN e1w1DT5rHhFywDiJtD3/VL3KJ5OTPenb4oC+Xe1J3wqRiTsXPVyZHO764askcvsEx3sod90Kue0h 4U1Y37aRyO1slte53MuEv46AxKr9Pttz+bB5PuDqfXc+DTobOd5LQudTlEvn0Z7QCThhdALOfDqe R/wFWeeFiEEyf9rg2xeA71iDrzeZ4zw1aPxFf54x8N8OgI/n7gG/sP6cmO4HeBfWH+ABvv8JwHdW gf2JGhz9qcP5xmO0BQyM6VdQZjyG3br7cgM9Hkd1rcvj8ft53IUPcsdjlA/UeDx3+oCNxysQIXv/ 7orc8Rj8Dkvn8y+ImAdiPMM8MGnq2fPAz5ky1TtX5gkSvQNBheid2/5Q9Q5tAQO6e7jrvi9w/C++ 0Y02DPPjpp7y4SIug69FG5sPNg3wGWey9m71n7/o9J8gw5MULdTj+2ddr2A/xN4jASz7Xth+COQE +iAnlz7ICfS5crLpS5DIqdD5uts+TDb5+Horx9v5xqdJ+Ppvpp7SvSoi49rRFE53kuOHzPN3eHII z6st4p5k81rW16AfPFReujxHzCeLML6DfvDdpR98B/1Dwfd89gFaHgQsjn+kw/cTsI9TOGKffAfH W0w95cOHOP2yaaN8cGmAfaxkDYbX16eMKjl9LEsT7UA/IsYvyAQwtAx5LUcMklMPCX07KZe+q0no s+Xk0pegvvkxt/0h+TED40tetpzQ17B0PjmBx58h4cNVlMuHn5DwQfvv6ytl0wA4C2ieP28BrbYc gvgO3gLftQH4HjH4suzDwZegPo4fTvtD4TvaAgZsrD/4finHKzzhw2+8XD5Mjggf4AOUDy4Nmzgu 9Z/fxXO89f4zvidz1DWpGwHDnp8HyQa0gKZ7A2jabGiyZePSlCCZI4fNWX9n4N8fAH9bgfCjFLyH d6OBC/gYO1z4Fxj4JXngt5DMwaN0FnN1M48ieEJ/u/+2iMzNT0jrNtrr+sb2Oep3NK3189kExgzQ jTHDpRtjRqF8KdQm3PaF2ITqtvoC+I6TOeJ3y+FDcUX578mci/h4Dwglfhic524wQQYtu80V6xbQ BHr6k6Yg3P9MgvOT5gqdBG7UGyp+fIqEFr3eRoPHD8yDgDPmyfXHJLifoqHjB17aBC16vdIbPH4s MDiXmetXDG7Y5VDxo8bQotfbBpEfyw1O+D1fPwzuSm9w+DHQ5a7fRb/hb+F3R3iHP8++leMbJHOc JFf4lamnY0ecM0Ve9nrJpSHply2jOMfV6X1Z7Nti1/yDHPEsgcxFMK6DJlwx9oEWRM3r/q2ul0rM FXXC1kugG/R3B9D/iqEfZWH0J6jv83C7fSFjX3/IHbjQz6n9IPcdJOuruwnvnxA9ZurZ66tyL/vM 1KVhA8n7yXhPrIFnO4sos5+LqPuPSLs2pLIDbtCwJYCGjxoaXNnZNCSo77Kz2xciOxcG2gIG5G/L 4lDn8ptI1lDgw9cplw9YQ4EPmLMqH1waAEfenMns6UAHgnj+DYML80UX10MGl81zF1eCwufo6wxc wP9eAPzHDXz45nzw17BU0YcwHDcZHLcH4MBctxAcq3n1E8Yn4LjD4PhNAI6/FYhD17Sufqosfmtw 3BeAY5RXmCyiAfArTJlew3R3IHxXWLlLC/oEGkDTWq/vPq2Q+i7PkyR+D/NH2MqrBpbt93BeCb1T nrt0QjdwntDFqz14Pd1Thd3hqv6uEL8QpBPnkNC3nnLp6yShz9YJl74E9d0n2u0P1ScCBvTKluWh +kTw+DMkfPgy5fIBPhF8cO3PpiHh31sd+swfcHzF4LgqAAfOFwvBMY/HP5V/kDwBGzjgF10cfzA4 bHkG4YiGwH+b4zUG/mleLvz/MvDL8sD/GOflDcw1Pr/wtD/eA49SdbpE3h5v9ffD21nv22mrv6cB HYAsdczRqGO/Pf7DHt06oEfb4z7GOORxH2mdT2hZEH9xBo/+4wE9t/83eIXxd2w03EefaeAvDYB/ S4Hwo+ZekD/CNwAAf1sA/P8w8G1/5MKHHp/lSwVySaV5Bv4hIh02F9hqcOOZVxf30wX2LWwuUOrJ d3AAH8+uufCfN/DhV8LgX0Y4g0qSfBehNf19C5zjqpZu8Weg8qbKds53OHv+qKt6qLqkPEFUPQV+ XYe4umvrqaZtvVe4iKrXynstK9QfuzwI88H5/Gcjif8Ez7EuftfUs/0n1s6gM4z3gKPficB95UWQ rHd4ggf4vuDl4nvA4JufB9/NnG9gHcZ+aTNjdt8pr6RVLNct/lncMl5VrmGtx2l+u/+1EzzFcRKd TMdyej3pN3ikFna2F/BsL8H/zvPloX4G/UFar7bM1f+o70EZxnrVFZVvkO8Db3DPrmdHtNGovMXV haU6qfqq5WFjzRc9kQH2hVwZ+M93eoX5qv7WVTttw+3v+eS5TMMDTEuXd/hzxVs5vsJxOAP4MMfx hnfKTzwD1u7l7o3YNCT9sqHbGwHdoB90uvQ/a8ptfXDpT1Df55J2+0L0QWWg+OG7TuboebIPHvGk HPrVgryP94BQ4ofB2wcHTbiCpttIaAI9/UlTEO5Pk+CGDQM39sGBG8+aDxU/cMYImsoNTZD5QPCj LzSBFtA0xdD04ADRFIQ7anBjLxq4Hza48fzHYPCjP/wnbPZJvn7WO/w9xqtI1tplfHM3X2cbX2Ov tT/lyTO4wK28tGnYRjK3xRwEXzPMzAYwwi9Kz73gI3WctOdpyOt9lCEdNnb+s6H1EwG03mhoRVkY rQnqu6+02xfiK10YaAsYsL3+kNllHG8g4cOfKJcP+0j4ADjKB5cG2EJmfraW5126shQ56Pilc6XR hgb3XpCMQBNo+0sAbVhHuTJyaUtQ32Tkti9ERgNpn6ABNF3fD7K+nsQ+53kid7zQbfMT9nmNJ/Kx dd6moYUy9pm9QlMLzayP1EZ1jg1aENVGYZdqu/ns9HISmq+gXJp/RkKzrQMuzQnqu53a7Q/VTgED etQfskOEnYIPN1IuH/ZRLh9cGhIka/cwPgMu4N8SAP+FAuFHqW+2ZrcfalsDDaDpF/0grz0ktnaG J2c8Kx1+wtbu4IKxBrfqrU1DF2VsDftwsjaXbztmj4q5NqdjodqWvUbVsVLb6Poynw3iDAl9uYZy +/IQSV9s3XD7kqC+26Dd/lBtEDCgX/0h06+S2CD4gLW2y4d9JHzA/E/54NKwjfDso+xMYGUY5xx2 K/BO00LK+Eld9+taELThHmAi6rrQ5afKC/SBzoMBdK7wcuXl0pmgvtuy3X6obRk0gKYn+0HuHyOx ZV2PNjn8hC3jXW7ISfnp0rCJ8M3zpPlOKp6+xDPmGbmqjWpaZR1mj62Gnu0B9Fxu6LHl69KToL7b o93+UO0RMKAj/SGXTST2CD7cTrl82EfCB/sc3aUBcPQcXeejwBvEc+AArj0BuP5qcNk8d3ElKP/4 +zMD/64A+FhnFgIfcML2hgAX8O8JgH9UgfCjFLwf/FWS9/MAf4KXC/9oA9/1jTb8bSRn9PJNA8wr m/yRDm9hAC/sCzjVPsBHNw+4dj6IDzinAJ2TAujEM0WF8KEyBP4TJHAB/5sB8C8y8NWmguBfQrnP aff2jLHNB9eH2DxBWsd9RNvnuP7HjkF8/Jbp57UB/ZwXKYyPx1K4nK4z8G8MgL+wQPhRKtzHue2H egwDDaDpHa//xjDsD19Acn5j8xNj2Fte7hhm07CJr9WsgfW84sdbUdBPjGGu7rk6FybfFkNPRwA9 lxl6bPm69CSo72OY3f5QxzDAgI70h1wuIxnDwIfnKZcP+0j4ADjKB5eGRs5XMSdq2C9AJhmvkJGH a88637djkIxAE2jbH0DbfC9XRi5tCeq7Ddrth9oG3/XkzOvkyOGfL11CYoO7GUATydrX5idsEN+z AQ22zts0bCB8+wdrP/m1ly62QHsOqXLVfZUw29ti6IAvcOm41NBhy9WlI0F9tz27/aHYHtoCxh5P YCiv0dewdD7bu5HkzBx8eIJy+fATEj6UUIYPLg0tBHls80+w5QkEPKUQ5fFb5vl4LgHysc+edX1u Py+gazxbfvocQZD8QC/ofo5y6Z7p5crPpTtBIj/ALUR+bvswmeXjd5KE36AXz3N+NYDfUyO5z77Y eNdx/gP+/CfFvG1O8xZR00HveiECJ3ADpov7ZYP7H41nGLfBs3/z5Hwazze5PMNcyB63XbybCGtP /FJIF2slVp7Q0gy/VB+he/azDkgH8fE/DD04k3TpecPQUwgfC/UdhfIxn+9AW8DAuNIfvgNj7mpP bLDBy7XBX3pig+o7cXVpEH42+TsBkJ/qbpj+Ag/wpQLwPW7w2Xx38SVI+F4WAD9JMr4DPt4zdeH/ ycC3bdOFD9s8jtduMcLTN9GsdQbq6zVIx79kcON9Uhc3znaB29ZxF/cmwjMECzgK9oU8+znJwu/S YccgXv/W0PNAAD0Nhp5CeF2or3Dbh+l1IToJevFtS9fHQSfh43rTybPYO+ywdDKfTwUe4GsLwPeU wfePxqckCZ/gw/A8jOvDwCf4sN50/Ux/Lx6/1ya8sscftAnSdUTgBG7YsYt7v8Hdd54d9OH/lcSO Ab84kgsfdgz4k/PAv5TwXJ47p5lLW605zRJ/BopfwLvIn4028X05D8zoTL75jo41uKqf0LGoxKTR Blfc031wGzauyvcgPqP/4AN+I9Dlwx2RwvkMHEHwxxv4+E0gF/6v+wAf/VtF8l4bcBw4GPrd5ZKB +K6RyhTfNWo7MpIjU3zXCOX6rCW+a4RnLdEnPGvJXTms75YvXNr7d43kDuj9y3FXlxbVFNXId6JB F75tjjJ8bzyx5S/HgV17mAZ83+ilOVUpwAdNgOB+1wgxLD2LRO7Ys5Tg//Rnuo7uZcLvpmuYADs7 MSJ7rqCnv54FqjRp4O5Pf2mnFZ+OE+jfyRwv8uT5vIs9Kcf6vAXIfbwHhBI/DN7zeaAJV9B0GwlN oKc/aQrC/WkS3N8mwY25MHBPp6Hjx7UkNF1HQtNTNHj8uJ4E94c8wb2XBDeuQ8WPhCc04QqaYAuD xY+VBjee3wTunxvcJQb//8b31E+JiJ9ZFgneK8P4H5YOGl+xV4a9fzAE78UAlr1XdqYzvro0JEhG DHcPRWnvrQ+H4yv/3RNfiSvKda9oKH0laNErfCVoGixfCZzwDbjCVwL3ewfJFsJ8A2jRK3zDYPED vgE44RtwhW8A7n9U36AwD3WvBBE28RO+eRrJGt+2ZfDlfMeWNbi/zQRchdiy2z7MfvPRvYmE7vs8 +Y45ziVcunsi2c8XuHgBp9D39AEDuBIBuJoMrt54hOcLwvaMcR/wzwmAj3OAQuADTth6aK2Bvz4A fleB8KMU/nwB4AI+nqdz4V9k4NvPF7jwtxG+D6hfnpPfKMWq6QJ/NSX4oENoi6umEXXdaa9HXV0E nbDvb5DQ+QPKpfMhEjoBM5/O9BC+sxFN49O1sYsPzzLcavCd7eXiO2DwQefD8F1Gmff+BC9S8qvO +LaofGUUf+WOvCGM+5k3L/G2nvINeo5o0655u1z3mN16dlptBjEIrvIFuHHN9nuyJwLdOcczuhPA o7u8wnQn/B3EbDoR7ectAU/3PuzoyjLJ8RuGztsC6Dw2InTa+1IalM51nMbzIior1V+bp9l6JDz6 GAlO4H49APdygxt9C8O9iaC71TSfqmghW5k8w5L9/KJtV/bZTRAvQAfoGR3JpecLBfLiWF9Oa/1T cfRdeTHa4EW+L+t86NETRo9whe5cHJHv2oC+gVjn94U+yBB0/dFcITfQt4yGdh9CQ1/G40LmHa7e gAewR/QdawTsp9p6Az59ugD/m/ItqCWtt8AVtE5pjAge4CuK5OJrNvjOzYMPDfBeO87lLvA1Vd5m 7mQK8H6FvB99kX9H7RpPejQS3n+H95U34/VJuc2+z9YnTZutO2iB96zb/K+ZZN6W1zfrcQe19T1s adXp7y8CO0YJ/epANl/svV21K7VzHSvBS/vMUX0R8vARto9SP++ODerr9R7a2f7NhYO0PaYonTa9 dhv11ZpGW+RRR+nWtNKGMm2jsPW+7XMUlz5nZz8XoHVsXobNE4dFRN9GBOjbTRHRN5SF6VuCZJ4Y ZD+bSOAC/jEB8H9o4Pc255VvOGR44s4Z+9NPuH3YHREf8ArfPILT/xPgA74ekW+OhvVhhIfn0tzv SmBkTfFcABayzbcbzIJkLoTvGOBEBHYk9lvJY+GxpF9UEXvEHeypt3CJzD71WTpY2ha/TqsPQX6H NWlsHFd5GxJ79fIbrMAvNi0nL0n+22kosG0x6PxFy2w9tPVWdVztUG3Brqd2aNuO2jzq6vMs9rxI 66tN2rah+q8+wbYxlLt2pHjsPti+Qe1M+2Hnta47B7Xpt/tk17HnMkqrpgdLxy8h0XHsKdbz9b3G 5m0dvzkieMN0fAOntxqtTfG1h+dKNm9wtedoKHPpQAR+0LElgI6PGjpQls8fRQ2OweIf3vEE/0Yy bf/kyRmey7+7I/Lb5WF030zov9gpeLjDXwfBlvEXozIsu8EfYW0Pgbx4iKDVFuar9td9sscbd/xD 2h5/NK117PFEx64wO8Z92y+4ay21IbvchaFjaSHjGL5PAf4fE8D/7Z7wvze9CdvveAn1DPzPBcDH GTngT8wDfzfpOBb0hSH1/ZA3vC6+SATfuyjLl9i+I8wP2/zVqy1PLVMeK3+DePp50+crA/qM8bwQ nkYNnv60xVUk59tYLxw4mHu+DZqKBux3e0RWOC9OHRnJkhXw4Hwb5WqLON+GLYI/sEVmWeD5NsZr nG9jvM53vn3lmkP/3Z4ND8nvauOK39W+ZvT7/N/VBm/f+c/lqfedU5vCb2njrNvbnXu+DX6HpfP5 RzwzAf8Y5et3ucLcAP/4fET0KEyXniPxj5k9ttxdpmDL2uzfl12lzBwKnhFreUDEPXs1gnZ4WkXm RJA25kwCMbOiyuBVP2VH9Z06p7B9rV1H/aNtw/YcXuspHDuqbQfNj3AfMBQWZGS303taT/EBjtKF aOPWvO1rbBrVt2h99TtuP1z9uIfj9zzRjzGRXP04NSL6MZ7C9WMHBc2xTwnRisJ5bvM9X13k7X5V mHt67c/5xroI3tHg8Qp88eSc0bWnP0dkDz2MX38l7IthhYCvL8N/yVxf1vsraZqv/bKSx7XTf0Ya qwetE+c6YkXL/PWD7jLDomRdgXd7sAOgnMccJlce4h/xJpBYF9KwSDxjHGVbxzcjU4wpw2uVhUbN q25rHv3W+bUtLzcPmPZegq3zCkffj1a7UPtxx9IgXLin47Rdx9Uju9xuG6RzmrZxB43vdjvX3yCi 367uQscQX/BEx7D2dXXs0ojoGMp6G/+Bx4Z/uLah438xBf9uH2gauPFfbAPj/w4e513bwPiPcrUN eb6tx+cPbCNs/IdtYPyHbeQb/4vX9eP4P6Fv4z/4HZbO5682kYz/1dz5Gr6uCvBX44f1vg+0kldQ 8AOArbofpLc4XwWuRACuRoNrKPTWni+FpfPxcUNE+Lg2InvyTQF8nDdMziry+f311rwH85zzKLNH BH8tvrkt64tZm32vDD3HOYy7HwXP3cn/tLaOHNm1sLPURngW1IZcmbULBovFeNBs7BYzMPgxd/4C XUH/1OfZftP2t1rH9oOuX1SY9j17r0LhaDmu9jwLeXte5PpZ258XAsseS5SmIJptOJq3x0HkbVvR ++6crj91PJ/+Yh0J/YXensrpzgD9jTP8kyhcf39KON/IPXnIrAcwkxBd0u9OY6cV+osZiuilajtm KvLUPdYJmHnIHmgnQ8A5SZJrBuuM8j5IHki7831Xj1QO4I/KxpZ1kL7o/aC5hEuH0qttbP3Uurjv ygh71acZ3/JggIyu90RGUyhcRp/hdGauPY8jfvkS+8mdpN8ayOxOr+JV8Rm+D8HpUpN/yprdH9t+ bb3VezondNcgWo7+gWewMf0mB9rbvLDl6/IE8SHDE3wnwOVJMiI8QdlQjSmHMzZXkZzrYmz+ZIBN nl/A2Bw3Y7Pti4L4CBzAhXNOF1eDwVUAH9f1Nx9tHinv8o3Tbt+uiQgf/5WvWMd+LYCPPcPkTDms b+NgW9y7sFFV9iTw+7GyBwVPBj/V4/spfFUfb2QmzWiKmtg3hheEV5QcvJz8Bq293sMoiy+hYwck g1/PlASjnCa78wCksRuCMyWZA8u8F3aGPrr7Eb2Nk1rHtl/bthWO7dO0rV1X03Z9hal11Q9Dt91x UdspPci7uJBX+nG1fZPm7f67fjuIVhtm2FwEcOxxX+FqHZu3QT6tP23Fhgs7uIxkjP9qBL8LQfSd ADv49DChPcwOYCN6FpJtA7nn6/n0yaUNMUlCWyfl0vZFEtp68z+zKHjPHGuO7Qa+F8mFf6WBj7ph 8N8m0Fa4XYtPwF6JfVqca+2ZOU8+yLBx+AP5LiDsGe/rwSfo7AqeQv2D8ry/bdH2AQrDnT+p3hdi tzofsPXmUGi27VLzkL9Nv62Dth9QuPY91zfa+jSQNvoEmfcKIvJc6f8NsNGvD5N2YXp6CaeD1nPi /e1RLFNLea1R+ag+ypUfYtg4EgTL7eernjzPin7ivTW3nwdI+nkmhffzUUI/M6uMzLmAfP8Ac1yc DeAUyD6Z1fkvLCsZaJE6/vY2nuqzxYCfn1+2HajeuWOoncZ92JDagcJ04Ws7LbNtvq/j5eGMZ7Yd K1zXDw+k3XRFxG5u4+sbXOHOALu5eZg8CxGmT0We2g20Qc57C/PNttcXLx9e299NtJ7ck7eroUGN PgzoL0YM+day7tZAe3EaIM8FoUS/CyvU2TZn65nqhO3rDsfP5hsbgnx/X2Br2qbNrq+4lA57zmb3 2cXrzu3sOvZ4obxx6XV5N5h6jb186DX0Gd+ieChAr3/O8M+ncL0emdZrd38vzPNBq6Cb3ay78vyb vQbR2cZm/xuF+HYhZiL6TFxlztpITmnxjCvsQUrxhnn4WsYdqYLHlDB/21f/Z88BbBzaztUBhWXb l41Ly2ydVlyuX7X9tT0HURj2fZTZcxq7rubdsdjtj9tH1X2d2wWN6aUGL1lzdegidBJnwq5O7omI TqIs31w9au7Z8AfDlkAvvunwTIAtPVyALbn6jRk5/DlmG/JVMPmqglpKq39FPt9uu67Oz/Q9vOzE 5d+d1/kOaMFZsW2FKcL+K2xXaVFY+XUOeqQ6proR5K9d/VHdstsrHuhWIXPEIHu2xy7VT63fH/DV jm0bVr64/bPtF2W6V+mOt3a7oVpH4L0Z6Pq+iLxX83qArr/I8OspXNdLcnTdfqagEC+P0SBsnMj1 +hgTRKfxXIE+Z5AZkXQWLjOe3s63CtN3W7d0LFB9yGcjhfplWz9snc43Ntjt7TZ23tZlV38Vns57 XHz2XCaozNVbex0SNk7ZtAW1L6X+03ttN96UAZ+d/iDHMq5wqknv4PhZwhm1PLuM6zrC7wH90cIa /I7UQfMIQwvH40neMdw93Hxbl+T9KE17voXJ/aCgsDQM25t9f/Se7PzB3VnZYX81Ce/gwb/zZfEB kx/NgLnqwT0mv4vzB2iYIhsGnv2dFqONVucGu7Q5qh88+Od0cz+bodUzWW0+3OTfyQJ38OBek19s 8gpOwIMiCSar7X3qEEzv0nmDT9EpPaPT+d1+fko6LwgXp/N7/fyu0PwBP5/OCkHa24OGIDefJs8Q mCEvJ+8TPNrKg+B8eXRgSi/5xVYeHepLHh3e1UveyvaaB8MOJw+GDmk+2sd8P/ffzQfxe1cf84ut /N5e8nsC8lN6yY+28rudPGdz9N+1D9d+8tibOAg3vyudR3dz84vT+b1+fko6D/Jz/YfrX1z/kyZI va+b32XyB0x+scnvNfkpJr/HyZus1lf3qnkFTzulQMHR3wWAgqO/Gv+u4R2fQvXO5L3jQ0w3H3YA XUrf9gehKRloNCyT9MNwJz96t5PPzubkMbjb4f1OvsrJYyC1Q7KX/N7srLfHye/OzmPsLz0pfG6g Qcf0BMdKnlTs4HjVfLl3J12ankNUWnU9f1YSHiD0F/b+he7/1Zv07rvv0ve/8SY99ciL9KWd+2nP La/TlsUv0puv/40uXPMcLSl5lj6+dT8toH20auZzdN3lr9FbB/5GS0sfpXfeeoMOvP4KvfnGq/Ta C8/SG88/Q+/8+U/02isv0DN3/4Lu+e7X6Zdf/Be69ZJm+m7buXRT93l0w4dX0k8+maIHb/427X/6 MXr09h/QHZ/fSddtqqGr686g33zrCrr/R9fQ47/+KT38q5/Q0w/9lp59/D56eM/36b7vf5tefOT3 9JXaufTyow/S66+9RG8xDa+/+iztf2kvvfDso/TJ44rpT//9Nv3rSZPorTdfp1dfeY5e3f8M7X/x KXr5hSfozm/9C11RXUnP73uYHr/nx/T11VX032+/RXff9BU6ddST9NxT99Pbf3yO/r1tKV27uZr2 PnYnPfPkvfTZbd+lP/ziRnr6D7+k/c/9ga5cu4n2PX4XPXD7DbR85DX07BN30/6991HyrDuo6aTb 6Zvnncx199C9N32OHrnzB/Tkgz+lF576HT3/xG/oRx/fQE/c/0N6/Lc30n/dews99rOv0bMP3EZP /uY6evOVp+nWnWfTi8++TrffeBfz4Tr66Wcb6bFffpN+9qUP013f7qYHfvgpevQ/v0zXNS1mnq6g h398OT1y+xX0u1t20StP/Zbu+8HH6KYv30cvP/Fr+truO2nt7Lvpuo9dSdvKGvLqxf8P//uDNyjh 6MiIEUcPCq7IiKNKRhzpDTiuo48eMWr0qBFHc3KAcUWGDR89ctSwI/1MobiKSotmT5xUVjE5OnPm 8vKKyWVTZ08bW+oV5WtSFCk5YmTxUcOONgUF4Ro//9iK8rpYXWdXfX1re3t7a31zV2d1rK68ctK0 CSFtIpGSUcXFxUeNyJDTO66iOWUzl9fFquJdqe6Ojh4TOjo6Uu31nXXLZ5ZNW5DbiLXhCB+TcE9C L7jGHl85q7qrNZlKJZur4zXtPT2pdADCVLK1JjazbEKp1aboyMjw0UuLi0ceYfUJIS+usbOnzKpr ZaA9gNzT3hnvTCq2HpRI/1rr6iZPHKuNuEtjuEvFo0dEHHB5cI2dHa1uTvZ0WB1JdsZrkgy+J5VM Jlluzc317e3JZKq9q658einUYZjfpeLiMSUupjy4iiaWs4RsngFbR3tnrL6+q666ujrGoa6ujv+y ltR01cWmbCoaMWokEBWPHp6LKRzXtIpYVyrTJUGUSrU311Utqqpubm3l3qRS6CF3sb2+pq4uvmjX EYLJUvOsEIyrdF51RjISOjqS9XWxeF1XMlkTr+9mhUz59yE3CG3GuWcLouLRw4I65YXgmja5ujUL Uw8j6oyxQqY6ALt1UY0g0tupJetMl4rHBLLPDwG4iuZwp2z2sSV1xmNd7Sl0xi9IxmLJDLKesnW+ PiCcvWp2LkQTcnGVTl1Un2VGKbasznZf8TNlnXElhzEpouIxK1Jdscowx5WDq7Qi3m6peUeyORZr TkIH7NDT0xVv9cusPhV/pKwn1dEem2FbthVcXKdMrmruToPsSHbF6+pdzRdkzYu4r2UrMpiWrpA7 yfjkYGQOrrHlsTiUWVqlmuOOklihozneusL3EIZ/O9MeJVaR9iLhuMbPrGuuUzn0tMar6x0by0K2 KtOn4uJzl6Rv9KTqAnuWhWvs5M6OumYhr6e9Lt6cpdnZoWdJRiU4CP/0Xqp6coCC2LhKK+pSqVg7 4PekuuD5QvDgvs2+4uKdrvLEK/LjqowlWYtgODCgVre5HXaea2MqXnruip3Z1p2MLcmHa2K8vaej vs7XCccxZAfulC0pEz6ybqdVp6M9nmPUGVwT4vUdqY6uTqapjjvlgEfQTNlHcjH5YcwK1UVGVh8b F4arNFrD8Dtqarrb43WmU2Y8NGOi4OvpCeqUhqXryhRbT2fU0Y80riUxv0JdfT2GLe0KcGSF7g1Z 6heEbadwgM2sMhjXtLjoX2c8DqUAlgyebvOvo7t7Z5b6hWBbIshaY9mTLMVVDg6CFvaGVne6s8OF K3ToyBvG7PTF3VMzJcukDa7pcfCNDb6qvTuNyUEEXJU7130kj7gkLN01w9hLLEsXBVfRrHqgSvI0 or3bcM2HrWG7H/xrd+UKTP1Cw5gVU+p4DILDZguy1UNwTYViMAPrUnXAlcEjOOzQtLUpNaV6V1jv xqyAsNpr4rFWqHFsuourlL05GFjX0VPdvt3g2c6ImrY3ZYW2tq0b6qtjPHJur8x2UhJYLUTfMUTE WPL1s6yO+bjWxKB5dbGe7p464JIOpeGnw9am5PL48vaOtq1tfPcsx1GxpypTS8bEoQvOJzYvG9dY llZPR00s1Q1cTRYmC09bS0NTBQ/RG1q2trRpP7Ns7SPso5Kp9OiHEbo6Vb88o4rANac61dPdGk9e 2H1hd117m+BJozChoa01VjejqXGrKecaH0p7kKUjjxhVsmMbh5UXr2/Ynh40O2PJ6ok2rtIpS8Yu G3/+/LHjl40fP23C+PFb0pha2i4+c+HYU/z/p02cv7BovSD2GbrG9GrkUSXDMozyw+ItTYKts7qm wsa1LLYlu+Z6oJLOtKx0bjVsbWjY2tKytW3rJPHAMnGfNrVscvlMDtEpFZUTx3PJtgZBFq9OOw/G NbV6rVexaFHchKneekHFUBsaVnpl6TuLKr1alCFsvUjUcNSRXunsybFFVXZYNKuSESy+0DfnqrTa M67y+pVeNFNxEuNClySs9Coyt8q81Y0cGhoaN1/ii2rpe7zSSbEsPBomz/dK2+AUq9JzD/ImVCdX epMzlSZ5tT4iQG1sXOzNyNwq8zZt5tC4uWGFiOo93gSLyuzAXChq8rmoTCRv+vLuHV55ps5Ub3WL YGKwG0/K7tc5wLXxvKME1SgeYHORWNXHd7Djqzo+jWtGV3Jedr9WAxOArl8/Y0l2v87fuHHjxWtG C6rREZvGgDDduxhDYoXiGhtNzqrM7tc5fo82b6zdPIX9WVa/zl+/cf0FBlXxcK/ShjyronJSWbnd 0eqiIp5W1EcV1/yZ7fEt2f06v3Ezk7+xdk318vOWZfdr7fqLL1ADHhMpqs7cm2WGjwlllk5WelvY l8RONrim1XXWbMvu1/k+qk2V8YpE7WnZ/Tq9VhRQpDUxc4tHxfFr169ff5rnzc6UlnvbWO1nGddB U6tjKUcP1zKmxKaK+JJzahMnZvfrpEsU09JLtnll6TuLJnhzOy9s2n5h99ax3pJ0cXxBKWtHzSSD q2JRTdPK7H6t3bi+dtOU2LwPJGoTp2b1q2i4ohp9wcXLLAorvGUbYh0tTU3bu7d60zJcnFbUnerp MspBk6va25x+nb6xdn35rDWn13I4NbtfOiIfddzF6xd4M9N32FDaqpfwAMDj9tiiWeny2R7bc02Z wTVrUXfbadn9WlmbWD5r4weBqja7X4prVO2m2sRYL6MarN2bZ7Y28CDQxLgy5RMZV09zuQyYFO9s aTotu19z18+atR6oVq+uPSGgXyMv2rGJ757iZeif6m1qnNLV1H3s9ratpdn9SvY0z5TlGFXVN7r9 quBeneOjWr36/9Fy/n+JG2kcNxJ1v557a1IDkm/rhgFFLQJBvibEwY1KbqH4gjtRrOie297W7bXd bn/sn37PTBJMAm77el19MLtDCLz5PDPzzDMTkhm6lv/zG3wJwgrqUk+bTYQQPj1ajeo68kL9XEUj rJCuFAZVBNTr96Z1Pd4c9Mlr7ZWQrhNTzZ2dmT9q0mpgP9V1hNc9H55dfdDDukTUIZ/W7/edfjyq 62l24MArcEC4vgbDDIbYBlUmRHWd+iz87upDRFcPm1av74DZTj6i6/lvA9t2nIuuvd8I6bq4vs5l rmEweleO1Nd/mzmfdXt1FdHFa6hNSTZhhXQ96gLKtg17R4JEIqjrYjzGB9dXwArrgmGlgiasa2CF dDU6OG0REhgX1vXeAuta6WMsvi2HdY1Hx+bo6urDbbR/fawolLVLWNfFsC7DSiLbIiTLiujSLatu pxFOdgyrFa6v8ShljmbV13e5FG2Hr+dwZgyskC6j38eq4QDJsiP1pVtba0CyDPgqrZAuCKIpcwiN 40Okf30+/Vmh/Wt9LnU2mtLl1BKvOJ6v8jwvhHW1quvptTzLV+u2XQ7rGg2BNQZWJG78mJvEDQUO iOjS+5B0sfQPtrtgvkfjGkv3Vy0rXF+Wx7oO6Uow6tHppR8P1Y/tcUQXYa1JkijDQxQDaRIW6R5Z XHNZQV3WEFhtSHxuwvWl7F1eqh4rKbZHUV1OlZHvdswwxBRKUV3DTirdHo3HV+H6UiufJ+NX4ng0 yod11e3qHyQtkssK6eq0j31WUJdc+Xzqj8u7yvUoOOqBLsIK7JhhCrBKYV0loqs3Go2vw7qUyiX2 5mBzq6lM5zAow2V9WZfCtIxSWFe300ZnvSFl3VVxgjFPT2UXBfmhbMIIm1Yk2XskmLpVDe6Yfkhp YBkCo0n+jixh4dv2cDQC1mQ/BIybo4o2YWXk9qH3xLO4VQjvmGFlwgpat72PzwlrHF6nvPo5kPcm 0NDguerK1oZQKKwUYL6ll/IrgiCwsYXZ9iLGClyjwZfBWu78jOcHvRPsdIbgROOwWCySed/7952d 7u1pxV+XmmPY1AEMwr2BLHZpBLRKJcMwGvr72H1LNE8X67quN+CoUonEMRgOYDizzeM+YUGNXZMQ DDPPT7nvPn3Kyb5QmBNpKmRMPQcdWB6qRFD1ojdBiNrywuFhncIaIZilSU6bCiMwMvW8+QX/Cqzg /GsXd3o95xyPqCwPpR++mI16usjH47Wap2zCcvpdUXQ6E2Ewz73Rmp/fffqMdwMsPnVm96y0EvCg rhcX/RlCyN684FcO83lghWHAshST6qLCwIk3n5o/3P7606Xoo+g6wCvJ6XWTsseildU4JCcbp2w5 JnAcl8/np5Q5g3180qc+JMJgrniLjyA1/YTvVm4IaxVv97uabPmyiAcfzVoDerrI8jyFEVY9xLLe 4nNoYxMnXv+Cf4Lm8TGwcEPXbVS5a4hq94713pi1vPW8KlSrExj1ImGVrBJ8TSN93JuwwH5w0/uf X01QLms1d14UVfIFfVkLM1BLglCoujDqRV9Yo25sjTb3RWk0vKA9DFgjrWJe3b67/fFuxcFjMaJY VEWSthCWrteNGQ0DpvzQcSmNwmiNNYxafj8toxTGlRxCYga6GJm8mU3zmiy4HAeXYV3Wam5kin6D n9neX36jcowAcQJorhdrpMq4BiRvirZ2nt3PnewfyE1xCHGqbTY/jqGH3XxEwXPP3rqoJh8ok5BR Ly2/ebkM9ualv+T6LHYo402GLZeJMioMnMjXdlJY2y/V9S5UV/fCGpwgZdjumRVtRHrYLQ7U1oRV xcnjrF9dxcWFWGzx++83v/Gn4S9jLFnfUePEj74T44UNBSdLeYNUtAEhDvJyZ4jVgZbThqQ33/yQ mrXey2QQ3jH8pvGerILxrPmdF6aexRiWZZmvZJxh2ZbnxCqn5VSL171WjzI2mb04B0hsnrWhh91c nVX8CB9msWJFrPuseq2Wz/NxxTvh+ZKiAMa8xkqCEQqkKVYbMt7ga14Pa2RQz6Gs80ozQ1IcYJ36 A1eExaw3m1njjhXnqlsVtz+/eURV0X+qSSxnBZbnylkkNTivh1lWUZQtYPWs8+O9s29pZ/63iCNn 3CYsZmNPrXshnujiyhnvhPGCq4nCWGZdxXKCZUtY5Di3N5PuvIV2uk6vPzBzMjpoE9bYzE2C7hQL sqsNfcIqHvJeRHzh+Y+yYAiltNeS2OJoSKQsYwe3bac7FJvmPjohScf4XTO4hB1lsQp2Ay/14UrM rawlgRVcmIsqt1jW0ip76fVCgcCoDw1JNazuAUZvuyaikf4KJafO7AVYTB6Jdd1lFbmaGxGfCyQb 8E2gvbnKZnFSwmIGOli9QVyYwOeNjtjU2k4HaRckSMmStzB0D4tZz2l53dXFu6HjMSeUAzCPJUgq w23AFF7csRtc3ahB8E7nlG2rNzDxaDgaDqVQwJjFYr7OqXoRWPX6IvXg8iLbKt/BKKpVbe1iG7Ih vratIiwlT7ZspCrYHNi9i/Om+e1w9O0lqk6jIiwm21R2uZpedBvGm5jAt1yYa248ZNNSmQ5heb5+ bsrKMd6ryCPLuRiMkAr/jWT0J84vAyzXPOHyRTpUvlmA8aoQgLmoKqtqBS8PqOeF2hreSykIpSRR yzXNM/NAmqlqmsWsoz2x4zaMf8IoDLBCuUUyQZoN0sjLyOmCOzLX8tZaCiFsF53tA1Pew5Ki4D1l Rl0Rm2IxeXmvSVf5/5XqFjgKaxFtNO+kLFZVC5BL8QV9U8XI3JI0w7a7xZNTcegMdnBypgOZWSyG 1SokYizPH6Uhk6EwQmtNRsryCYpzhfxGUsFyxuAzOFuyu221qfUHfS1HfuMz22awmAJtGN8kVVRj hTL5fMorVEmxAJVXRckNNYXktR5XM0qKVjScA3x80rXfIpS9/2dns1jzpL3/462KKkp6O/sVmSB7 sYNlCnp2M63CBEvdtmpc0TDqB8jqJBFOOiANa/f95IzYLBb9HdqRlM1vVpoSbV9aeieTWUtqqqyg lCJpmQySdkrQOhq6jVMiPk62GzByKYkv/ZZuFisG7X35CZfGYnYb7axnKQNMUlVgJrZKPCQClpkC iChKzaaibtuHpYyC09NhKWTTLPYxHYghz0/Ch+G0QNIn0gK9ZshxpLkX8/nEjpk0tcp+0WhYBwo9 XfNlm2Y9IuMILQmryVRzT9otFEh64RmdOND8Gni8gZJVa19LoWT8i+6jNsV6ArKeTt63+lrKVdRs Wai6OAB5KJKG6rosbZhKSt6YHSgiNsV6RM+T3Bm3npZyUnJ7N57nC5Bp8EDkyF9RL2XVPcg/k+t/ UE++RVlPIEt7FN7FsuuvwUuSmkxnNjYT2a3sxub2TlpVoU1qia/dMfvPWJS1QM5dzLB4PLGWFMn8 XpLIEgE0ylcJdwnyT1uEBbIe/33mgQwRuMLxX62CcdwKc28outcirKW//S16TvWvszBr/qXX3B/E wqwXX/Dg/28h1vzys3t/PPgXWIi1BBO6B7Qg60kgYDyEBVnPH9SDIVbs2YN6MMRaelgPBlnzj4O/ 034Iu2MtRULuX28T1uLSA3vwjsUuPGwbJOaz5h8u5E4sdK295pXJ1ezBMrnWzb/Gfg22F4HrW/TA c3Ltvv/cv5Y/+Dx6PDH/8wiHbP7rpDwOvD8em34ePZ5s/ufNe5v/OilfBt4vkHtgRJ5Hjyeb74el ubnf/TLY71975eXA/udQJve5J+8nRu6t4Psu6EfyuX6ZuMUvB48n91bwy+S2An6ZXGnol8l9Fvwy uT+KXyb3J/HLZPPL5B65fpncg5hs3JxrL7zy/wAAAP//AwBQSwMEFAAGAAgAAAAhAKpSJd8jBgAA ixoAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU2LGzcYvhf6H8TcHX/N+GOJN9hjO2mzm4Ts JiVHeUaeUawZGUneXRMCJTkWCqVp6aGB3noobQMJ9JL+mm1T2hTyF6rReGzJllnabGApWcNaH8/7 6tH7So80nstXThICjhDjmKYdp3qp4gCUBjTEadRx7hwOSy0HcAHTEBKaoo4zR9y5svvhB5fhjohR goC0T/kO7DixENOdcpkHshnyS3SKUtk3piyBQlZZVA4ZPJZ+E1KuVSqNcgJx6oAUJtLtzfEYBwgc Zi6d3cL5gMh/qeBZQ0DYQeYaGRYKG06q2Refc58wcARJx5HjhPT4EJ0IBxDIhezoOBX155R3L5eX RkRssdXshupvYbcwCCc1Zcei0dLQdT230V36VwAiNnGD5qAxaCz9KQAMAjnTnIuO9XrtXt9bYDVQ XrT47jf79aqB1/zXN/BdL/sYeAXKi+4Gfjj0VzHUQHnRs8SkWfNdA69AebGxgW9Wun23aeAVKCY4 nWygK16j7hezXULGlFyzwtueO2zWFvAVqqytrtw+FdvWWgLvUzaUAJVcKHAKxHyKxjCQOB8SPGIY 7OEolgtvClPKZXOlVhlW6vJ/9nFVSUUE7iCoWedNAd9oyvgAHjA8FR3nY+nV0SBvXv745uVzcPro xemjX04fPz599LPF6hpMI93q9fdf/P30U/DX8+9eP/nKjuc6/vefPvvt1y/tQKEDX3397I8Xz159 8/mfPzyxwLsMjnT4IU4QBzfQMbhNEzkxywBoxP6dxWEMsW7RTSMOU5jZWNADERvoG3NIoAXXQ2YE 7zIpEzbg1dl9g/BBzGYCW4DX48QA7lNKepRZ53Q9G0uPwiyN7IOzmY67DeGRbWx/Lb+D2VSud2xz 6cfIoHmLyJTDCKVIgKyPThCymN3D2IjrPg4Y5XQswD0MehBbQ3KIR8ZqWhldw4nMy9xGUObbiM3+ XdCjxOa+j45MpNwVkNhcImKE8SqcCZhYGcOE6Mg9KGIbyYM5C4yAcyEzHSFCwSBEnNtsbrK5Qfe6 lBd72vfJPDGRTOCJDbkHKdWRfTrxY5hMrZxxGuvYj/hELlEIblFhJUHNHZLVZR5gujXddzEy0n32 3r4jldW+QLKeGbNtCUTN/TgnY4iU8/Kanic4PVPc12Tde7eyLoX01bdP7bp7IQW9y7B1R63L+Dbc unj7lIX44mt3H87SW0huFwv0vXS/l+7/vXRv28/nL9grjVaX+OKqrtwkW+/tY0zIgZgTtMeVunM5 vXAoG1VFGS0fE6axLC6GM3ARg6oMGBWfYBEfxHAqh6mqESK+cB1xMKVcng+q2eo76yCzZJ+GeWu1 WjyZSgMoVu3yfCna5Wkk8tZGc/UItnSvapF6VC4IZLb/hoQ2mEmibiHRLBrPIKFmdi4s2hYWrcz9 Vhbqa5EVuf8AzH7U8NyckVxvkKAwy1NuX2T33DO9LZjmtGuW6bUzrueTaYOEttxMEtoyjGGI1pvP OdftVUoNelkoNmk0W+8i15mIrGkDSc0aOJZ7ru5JNwGcdpyxvBnKYjKV/nimm5BEaccJxCLQ/0VZ poyLPuRxDlNd+fwTLBADBCdyretpIOmKW7XWzOZ4Qcm1KxcvcupLTzIaj1EgtrSsqrIvd2LtfUtw VqEzSfogDo/BiMzYbSgD5TWrWQBDzMUymiFm2uJeRXFNrhZb0fjFbLVFIZnGcHGi6GKew1V5SUeb h2K6PiuzvpjMKMqS9Nan7tlGWYcmmlsOkOzUtOvHuzvkNVYr3TdY5dK9rnXtQuu2nRJvfyBo1FaD GdQyxhZqq1aT2jleCLThlktz2xlx3qfB+qrNDojiXqlqG68m6Oi+XPl9eV2dEcEVVXQinxH84kfl XAlUa6EuJwLMGO44Dype1/Vrnl+qtLxBya27lVLL69ZLXc+rVwdetdLv1R7KoIg4qXr52EP5PEPm izcvqn3j7UtSXLMvBTQpU3UPLitj9falWtv+9gVgGZkHjdqwXW/3GqV2vTssuf1eq9T2G71Sv+E3 +8O+77Xaw4cOOFJgt1v33cagVWpUfb/kNioZ/Va71HRrta7b7LYGbvfhItZy5sV3EV7Fa/cfAAAA //8DAFBLAwQKAAAAAAAAACEA26+ii0MXAABDFwAAFQAAAHdvcmQvbWVkaWEvaW1hZ2UxLnBuZ4lQ TkcNChoKAAAADUlIRFIAAABrAAAAeAgDAAAAwiP8CwAAAwBQTFRFosTZh5XE7PHyirbSxNbfvNPd 3Obp1eHlmISnZI68rMrakbrVGzeP+vr6pbLP6meF8sXQKESWlqPJ5FR2daXIsc3bd4m78fP4OFOe aXy09PX2xtngrWiOw8vih6PGzd3iapfB77HA0N7kncHZSmCnuNLj6O3vWW6t5Ovs4Ojq7ZGnhLPP 5O703ufq6+/ws73Y4ursVX605CZS8p+y2OPm09jpyypXyNrh8/T1wNbfusza3Q0959fettDc7/Lz 5uvtpLfQlr3X9vf45z9mpAxL4xBA++DmXXWvmq/LLkyaXIW3Q1qhOV2is8bXytTf6n6XTnWv1uTq vkZwYxxo4uXxmb/YRGKm3+vyfpO+z5mvyKy9rMPWvMfaR26rxoCdy9zj4+btP2WnUWqpz+Dq2BhH kq/Nzt7mvTdlu8XV7+Pn2d/qssDVydzlyt7rqb3Snq3Mx9zpz9rj8fPzp8fa/fDz0dfnpbDT/e/y p8nd4+zvYFeY4QAzf7HODiuJ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAzblzxAAAAIB0Uk5T//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wA4BUtnAAAAAWJLR0R/SL9x5QAAAAxj bVBQSkNtcDA3MTIAAAADSABzvAAAE01JREFUaEO9mu1D2tgSxgMIVCBqEMOJyItAiYggKi5SCyK9 NYZEKl213K2sK760V11tcdfKGsK/fuckARLEtveDd7BCA/LLMzNnzpyTEB3Vtia0F8/4RGjfTa5s PSNF/eouq/P6HfncsB6r825WfmZYn7X15tv/jSW/m3xmL/Z1dSberjyvMB1LHn/7vLmoY3W+PTyv F/WszruHlefMRQNra/lZvWhgyfMPb/56vvwwsDpbpw/zz+dFIwsi9vB8RXiA9W35O14kSW/K/Mce WCrllUv/s7MHWPLKw8P4MC9ubPhvTAzLcizLNvBvmr7zX/xvuAFWB4Q9DBRhkrxYrEUFlja5i4ef /ZWvlcPPl2Numm4I0Zr/b/KnK9sgqzP78LCsLx+pCzfLs6bL1Y2Yudk0m82xWCyFf1rxTIVuCwJj upj+OX2PWN/ePOjKx94iy7voynSpAN8PtjEHlk7HwZI2WzzOsYeBRpQ7LPwM7RFLBmFa4pf2TFGq za42mypIpQFOgSXTrZjZJpgK9lfgYdPGj135iNUhQdhbnPirpijDIHeptLbWXGs2m/DUbBYKqRSm tWIx/1jAFKi5XrVsSft2Q3Dv/UjbY1ZnYh1C9i3lRkzlUhi7qNyYajQHBqlXc4/5v2bM082mPRBF cCoMS1EN+jK8kCk2kHv6+3VgCEseBy9O1tlK7LOLYoUoy9SAUSwqTMi9BlsrFgV2LAPykvEwINGB yZcMbgsN/3cdOYTV2XoLsJmPtOBquC8rf5AyPEokGLxoxiuf3bTQbtOX9rlUy2ZLbwv2EZOATMGq j0a17zlyGKuJhT38Y6KFObI0DSECg1A1C/hlc7pUKgimQzoqcDfZ1Jwt06i1bMFtdHBdDX8UhMrT 0oawyJrrX8Ba3qq7S6mUWeGsKYZTo2BOTV8LG6lm7NDUQFzRZi6iSiYMoqja0clRjV98sng9ZsW4 NvUeC/sUrTZVFGCmwbRENJM03YTUNzfjn2kkBL6yNVs4XG1di0wueDKGTN4nEvIR60JoMyNzkPcP D+9Js4KaVkgKDSszy5y7iUd1Oj0Xs99EBQGFW8HL7QDXRmyjgdqN2PB8HGRVeOoa6s8s5P3D+koJ UFhTSTUNRtK1ZiymDOl0rDR3g9rRhqDkK08FzgLbrDC8jAywKlRjNTUXb5mV9FifKJl1qC6MdLPT SrmKmdM7Aa5xgNouzmoPnp9YBRqerJww1I1G1t88HW/F4+l0+jXO+4fl16SqCmc8SSqwtcLaKgqb UwXz3CUtINZ0/TUs0A0UOAlnz3eowFXOelUeqszAuuBrsXgSWHNz5nnMeniTKvVRGqxZKLG0nDqk DwRmLJxMpW1zNFd1841Le/YkgKw5ay7HCrHHCaJnxQQmHbcprFZKTY+HcRwnVVVXWLNAVpCJRUwx bYbKYctkMn60kxxhqJovOCLUzq3WfJ5jH080OhbZQBmbTWXNbXgnFC8+vCtpNUNWWKXpNZK011xt 90WzOQf13gYsu42lbfbqNhI+VgNCLgcsh2B6NKj7LJl2HcYBloRwzc21FtT0gPlFUSSDqTD5gkbc IsuspTAKWACzjSFfOFjNMVTglXANrKl8hFoczPw+67BNp+GvNFYsNV3E1QNsRcciFZKfJDOISaV6 rMxXYawazB6dBHhO2PYBayof4FcHQtZjXVBUBZ9h14epwlcXHmSQ+bNYkSJLLpgQVymRUKcqAptM KbrAh/YWw9mD2WzWvnPQPrvCLMdLBg1kfpdFMi4mbe+zYjHzRuO9GrLTCczBuEXU8Msl6DpSqUKS Q4fmOegEMCtZFLLA8vmCOy6q6Mvnpxz3DrFmFNZlFQU0ZuuyPpgXoIkhA0uTqhffKjD5Dw4VSXKt CeU3lYoVUjWetpvjCsseFophhbUtMNSZT2Gduf42wDRWAZkOKnaN1Xq9MjHx+j//+fzPb9DBqcpA 1B2iN2RoCHCpxw3IRvOwgUyZmA2zbBxTBR8Gc4g+qfG13JTj9vZ+NGqo+SpLrnHbDfgL7ENbMp1Z Xj9dBls/VZ2IlS1w6LNMTsP0r7E25mB4jUVR7VUmHa/a3AfVc/vJtdDI+bIBV80KLIJAd3phKmuP twaYMGYBLB5fUIuG3k7/oVOyVnwVF0LtheKbSo6xqFG72am84q9fbXMUk/PlrL4AFcoD6j5kKB8K S2aYFs2ALkUYjGWb5js9bQX7T5stsQsBhZvEudgrNydEEXLx0JcWj0ZyVrAAFZgiwA7cOmEKa4/f aTE0druWiAvQ1j+yd6WSMi9r0VK6RJyGybTtq/XzK4a15s6DI1A1oGxYa66Ag4gQHqRrQDBLhtJp Y+gqOFGDfbCp1dBo4wWYzzAKZEG01JEMbrdn7GE7BCx75PNprHx+lLfcRiL7x3f96oFZe+jyqFrj 4A/6wpTJctAmX8NMraF6spSMDwftH9FOjwVDeWoX7RORSEjol0VgyXdsMFs1ceGwAlPKb3JBq4ZG 3PIEdDtKvivRUlyosU5eoesjVRaUDYfDQaA6Edl3osVexIBljp6Fs3Z3Q2NhWDzeej0kPaBezZu9 C9r8b0AFj+yNQBCzcJUH1u29kxolNvfLjJ61ikZgEO4gqwJT0h7mlSF5r2icfG1Wlg8GVeFg8KjK MMERNVzgQhhd9zVKijgl1CvBoKtG232+bFDYBrcrEVOLfUsrUINBW15ZWFAXKn0PhoNHWXuNVXRh WcCChL/fRZtOJ99zItEho9sQ0+wJFBmdF5PxDxOnQ9JDlaap6gYLo7LhwAEMLk0WZkUiTn4JWFy3 3BMdv5CzQafi/XpYaja9sPrxxjMxL575J1aG2/wEWUolk2atP/UWml6z+SR7jZTRlbcttFqtD4qN jFUJ0ZXSIkZ0ipxvAc+6fduwN40Hhvxv2mYrGQ5Xfa/QDtQna95rOO44bnerPSFzgVxMduO1vfrw y2l7QX+g+0b/mXXLa5hVw/sC+MFW5OqIDxGYNVUie8cbF/J93dWdxoi9aHFkQWbbPbuR0+GC/kD/ rd6rBrAy0zLqHVjELOEsi1uNEsn3jvvlgChyXR+uNqasCzIzyNIdGMpqZoAFyzDN7uRMbiTqzuKE L5H944dyw1VGWukg/AdWa0wv4+4ndLFyM2M36rKP+A7c0NXkHSWyr9cvcy5J9KvCCBPjs7aMuuLB gswNUdM/JKgsvS471qWx9Lpol1S/0Vh0yJdvGXXFj8zyDcsyHDwYpu/8NmKUIxxzIxfsg7pyuWgA NzX3Rl2NdrlMa6xGIAcsQ7wwC5bG+Af+mfpyTEpHqhxXWAZdVmDloGTc6uPll+m6WDZprOiZdWpA ly04579LwToPmqmSTOtZa4UL902MNBfS4bAxXicay3HrNcSL8PBLrJocBCrmgWXQZTs6QrQtiItj OCbX9Ky4/esNrPntNqidawZdJ1Yr6MKV0JiHhCQeN5QqdUEgYuqRLrtJCMOX4VIcM+qK2+3psBto Izb7mmF8neSBZYW2kDDGi5CW+KjSCCxiliNu1JUcQW57ELPC4ZRR1wfcAFXt7gPEfDTG6zxvPQhY Yd4ivIbxRUghV0PZaFwFlgNYurpxJ5trgi8IBqjggK7Z6gk+A1sYWjW/Qdd5Po+28bwVMeqKSJJL UDc1CRRx3CaNurIoYM8eKTRgGeL1ZvxPgAWD59Xwq6QhXudTU3xx6hZY00ZdHgvFayzqzHE7oIsR RmA+yh4dHQWPNozxevMwWTkJwjvwAa8xXrkickBqPI5XQkQay1WbIgZ0RVEu6AMY4LKtAV2whP58 gs8k6/MadF0HaP7sLOCpsXu644cy4UnUu6x2GbMM8YJFtxWmagWXHtQFmwO//YlXJL6CQRctUpQA 2ypifc84viRgqQ0pQR3fRgZ0XeYEAZRhmO+xLlhI/PvPK4WlrxtXU9xuxFncJ6BG6esh6FqKql0A Ibicg7qqvhFQhmE+3xBd0HGM+658I8Z4fclHRyFYRMQ5UDekRK9uMO0QUTXmod3qgw2Ka+iuMMuY h1q7M/n5C8zmUd38lSVQ4Baaz31gGXRJUt2k9tkE7apHqsZ4QWnzXXH8WHjEN2LURcI1ENWWf/ui n2FpeeFMbeCd9/KFq3cOF6RTSux26/wd4qUBXVDarCNXNBWAnjlu1JX5vQtb//2Dbgpw7cmXx5uR /U3nvVcO9FBUrGSB3OjOXxficf2DUReUG7ArN0WP+JLGPLT7fu8tKsZlf78scyXZfAINdlKWD/tH WfmDJElCd15ejYaol8Z4nU8pMN81OthZMOo6yX35rQs73dIld1s4VFu1PVPfg223/FKSPLy2XUR4 Gx7BbdR1NJWH1Vre6stz/KJR1zlsbHUX7A/vZLe+UxBo942JpXSHEElaJEu50e2j5NquZ2ygHkKt wbh8LlcLGHXBvpb1y7W2hFne+kFrtyh/kaSEqKUG3A+weOD806gre+vANEVdxqjrCJ+CdUdbVozL e3oZg+2QSTZDZnj6fS+sKj0DeegDlkqbmrIZdV1h1lTeMaOm44q813iq4XK5ZRImlMQx1V0yw5qI LVdl3V/cyDkCpgaMA6sadWUxH84jr6bjOmwO3OgaLR2XWZVLBKBG20x3QwVYd+gE9vNclGZ3wCIw 7V5lmXrvwJn6tFNw3P9bXTGNf5NLhwyvyz3gueBCjizbNiHfJb69qKUGvn9jgX9pXIjkIioMxN1W B96CbSbHPZwHcX/ziwI7nd+Cj1zcwQXGKFiDo91+aPnkDw5MAg/2dx2AVeIC3gXz+aoX73hd7JnN LyMYhu2W+ALrMVhfwU/Sv9okc8op4EUjcX+tXDGAsj85PzGwarK9hEgpKFSne5sOeM+hgqSEc5Ty bDo3nWKI2N+PgGk0VR+WSIzyYi0yBaVcMfjEx5nusF5/+2Z8/k+8uqt+yTn2EwpISkjHvAdpRQPX XvjnFcqJhKXOS05nQgxFNjc391VeD6hodERonl86u72Hcq6ZpkzV98sLqBHw6JolxCOpfNDfalP2 iK75hJRIiHwCs/adTh3NwLuPeA6og5CFuCfgXLZffOoWYvV5/ZOpB5Is0q6rLiX4MeO+TaeERgEm iaIlgTALwzb3QV1EldcziNJZGfHHocS+e2bI0n39fUD1XkJaoviQJVHWbduo9xHJd7ziXl6UxJDT YgGaysPOHLDIfUTi0K+/9Mq9UdvpTACiFapT/Ch8YQLqaTfju/cskRAxgHkQQpgFNB2vz1TYTvfM sI2xHvJ0hhOp4xDWZimL+k16bV90kYKzwG5sh5yQJ6op8gy26X7x/ilFfX3rv9Ysairyh31VvXux ZLZuUd1IgZd7tEHc5kx3U9bouYH/nb7AXwYTMjdkvxcWLFQInwqMc2oUTgrjuvIUjyoPQL94ajNH J+s9DhkuhbzxSml3z1wO4PSAyaZcpnaxPzFOJ1Bzq8V5ZhhTj+Wtv38BkVJ95DZe5ehddyg1sBct 9bozRIkKDH9cBapM5RmO9KrFED+uvzdpRQNc1Bi4etO/nrJHlWHC3j2GdBT5UcXhfVM5mpnUqvvY Tmde9D5kKfPdfShdnddeyn4IGWQplrOEh7yRpgdLw6T98h5qVM8sIcqQg0ov2k9K2c17oIZ5AGLx 8CDtaZo0UJ7WP828MJxcwsMHHl2M1V/XK9EgilfzUdql6p4BRxqlGRLyxeCJUf2ppKfGcL3Syxxb xCUtL0IitfQ9RwYMCTljiK6EmCGX6g0s2GYWl0RNTSIxSqEy1OunzPKPviZ+Uquumr5ir8cYUje6 h7wsT/VmIFysYQZ4ImyWJWpUX+tPuzkIA4v+ievLHbnAtJec/Wzy7FJiGZfRQUskllyhRMKky8h1 1Y8JDzVUlSEPVW0lGipi3x0WzxJMxp7B0CcSuxTMeWCm931P/gIDGTK59sSdDsZ4KbA7F7QEfR3g SQRzhG4sK50E1c3ShKmfJKcz0i7vfuoOjsesDlypPjaku0UKHVP8bkiCMqWcAx5+eBh2c0Gn7V// PBrCw3O+e/SCGUiJhMVTPubR7ijgIHqjA2UlIQW0y6jQL7578kbQIbqwH8dAmjEjLIATeUrc9Xjq VNmJJWrlXCnMUu2Tdjn6YXniCdpwFsxnNL87MLYSkDKhJbHtaqOl0VEPHhpQ/KFP84TKdVGkXL++ 0WbSyYmhd0w+xeqQfhZPZMZsT1hCx3y5vCtCY8KDiaIIvxEv1ndFnrsiZ8dV2vJQRz7J6sheuKS7 5MFqujmQ8BzjKonVeEBNaHRpqRwKgcLQrsguluQOSU68W1bGALT5+pKhvH6ahRviQ04QoffC6uAX ZGM/ito8ikM1KoqMv1cptmYnlbK8PDtI+y4LaH/DJujuKMTGA6OsDqNMN/AgJyTPaJ2Pmvb0o5f8 tqWIe/tmljTMKz9ggTiyYooeiHwbogfdja4nkELlY/EgaroYcgsKiMNN5OSs/n7yH7MAZ14t0qzI i8e75fJoCOJUXto9hoxg3TcXT91UtrU1r9wXN2u4NvoohsMOwM0ph3DHKM00otEDlmZMd4cX3pL8 vXvlSHJrHkZBfwD8lK6fOpuhH9qCvHw7PqF68plZnc5ff82OL4/P/gVZ8uwsLAgyZR6y5P/CAnVb s7N//Re8cRV0pEeJrQAAAABJRU5ErkJgglBLAwQUAAYACAAAACEAm5yozREEAADKCgAAEQAAAHdv cmQvc2V0dGluZ3MueG1stFbbbts4EH1fYP/B0PMqlhzZSYw6RepE2xRxW1TpB1DiyCbCi0BSdpzF /vsOKTG2k2yQtuiTyDlzI3lmRu/e3ws+WIM2TMlZlB4l0QBkpSiTy1n0/TaPT6OBsURSwpWEWbQF E70///OPd5upAWtRzQzQhTRTUc2ilbXNdDg01QoEMUeqAYlgrbQgFrd6ORRE37VNXCnREMtKxpnd DkdJMol6N2oWtVpOexexYJVWRtXWmUxVXbMK+k+w0G+J25lcqqoVIK2PONTAMQclzYo1JngTP+sN wVVwsn7tEGvBg94mTd5w3I3S9NHiLek5g0arCozBBxI8JMjkLnD2zNFj7COM3R/Ru0LzNPGr/czH P+Zg9MSB4W85SQfdsFIT3fGkP4aoptdLqTQpObISjzPAjKJzpOWDUmKwma4JBijB2JzZCPcN6Arf CjmenUZDp4g3pOrCEgsImwY496SvOBDpLJaaCKRrkHgbCjVpub0lZWFVE8KcjJIOrlZEk8qCLhpS obe5klYrHvSo+qzsHKmv8WU6C0PW8FXDmsHmK6tsq8GLa6WsVBah/R36YXQWxWln+0Tscxg+tQVJ n22e+DmUBjcHhl29ulVrIL+6IVvV2u7IHim6XoAuJBH4IAf1vVAU3IW2mr2dM87AXxo+6yuBFPYu zSjcOiIUdsshxzsv2ANcSPqpNZahR1/lv5DBawmAdJG/IHVvtw3kQNwbmt8UzBMo56xZMK2VvpYU Kf3bgrG6Bo0BGJbIAlnPtNr4e/4IhOLI+MW4w31a4QCiJiy+IYODapKM08k8O+sydegOSa6O0/zq JWR0Nc7S+UvI/3ubJMfzNGTW5yOmrq27GuhWjlwD0VnMiSg1I4OFa/xDp1Hquw9MBrwE7GSwjxRt GcA47gAjCOc5No0A+PITU8pMcwm1X/MF0cud315DvyjFBvXp0ZdreKD/1qptOnSjSdORJqikWdZb MmlvmAhy05ZFsJLYe/egVtIva+3vaXc9m6nFx/fFd0M8ibwuyPh74Z4diLEXhpFZ9LCK55+dqGQU uUN0XFz0NOS6cBSCBWmajonlMp1FnC1XNnUmFncU/yD8plyOemzksVGH+Q2p3NlRu1/sZKMg29M7 DrLjnSwLsmwnGwfZeCebBNnEyVbYAzTOkTssirB08lpxrjZAP+7wZ6J+IKxIA5fdmEECqk7Qzx0z WE/hHocYUDfVTMOoIPf4islo4sx7be7b84Guw5xyc+iBEktCOR4Y+yJ4kosbfxVDwhZbUe6m2lGX OGcGW0iDA9AqHbC/PJaO/WS0t8jzO3zYb1B/IAZoj1FVXVM3vzubf/Kr+eVoMr+IT/JsFGfHeRaf nV2exPnZODtNTk7m80n6b1+n4Sf0/D8AAAD//wMAUEsDBBQABgAIAAAAIQD2RNh25w4AAIeNAAAP AAAAd29yZC9zdHlsZXMueG1s7J1bd5tIEsff95z9Dhw97T44lixfc8aZ4+vEu7HHEzmTxzkIWhYx 0FpAcTyffvuGaFQ0UE3Hk4d5SSxB/Wi66l/d1YD46edvSex9JVke0fR0NHkzHnkkDWgYpY+no08P 1zvHIy8v/DT0Y5qS09ELyUc/v/vnP356fpsXLzHJPQZI87dJcDpaFsXq7e5uHixJ4udv6IqkbOOC ZolfsI/Z427iZ0/r1U5Ak5VfRPMojoqX3b3x+HCkMFkfCl0sooBc0mCdkLQQ9rsZiRmRpvkyWuUl 7bkP7Zlm4SqjAclzdtJJLHmJH6UbzGQfgJIoyGhOF8UbdjKqRQLFzCdj8VcSV4ADHGBvA0iCtzeP Kc38ecx6n7XEY7DRO9b9IQ0uycJfx0XOP2b3mfqoPon/rmla5N7zWz8PouiBHZlBkojx3p+leTRi W4ifF2d55Osbr9R3fPuS79hoGeSF9vV5FEajXX7Q/E+28asfn4729spvLngjat/FfvpYfkfSnU8z vTGnoz+XOxd3/Ks5456O/GxndsYNd9W5yf+1M15tfxIHXvlBJI7jLwrCgmtyOObQOOKxvHdwUn74 uObd668Lqg4iAPL/DXYXdDqLORaBMykEtpUsPtDgiYSzgm04HYljsS8/3dxnEc1YsJ+OTsQx2Zcz kkTvozAkqbZjuoxC8nlJ0k85Cavvf7sWAau+COg6ZX9PjyYiEOI8vPoWkBUPf7Y19blP7rhBzPde R9XBhfn/SthEeaLJfkl8ngO8yTZCNB+F2OMWuXa2zcz11rmLvVAHmr7WgfZf60AHr3Wgw9c60NFr Hej4tQ4kMN/zQFEakm9SiPAwgNrFMagRzTGIDc0xaAnNMUgFzTEoAc0xBDqaY4hjNMcQpghOQQNT FGrBPjVEezu3e4yw43YPCXbc7hHAjtud8O243fndjtudzu243dnbjtudrPFcOdXybpjM0mKwyhaU FiktiFeQb8NpfspYojByw+ODHsmcnKQDjMxsaiAeTAt88bk7QoRI7cfzgtdyHl14i+hxnbF6emjD SfqVxKyy9fwwZDyHwIwU68zQIzYxnZEFyUgaEJeB7Q7KK0EvXSdzB7G58h+dsUgaOu6+kugkKWwC mtXPSy6SyEFQJ36Q0eFNo76z/PAhyof3FYd45+s4Jo5Yd25CTLCG1wYCM7w0EJjhlYHADC8MNJ+5 6iJFc9RTiuaowxTNUb/J+HTVb4rmqN8UzVG/KdrwfnuIilikeH3WMem/dncRU76UPbgds+gx9dkE YPhwo9ZMvXs/8x8zf7X0+MJ0M1Y/Z+xxzmn44j24GNM2JFfzehEiF+yso3Q9vENrNFfi2vAcyWvD cySwDW+4xG7ZNJlP0N67qWdm63nRKFpB6iXamR+v5YR2uNr8YniEVQK4jrLcmQyasQ4i+I5PZ7k7 XWS+qpXDG1axhstqOys5bZ5COmhlTIMnN2n4/cuKZKwsexpMuqZxTJ9J6I44KzIqY02X/J5wSS/J XyWrpZ9HolaqIfoP9eVFcO/WXw0+ofvYj1I3frvaSfwo9tzNIN4/3H7wHuiKl5m8Y9wAz2lR0MQZ U60E/uszmf/bTQPPWBGcvjg62zNHy0MCdhE5GGQkiYaOSGyaGaWRkzFU8P5LXubUz0I3tPuMyPtO CuKIOPOTlZx0ONAWy4vPLP84mA0J3u9+FvF1IVeienAC05YN8/X8CwmGp7o76jlZGfp1XYj1RzHV FdbucMOnCTXc8CmC8CYbHnj8OjjZGm74ydZwrk72IvbzPDJeQrXmuTrdkuf6fIcXf4pHY5ot1rG7 DiyBznqwBDrrQhqvkzR3ecaC5/CEBc/1+ToMGcFzsCQneL9kUejMGQLmyhMC5soNAubKBwLm1AHD 79DRYMNv09Fgw+/VkTBHUwAN5irOnA7/jq7yaDBXcSZgruJMwFzFmYC5irPppUcWCzYJdjfEaEhX Mach3Q00aUGSFc387MUR8iomj76DBVJJu8/ogj+QQFN5E7cDJF+jjh1OtiXOlZM/k7mzpnGWy3Y5 WBH145hSR2tr1YAjLOv3rnWZiSc5BjfhPvYDsqRxSDLDOZltWb08k49lbDdfNKPXsueH6HFZeLPl ZrVfxxyOOy3Lgr1m1n3Apj4/LJ9naTK7JWG0TsqGwocpDqf9jUVE14z3u42rmUTN8qCnJTzmYbdl NUuuWR71tITHPO5pKXRas2zTw6WfPTUGwlFb/GxqPEPwHbVF0ca48bBtgbSxbArBo7YoqknFOwsC frUAeqefZsz2/cRjtseoyEzByMlM6a0rM6JNYB/J14iP7JikKY63uXsC5H0xie6VOX9bU7luX7vg 1P+hrhs2cUpz4jVypv0vXNWyjLkfe6cbM6J33jEjeicgM6JXJjKao1KSmdI7N5kRvZOUGYHOVnBE wGUraI/LVtDeJltBik22GjALMCN6TwfMCLRQIQIt1AEzBTMCJVRgbiVUSEELFSLQQoUItFDhBAwn VGiPEyq0txEqpNgIFVLQQoUItFAhAi1UiEALFSLQQrWc2xvNrYQKKWihQgRaqBCBFqqYLw4QKrTH CRXa2wgVUmyECilooUIEWqgQgRYqRKCFChFooUIESqjA3EqokIIWKkSghQoRaKHKRw3thQrtcUKF 9jZChRQboUIKWqgQgRYqRKCFChFooUIEWqgQgRIqMLcSKqSghQoRaKFCBFqo4mLhAKFCe5xQob2N UCHFRqiQghYqRKCFChFooUIEWqgQgRYqRKCECsythAopaKFCBFqoENEWn+oSpek2+wl+1dN4x37/ S1eqUR/1R7l11LQ/qmyVmdX/WYRzSp+8xgcPp6Le6AeJ5nFExRK14bK6zhW3RKAufP560f6Ej04f +KNL6lkIcc0UwPf7WoI1lf22kNctQZG33xbpuiWYde63ZV/dEgyD+21JV+iyvCmFDUfAuC3NaMYT g3lbttbMYRe35WjNEPZwW2bWDGEHt+VjzfDA48l52/qgZz8dbu4vBYS2cNQIR2ZCW1hCX5XpGAqj r9PMhL7eMxP6utFMQPnTiME71oxCe9iMsnM1lBnW1fZCNROwroYEK1cDjL2rIcra1RBl52qYGLGu hgSsq+2Ts5lg5WqAsXc1RFm7GqLsXA2HMqyrIQHrakjAunrggGzE2LsaoqxdDVF2roaTO6yrIQHr akjAuhoSrFwNMPauhihrV0OUnatBlYx2NSRgXQ0JWFdDgpWrAcbe1RBl7WqIanO1WEWpuRrlYc0c NwnTDHEDsmaIS86aoUW1pFlbVksawbJagr4qfY6rlnSnmQl9vWcm9HWjmYDypxGDd6wZhfawGWXn aly11ORqe6GaCVhX46olo6tx1VKrq3HVUqurcdWS2dW4aqnJ1bhqqcnV9snZTLByNa5aanU1rlpq dTWuWjK7GlctNbkaVy01uRpXLTW5euCAbMTYuxpXLbW6GlctmV2Nq5aaXI2rlppcjauWmlyNq5aM rsZVS62uxlVLra7GVUtmV+OqpSZX46qlJlfjqqUmV+OqJaOrcdVSq6tx1VKrqw3V0u5z7QVMnC3e ScZ2Ll5WhP8Gt/bATCh/g1RdBBQ73oSbFyVxY94ST72SSn0tGqwuGIq/s5xVdWqf8fhgcnhRdrR6 5VThz0VL2P/lfjFZiIJtRfPT0dGJuhxn2mEyOVEdZdzj4FiFh3GPk2Nx6W63ag/9SrJFTJ/v12lQ bM5AYvh7r/gzmeTyyrjlbntL+GWdFx+5km7Sqkvkxuq9W3P+m1fMFRP5o3bqNVz6S7j2Nx/qL+Fi TSffirM4ekzFL9ypI8z9nPCd1empXm9839np6CFKSO7dkWfvI0188cSVeJ9Z45Ygh1/Ls6leaKZ8 V3uhWamQ+gvNfjnnzOqFZvIdZ7LR5RvMRBDCsA2WLG4D9UtchrBVv6i7eSRM/J7udhAbfnZXNLeS U7m3irrqsrrcr3YJXbbf0O6Cy7elzULerXqTGcDUwBOltK4WsvbMY6XGeSyj81kFnWxp+M1XITaP L0gc3/pyb7oy78oFJrdOxuIHGLa2z+VvCRrtMzHoGAFcqlpj5Mf2OJFvF1B3QxjTG8+sDd0tbs0Z 2tPmttVSb8AyBU1Elt5un7qfYw5aqDb8MVe9y2Qf/srHC5CeU/7jpUPT9hMhqzsGMqUveTsfSDjz XoLu2xki+sUrGbZ7Q2z5Q2zq6g7+26Y1M251wVKKCkOLASyIiS+SkXEEq+/ROIRt7dI5hu0ddwyU B+XdeKYdjssZh3monXYNxvuTrqH2aNxxlL298p4/4x4H5dzV3BlTdS+OaY8p6/SOPfbHHUeZHh6r ua9xjxN586E2sYBikSO6GurlbUBAONsvCXUnog+zS5Y6xBRhW0Xapi4VmWWiKZ/9e5E7bjxLWmcB nxo3tL7a9sM2f0bXWdDU82rDD9twee8jbLf8vqvZetJVNn1S7vePpZt0QZsjSWxpOi8QZ6b2O2ri BU34BL+5leXG79TQ2lS7mpRsfiN8u03VFnFA88yp0+cBr3GrPcbj62vFLL/k7/CQoYcsGbrjXMSm Ida9KnAborrn2X2fQkzXSW0Ief2yrM8srrGXq5mcoaOrSaDcJF4o/Vf2+vft1f6pQr1MDYat2tCU IvoNLWpq8iUoN4taTbUfTvibQnCqplZ6Z5Xfqc6quueLv/Of+37ds6mpuwKO324g3wcOok08QqEm qVv9o5fk/TqpoTz4e33rB1rfqqLsdubdRmmwFG/RG7bsVZ52RyYIyc7lVb0R8ist1J9rizPnNAtJ JgNKLL4Ijhr5eIz/ySoI8Qd3kupYMXTqHamWZqxsN8s2Vtbloo6VccRcEpL3w8x/tzOX60ub7pcf EZm6mivJNyhtJx71otiunKwPfJJUDYrmyVXDit+PvKyxtYvKXfVdWAaQEwuxz/7BRD3uo+0jB6Vy l5PxnqjVWyvxWu09fGajeWjb33KTNqXZcnrjerUhBLrc/5fNg8qDvs58s1lv1/LVydv9r96ojNGb JP2ttx9Xb5qHtv0tNw3Vmwqmv/WGqUQuaWAoRaotGB1urBCL9H1LFXdVbb2VxjMfGpFbXfiXLjR8 7wAs/8rf/R8AAP//AwBQSwMEFAAGAAgAAAAhAFtt/ZMJAQAA8QEAABQAAAB3b3JkL3dlYlNldHRp bmdzLnhtbJTRwUoDMRAG4LvgOyy5t9kWFVm6LYhUvIigPkCazrbBTCbMpK716R1rrUgv9ZZJMh8z /JPZO8bqDVgCpdaMhrWpIHlahrRqzcvzfHBtKikuLV2kBK3ZgpjZ9Pxs0jc9LJ6gFP0plSpJGvSt WZeSG2vFrwGdDClD0seOGF3RklcWHb9u8sATZlfCIsRQtnZc11dmz/ApCnVd8HBLfoOQyq7fMkQV Kck6ZPnR+lO0nniZmTyI6D4Yvz10IR2Y0cURhMEzCXVlqMvsJ9pR2j6qdyeMv8Dl/4DxAUDf3K8S sVtEjUAnqRQzU82AcgkYPmBOfMPUC7D9unYxUv/4cKeF/RPU9BMAAP//AwBQSwMEFAAGAAgAAAAh AAeQCTENAgAAJAQAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAnFPLbtswELwX6D8IOrUHm/IrsI01g8JBkQBNYsBycmaplU2UIgmSNuJ+fVdS rMptT9VB2NkXhztLuH2rdHJCH5Q1q3Q0zNIEjbSFMvtVusu/DuZpEqIwhdDW4Co9Y0hv+ccPsPHW oY8KQ0ItTFilhxjdkrEgD1iJMKSwoUhpfSUiQb9ntiyVxDsrjxWayMZZdsPwLaIpsBi4rmHadlye 4v82Lays+YWX/OyoH4ccK6dFRP5UV+phYWMFrPNCbqPQuaqQj8ndAdiIPQY+AdYa8Gp9EfhiMQPW mrA+CC9kpAny2XQ8B9ZzwBfntJIi0nD5o5LeBlvG5LlhnNQNgPVTgG6xRXn0Kp55BqwP4ZsyxGA0 WQBrTSLnxd4Ldwh83lDsIGyl0LimEfBS6IDAfjvgHkUt70aomuIpLk8oo/VJUD9J4HGafBcB68Gt 0pPwSpiYtmktaGztQvQ8V1FT7w43Zj+tb6spHzUJZFwnNqDhQPY1u+aE8FzS3eI/yI76ZBsOLdUe nT6zyxl/dH0UhtT1/CHfDXJgFwhrWzlhzvzBkJqmkUjoJEeN0lbV0bzLluxM/f9E5Z9J/veiWq8f Yedye1dv2LsM187e8ryqeNg6IUnXm8k0669RLwRb8mJBe9Hp2jngnqbgdX0A1Zo9FpecvwP1Yr60 j56PZsOMvmYTLz5apu418l8AAAD//wMAUEsDBBQABgAIAAAAIQAejbpghAIAAFMIAAASAAAAd29y ZC9mb250VGFibGUueG1svJTRbtowFIbvJ+0dIt+3cQKlATVUlBVp0tqLwR7AGIdYi+3INqU8w6Td 7GYX3SNsN7vt3mbrbV9hJ04CbICg0rpECuE/9p/jT+ecs/NbkXk3TBuuZIyCY4w8JqmacDmN0bvR 4ChCnrFETkimJIvRghl03n354mzeSZS0xoP90nQEjVFqbd7xfUNTJog5VjmTEEyUFsTCXz31BdHv Z/kRVSInlo95xu3CDzFuocpGH+KikoRT9krRmWDSuv2+Zhk4KmlSnpvabX6I21zpSa4VZcbAmUVW +gnC5dImaG4YCU61Miqxx3CYKiNnBdsD7N5EtjI4eZpBuDQQtPN6KpUm4wzgQyYemKFuRd+bdyQR EOiTjI81d4GcSGVYALEbksUIh3iAT+BZ3E3cKJ7ILxbSlGjDCpNyIS7lhAieLWrVzLkxZSDnlqa1 fkM0L5IqQ4ZPITAzYxyjSwxXOBigUgli1ASh118qYfEtdwWV0lgquFCo8ylXtN0u6nyWa+Cbfklg g8SQi+FMOhAks9eg1Rn/+vbh549P1VE2GAW4Bc4N+K3urYyi1jZGZGbVkxBV52isEIVRNKiPv44o aO1BVLB1GA9H1IO0sh2lcgEYmlWxuIJ59lIJe+ul0gflNGrWZFal0t5fKqXP4RxGXDDjXbO591YJ UtbMJpEQiDSggZquiRpPIqKd7z8hUrfKsxK5GnpXXNJUbeufx/uvj/ffvYfPHx/uvuxqo4JW21XQ CY520or20ZLKjvSMjRY526SX8Fs22dlUNajiyBE+rbH80VS1sgtduKYciK6awN4bPk3tzjlcTN// NYd7Rcrh5V9zOMSnFxultI/HIXO4ejHd3wAAAP//AwBQSwMEFAAGAAgAAAAhACeZ8yhJAgAAEAQA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIxT0W7TMBR9R+IfrvIE0tI4CR1r1GaCdZ0mbTCtGSAQmjzntjNL7GA77fLGP/CHfAm212Yd2gNP ub73+Oicm+Px4X1dwQqV5lJMgnhAAkDBZMnFchJcFbPwIABtqChpJQVOgg51cJi/fDFmTcakwgsl G1SGowbLJHTGmklwa0yTRZFmt1hTPbAIYYcLqWpq7FEto4ayO7rEKCFkP6rR0JIaGjnCsOkZgw1l yXrKplWVJyhZhBXWKIyO4kEcPWINqlo/e8FPdpA1N12Dz0K3wx59r3kPXK/Xg3XqoVZ/HH05P5t7 qyEXblcMg3xcssxwU2F+NgcpoLAfu0WYusIJ4UJWctnBn1+/YSarSq7DtgEma+/JYxetMreo4GeL 2tj/o8GuEFhFFV9wRl0LXl3iIoPT42IGH+QA4vTt6DV8M9K39iA9ubj4Po56MU6Wbm9+IDO5b/cH WzOF1EiVnxZXYQFz05YdnChpZcX7HrwFuJ9/h91aqlLnaeSmux3HVaJmijdOY3708dwyeKfWfPwm 8eUxWN8qgxMUuKJ7MIIQEgIzvFEtVZ2t4+H1PSGkvJ5K1rq1gE0JZrDpzukKS7jpwOodxjZIB2kM 1EBMsjjNholbO0kiYgUOvfxdTc5CRbU5t1FfcCzfd/k7sbSR0uEZ2otThE/cvgu5B5dSU2/wH7yj ULji7unkiUf0x/Emhw8rszJtfrKHtG0nn9OjaTELcuczJGlIkoKMnHJCvjq5T+4/EtYbAf/POHzK uCXIveKnbzj/CwAA//8DAFBLAwQUAAYACAAAACEAIUpMSXsBAAAOBAAAEwAIAWRvY1Byb3BzL2N1 c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0k9FKwzAUhu8F3+GQ a2vSzm7raDdct4mgKGx6H9usDbZJSdJpEcF38A19EqNO1154o+zuJOfwf18OJJw8lgVsmNJcigi5 xwQBE4lMucgidLNaOEME2lCR0kIKFqGGaTQZHx6E10pWTBnONNgIoSOUG1ONMNZJzkqqj21b2M5a qpIae1QZlus1T9hMJnXJhMEeIX2c1NrI0ql+4tBX3mhj/hqZyuTDTt+umsrmjcNteAPr0vA0Qk8z P57NfOI73jyIHZe4UyfoBQOHDAnxpl68CE7nzwiqj2EPgaClfbqFiLq0cRszKqoHbdQ4vroEtw9v L69wsQT3xPss5yHejYT4m/5Pj17LI6WGdUT2QjxpEaUqqMg6zLnICq5zkKJo4ErxjAtajGB7vRcj v2V0V9Ss4uK+49TDbn8v5H57+0ybDvWMCbahRxCAAx6BBbtTNVWNrV1/LzaDlg2tTS5Vx+d8deOs YGnqtIEzJesKft8K3n3k8TsAAAD//wMAUEsBAi0AFAAGAAgAAAAhAA5O8gGdAQAACwgAABMAAAAA AAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAdISmQA4BAABx AwAACwAAAAAAAAAAAAAAAADWAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAOD2xOJQBAAA5 BwAAHAAAAAAAAAAAAAAAAAAVBwAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQItABQA BgAIAAAAIQAnNYmgkxoAAGC1AAARAAAAAAAAAAAAAAAAAOsJAAB3b3JkL2RvY3VtZW50LnhtbFBL AQItABQABgAIAAAAIQANQjsczQEAAFUGAAASAAAAAAAAAAAAAAAAAK0kAAB3b3JkL2Zvb3Rub3Rl cy54bWxQSwECLQAUAAYACAAAACEADJymzMwBAABPBgAAEQAAAAAAAAAAAAAAAACqJgAAd29yZC9l bmRub3Rlcy54bWxQSwECLQAUAAYACAAAACEANOaM2oACAAA0CwAAEAAAAAAAAAAAAAAAAAClKAAA d29yZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAAIQCJsDhEhwMAADkMAAAQAAAAAAAAAAAAAAAA AFMrAAB3b3JkL2Zvb3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAOEcZtb7agAAyJcBABYAAAAAAAAA AAAAAAAACC8AAGRvY1Byb3BzL3RodW1ibmFpbC5lbWZQSwECLQAUAAYACAAAACEAqlIl3yMGAACL GgAAFQAAAAAAAAAAAAAAAAA3mgAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0ACgAAAAAAAAAh ANuvootDFwAAQxcAABUAAAAAAAAAAAAAAAAAjaAAAHdvcmQvbWVkaWEvaW1hZ2UxLnBuZ1BLAQIt ABQABgAIAAAAIQCbnKjNEQQAAMoKAAARAAAAAAAAAAAAAAAAAAO4AAB3b3JkL3NldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQD2RNh25w4AAIeNAAAPAAAAAAAAAAAAAAAAAEO8AAB3b3JkL3N0eWxl cy54bWxQSwECLQAUAAYACAAAACEAW239kwkBAADxAQAAFAAAAAAAAAAAAAAAAABXywAAd29yZC93 ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAB5AJMQ0CAAAkBAAAEAAAAAAAAAAAAAAAAACS zAAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQAejbpghAIAAFMIAAASAAAAAAAAAAAA AAAAANXPAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAJ5nzKEkCAAAQBAAAEQAA AAAAAAAAAAAAAACJ0gAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAIUpMSXsBAAAO BAAAEwAAAAAAAAAAAAAAAAAJ1gAAZG9jUHJvcHMvY3VzdG9tLnhtbFBLBQYAAAAAEgASAIQEAAC9 2AAAAAA= --_007_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_ Content-Type: application/pdf; name="ls142-16.pdf" Content-Description: ls142-16.pdf Content-Disposition: attachment; filename="ls142-16.pdf"; size=166866; creation-date="Tue, 03 Mar 2015 14:39:10 GMT"; modification-date="Tue, 03 Mar 2015 14:38:37 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDM1IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDMvS2lkc1sgMyAwIFIgMjkg MCBSIDMyIDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOCAwIFIvRjMgMTAgMCBSL0Y0IDE1IDAg Ui9GNSAyMyAwIFIvRjYgMjUgMCBSPj4vRXh0R1N0YXRlPDwvR1M3IDcgMCBSPj4vWE9iamVjdDw8 L0ltYWdlMjcgMjcgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUld ID4+L0Fubm90c1sgMjAgMCBSIDIxIDAgUiAyMiAwIFJdIC9NZWRpYUJveFsgMCAwIDU5NS4zMiA4 NDEuOTJdIC9Db250ZW50cyA0IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kv Q1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTI4NT4+DQpzdHJlYW0NCnicxVxtc9s4kv6e qvwHVO2Hk/ZimuA756amzhM7WW8lTiZWauoumQ+0JdvcyKKGouL1/PrrpwHKpAhItKTUVSq2LALd jX5Ho4njk7LKb7LrSvz88/FJVWXXd5Ox+HL8a1FVxf0fx6PH+eT4Y3abz7IqL2bHl8urCl+9KYpq Uv7yi/j19LX48+WLIHUSEUT4kYZOIkUgnUCUk5cvfv+7mL188evo5YvjN1KkYnTz8oUULv2TIvSc IBCJ67iBGN3TiLeXsbhdvHzhilv8ePvyxZcBUTUZhoPZMB0QCcOjhD/+NPxDjP758sUZAf7t5Yve JHhrJKTSSbwmDU3U4lBIAke6NiSXwyN/QOuKBve0zMkwILRHnvqmFHiY0XfTKT49PbkZSv1ndQee rObdD2XCM6rhkQz4+zLPpitAVVV/uqb/d4CFMWN8UPCYx+rjUEo1JF+I6TAZ5Fm+KDB/thq+qBjq ZCjD1QL4aUWPg5ocgvg4jNWMqxqnmr8EPP7uX5PrYT2PqAjVgPMRqPgsrhnxHAMBqsxva/orBzPU 4NkwasJdrZG/y2qk+Bp/LCb1cMVFWubDUHqDnLk9ZUoa5D5XG/bRGWUbUepEHY3JZ6CVJZZfZ2DZ ZKw4IF39cE18K27n+IrFo6Z/Jy7nY/qxxJ+saLzoMXGY9QycWirllElDuJrlh7EPmSROal7r/wfT w9TxErOdLmueWJSqIL5pFfXclo5qttLHopbIQkBbC/04URNLPPlOYNYMac3MmRCtviT1vj5hQr5A C5m+4gkNR5Ozb1gI6FCqbfpJWRpugjAysUxFCSjz1cqYqFdAy+Ou1LhYL0Oh0BAOoz1+HDpubJGa gZ0LUYGStmHwIvCXEkKhVh0/CbzKlZ+OG75vjetNP13LRDF2XltXyYJem1fzBB9ntdvLjB5nf+UO yNS6ZvYkzSta4TSvfWdmWfkDVEPRfbeS/JOUDZ4nqx0J6WaoeZP/xd4Lg+vIfmRWaB0EnAOpjCcD J40tvDBynQcQMt8T5Kw84TpBwj9cV6G7+Xuv54l6zMR6nQFhEDrRE4Q4TbtA+oxRhBBbIvUMXAm9 7uON69j4PFGPN69jRQAT2abhacjWpW4cY9F1whwIP9mW1SnhirP3nMWqWVFCyuGL2HXSUCSRI9OG Ponjj0iV378+PxXu8btsdisGk9nR21+HT8lwA0zAYJDkEpzEpJjSa4dCz3NCxP3UkUy5RR8bVEsv dsJUxKTNSSq8kBYdCgLj+Ra6pYVuBpQwoBYcz2hQbDpNyn0STSRiWn1N+Tn8w8WIYk04OIMZfyIn cHEC+1Zf8oAPFyfv6jSsMfYdZfn84TVN+kDfe4P37+FcPl/QtJC+PooHJ3ALLViiMeTDRYd1+63R j2iNfmuN26TjJyG0QUtHRrHjpRul41mkw4B8TTng+DbCSRYBK36D8kCSTYdEuefIQJPOjH0PBy0j sKu7lP44fRPOOGBeN3D+7Lq/yl92R2NcWiKdKGovbZ+lmHGEAN7C8e5SSIp4AfTOUxH8sPwLyaK8 6IfzL/RpQvBj+RcGrhO3UZwdGkVI2+utatAwzqbR+ZtcYlr7cs+VDoWgyKfIYCTKszlF+hUnmqjR 2bszdl4f3r//jET74vz1CX6Pzm0Oaw8KPGIq+bgWBV22NLH4TSxRZ2d1KJbIkKSs6LkcnVycniAB /HR6Dk78L0IEf0E8wa8LcXn2eoRPHz4dnEU+kRLHLYp251BHtYIeqmUFuC3aRilFMG/FRgqE/uDz 6f8IuPOP4OQq7KrweLrjwqx0eC6pl2zT4QG7SyFd4oN/aIweK3QL49HBcSQI0w0cgp3L6JpW51K0 PDA68ni+316S0XWtkgovdULSWPrlIpvwHT8SElm5OacIbTnFExypwMTrYJ7Mxuhtfekk0XO9bbSZ nNqQ1bKCwJFmQzYkHCGcXCzdRpiZ3dJ+k3flOWouvGUVxQzbXPr7sRuF9iSi5kyTCEM4bWDxm1i2 uZO4B++sADewjjZZkuyYtpVuLc8PJTh2q1jHRd9U1Tjwx0/ibIbkmx+DkzxEsXe31W5laYu4jfah d2BkgFGKsnsqN1lHsnkfR1BiBkJU9TSOFDvdKIrgohW5vy3hC7nqh4MUsOnrYPF1SLrZPcrYGTF2 jzJpY966faT0LwxrZsmIfdAGbqW2eAY4NdVmMLY9LyWHgeJXrIn2j01OdncMkYRjaGLYum+jwAaV VWzxgniLi5W2akADUKzgWHxsh+rAjRzXb1H9FsXVGdc0YYmvRGpwLbsjDGMk4E2E3ci6B3iSAoLk RinsAz5AtagJ3nPFG5gaGHZVLjNV6T2Suj4vkCFRsA4PSEXtq/qqWkuHpFYbLlfVZSTfCVFFwjGl RAW3rnwh50AKyAP4ydpjPlThpwkgtZ9qW7JN9hPOYNRjWgvt41sDagZZ5vtuzGkhP0ZJK1p7XgcE y3RKKxrTJaJGa8Caow98FFeCNELWtslIbcWVJzgKjN/T4XrkuiStA5XORiX5y+AdV61Pzi91VYp/ j/DlyagubKH0wh8uRrYQ8GyC/Ch1fGkgaJu/0wi9ABnl1pApbRvmJzByp5jpRXU+qelWx+N8mFvq Q2tYszVoPh8zZd0Y3EXdN3IqngW0ffSTjUyzbgW1MTLtDKejxVtCJ7kC2ST9HCcnvF/+bA2jO2CL XFSKOtgM2689cASk7GsoxBE5VQyk/dfIsIXdHVusYsYaOjRqJIzt8u0hsSUpe9V1/m3IdZ6PxHMp B+xwsK8DCClFD2LtAPzUiWRo02bbprIDiIwLkMx1PKMXQPRomeJInZNOJ0Pfavq9MHbYlRCfYf0d lD2tX2PV1r+ZY7Z9rxZ2E1TaewG1C3BRL21ZjPSVxby7tKnXjhjDgN3AGkYyGpoNhMflgRFGXOFf Q2is0u2HJjCiKWaCXek77Hc5Hgkk37OxOB3hmLrxPZqupGq6us9nxZS7BG6RZuqEcx+Cg06wJ4+A NGmNYPMhwV6s8b3QhOnQEvApZ4XvWkfzBn0yqrWieDgwysjjwsc6SmtM2xVNhCaVDprlnDch3Dt0 f1/vVWbVQmSkXzdomiiruwkONUvx53LVOoSmDJoyW9h6RA7hU8LUx+QGuTdFiaNakDvNSjSPscLf 5Nf0udEsMhNfB59A6M1PAqbD+cgZNx2N3qAR8KJwKImMU66AiC/cGFIIBqbG0rCE9rc+uPP240dU T/44rEgC2sLEqWGRPSMl7Q2lOhl0N+fKtpJdF46lntHddviBE/o0NXSS+PDbjl1I8lEoiQ0k9d/9 Jpo1dTj3Uf2oU3nD5lWPsO5e9fOAEqIwbI8I0YyyAUIYeDh63fAchQH9OHVoGyg3bVAxnIKxdFOc +2/SFVt1rQFHKjh9BaNSqjBg/9PyqWRrBfZUFM20C1KlSY/iWGHNsnYgQWK3byBha4qllElzz1fV /Q3c82w1OAYU1bQzIEs63aU9Spw4MBB/frayLWal+P0teSwxUr0r9MOQde1Ohkf443gHHmqpeb4T yh4K6Nmag7pwnqmAtL32bAq4CoH4cE85Pv7rjk1/UFFaRfHfqpE70CSDELWzLlF9VVLh7KGStopT rQsNQM9VyQ7xhpxlDyyxBxf3bA5pobjkIPt4PG9zJYnh7KZwbrQW1xsKhw7ncHDDraslPt4j6cj6 +L8dCJIh+78OQX2VTfGyh7JZC0xaDRTtOylbh3gfWZmkPQ3nGCf+K4F+MnZ/gVUPdyDACyX6ep/P PSWvgGJ02svzba5nNOE8TxGDJEJm1KD8ZD6HzkETi+/Z1KZqu6CUEh1TBpw9dU3j7KFr1mKGEnUT 0DN1rUv8+Qg6Zihl7oErdVFZ66Cy+tDdkASoKnWxdDPvPbDoil8fme+FJTRjYftH7iMjoeK3fpVi AiWvcvaot4elJU6RDXVp+To4KBqaE5uWjNWu0hN1GvuKGMTLf4O3Fa/q8wo+uMjw6VF4eGw6bdyD RPT1SpMe08b6kGgogXBNDO/phKMAVPZwwpv3yk04z3TCUbS2Lz3FUXo25vYV3d6ihWn1xztgl27C PO+g7+uPFc4e/tjWxVJLvQHouf64Q3wi/rlssUwYT9H3QO3RljFId+CbFpUMHfVab4q2MDTtW9i2 ecPNcMK6CAFA/U8xgoDbmRu0vy5mVYZKWWVVsZ3wSTdA208XYc8zDM0tmSaoKm1il2/dYauSjKa/ AekZ5UbQ3xb2a4SOuzJfqLIiV93FW9Qdi+9cBrVVBHejw0P7VGygY0uRdb9V+x76WRvY/rHEa3EP 8E/5YRco45gNuoPyhy5QJpjczH+Xi6rEGqdarIddJKrBkQHt1pYvP3LcpLYG5Dthstka6mLJeHL0 +h/Nni+fyzSa/gakXkcFqF6GBi0cIbMw7Bb2wxYm2OD30fn98MQRnFMXz3+SHUf0XKQ+spIgjA+L OKAF+iZ22nT+IMLrWBiOsOC//o0k8NAyRF+GfIZZH2SJHfs6u8+Gvr474dArxGuU6Xab1ocKl/Ns 9mSl3g+xUq3PTYrwfXlbf/rEb5vyZQHtCObclgUxSkWw/55VE7wMhHF/YcNUcHuno04EjatrOCD/ RyxNv3fWx4HuicdHz8RWPE+MXTE9wvsSMvTRvOM6keu6cnX00vbrLXYFrROmIPKwm9lwwqRHWE+Y 9HN0jq31R65SXxsAfr2tfow8O15vgVSctQHwQaFcUUAZII7q7EdQgaua7vVxpYsTFUtUCy1K1QAU rw4H1wBB1GtpMJSif1baoiRqy0v6qARukpcaYZeXfp7G6Ngz8tsGoea3em7ld4v82MRImzHoN9Yj 9MVamPWnhU3GrV9LEgp4xGdI9bvZpg7B5qQYXb9rs44sY0kmYbA2dmQbG5NlrI0VlrGp2x37G14O ENVdNvu2sM2TFPQp9WzN4w6cYmmdEqdkka0ZutvBNiHltyxMOEpR1jvj+ZSbGlT7TzETaGVN+VoQ NA55deMQfzkZxoM/l6q/Q7RKWca4Zty6Nin0A264b1BojlF1d8Z6c0aXgMZrjcadYBN7IAOkzi3s T7cwvOIlg1VblhkYTyRbiPyUT7e2LXN0SlHXS4Ljt6p2t2l1xmO7FlKSfpzYVvd16IjfsXldvziq Ectq4QROEorYc8jWyIpSXHJRu5TVynhMGFNY7g5SXsFg7qGHS04avuShWE7tBhy153wZjIXan33j RVSFwJ1a3kC1KfFtNvlf6ELix5Dkkvg7G3P3m7oWbDZG9ZffEsNJ0RV9rjvh5uqOne/5WBXf1AgL db6vTsxb1HF7UT7Ln1qhMsYvNM6xvhyrCX9BKdVKKqR/N8V02uooa7FRcvmrhdXmAEMPp6WtoWjt WvfdBimRiGU9pTb+ekWvxMNdfj3EG4vM74m6Q027imlW4TPfywTxfB1Awb8OR0gjG02JxOqqQNmp mIq7DMnmbDxtcuUGbq64F+o+H2bOvIZcLuaT+jYgxcrvSt43RBJRM+Yqv8pW58Wi5u6419q9EKmE WjuTUl9cp3ooHzJ+oZkVxrFFCNXt1QLVI2YGxmNnA4nqPRcd0e6wAxfV5N9gYiUUD0W+ulLv6eKk BZknChxZpW76Us1tniVAeDpAOMLW6dikDKcflFG1SLPpJY4wgrQ9Vvccrisbm49SsXy2mJR8X9j4 JwtgpHXYrzcB9+G78Yha5UShOSfCDQaNpAIqSqGfuYoADQ1/hPot0SCJBvHmkq6KZcUn+hROSZVO bWzyYn7Nr4nq61CnSD76efzBpSOYb7/j67usEjf65sZ0sBIYLh4U+UL1CEMFiJo5ETKBAtio/C/+ JrI0ddqMx4vlk68hE78e1qdugfKNY/hbuFuy1t/+Bo3lntJstnioda9ciKtHcUIz/4ahtMDzGyIz RJp0l33X0HjV2Xis9DwvZpm65GxNgcR8OskWQ227YjqpxHIhvsEnK87YTDhIuO+6taA+qmQ8sFeq FFlUCTdXrV7JlTaC4sDx3bXRfQgyHolv1m3aavsawxdyEC5pl6e0S79PTQHzD+Kvq65Fq+4mYpwv KnVX3DX6VXCh3BU4Xj3UwZjTG5ZarfUk/I46iwWr4aLu2GUpk4LQHOsU9vMzrlA0LsWrcSFY3Yn8 fj7NJ2R7vbSYtvJhO6KzU13pWm1llhxchri5oAGkFFhVxmUX8tQlOsleCWYQ2x8tEEwk5Y4GmapV ZVdT4ioWzPoMQyrzOV8SmMMYj/muy9tpsVio09xHGkFBkyLmMB18evNaKB4y/YpnVlWnnX6YtAju o1jGU9GNmo7Og6C+S+IE6mLXdt+J3bUZfYiy7jqt2o63rdL6EpqTVaukQRfzhbrE9S4rJ2OBa2GZ 6fOquC35NsE5qZqgJLNapXPKF5EsWW4L3GN8BVdGeniz1Pe56syIMVIQGS9IfnfZt9rPGc1I/V2I +aR+g79cOKpTvY+C490VmbSiF+NqL9iq3h7etGnB+A/rWGZua+xCsDJvYx1xe7moYwKnkhPNSQ+c 1Pdl8lDYlQnet2Gk+j0e+Saxe5v+e6kqeDWIzPhWUkaGgC74LW3R9Dp92Ix3tGuIFi9F4a2tdDZv prUvE1WZcfcKxfBSXdLJIR2Jd8S+4Y5ZNG/zC5qHRJE0JzQrUlBHX5Vxk7fvs0TaBIXtJVaZ8pYM yNsiopbIScbXJcyjPSibTh95vzC55ss8x5nKbZW6zirOIMoaSv0ybv69dp5jlDjgX/usR6ZPV1LZ RGGwalxuS6GwLJa3dzBuvg5X37sK9bm6Kifw7rmivbMbaW0sycAolW6RomLmmkNSqdzyfg7KPFgs It5QX1CatoIkexa4FYW8o3Z9eIPsuk491ki5zx5RlVqgSILDArVs5sl9UfIOpUfIJh8mzuoMT0U0 4yy9uevYxmJRXBOHSR4PubpyGMSI0TvM6LXG1MP9L6YlIg+lv29I6/g7zygBndKzvLmUAE1syrwl B6JKi4tWMCuYZPJ6rE+s2/wbSfKGFAnaPxpGVkF2g2TaKJ/7OCXgO3AiLq5GfCto8wqcyEWjL5iE 9xAlTqP5JlBPXBObjs/vs9uJF4vTQtTI/g86XKeCDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9i ag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9UaW1lcyMy ME5ldyMyMFJvbWFuLEJvbGQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9y IDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvV2lkdGhzIDIxMCAwIFI+Pg0KZW5kb2Jq DQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIw Um9tYW4sQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEvRGVzY2VudCAtMjE2 L0NhcEhlaWdodCA2NzcvQXZnV2lkdGggNDI3L01heFdpZHRoIDI1NTgvRm9udFdlaWdodCA3MDAv WEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0Mi9Gb250QkJveFsgLTU1OCAtMjE2IDIwMDAg Njc3XSA+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2Eg MT4+DQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUv RjIvQmFzZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbi9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv Rm9udERlc2NyaXB0b3IgOSAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyNS9XaWR0aHMgMjE0 IDAgUj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv VGltZXMjMjBOZXcjMjBSb21hbi9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA4OTEvRGVz Y2VudCAtMjE2L0NhcEhlaWdodCA2OTMvQXZnV2lkdGggNDAxL01heFdpZHRoIDI1NjgvRm9udFdl aWdodCA0MDAvWEhlaWdodCAyNTAvTGVhZGluZyA0Mi9TdGVtViA0MC9Gb250QkJveFsgLTU2OCAt MjE2IDIwMDAgNjkzXSA+Pg0KZW5kb2JqDQoxMCAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUv VHlwZTAvQmFzZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL0VuY29kaW5nL0lkZW50aXR5 LUgvRGVzY2VuZGFudEZvbnRzIDExIDAgUi9Ub1VuaWNvZGUgMjA3IDAgUj4+DQplbmRvYmoNCjEx IDAgb2JqDQpbIDEyIDAgUl0gDQplbmRvYmoNCjEyIDAgb2JqDQo8PC9CYXNlRm9udC9UaW1lcyMy ME5ldyMyMFJvbWFuLEJvbGQvU3VidHlwZS9DSURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lE TWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5mbyAxMyAwIFIvRm9udERlc2NyaXB0b3Ig MTQgMCBSL1cgMjA5IDAgUj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0 eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8 L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGltZXMjMjBOZXcjMjBSb21hbixCb2xkL0Zs YWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY3 Ny9BdmdXaWR0aCA0MjcvTWF4V2lkdGggMjU1OC9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1MC9M ZWFkaW5nIDQyL1N0ZW1WIDQyL0ZvbnRCQm94WyAtNTU4IC0yMTYgMjAwMCA2NzddIC9Gb250Rmls ZTIgMjA4IDAgUj4+DQplbmRvYmoNCjE1IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBl MC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJvbWFuL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2Vu ZGFudEZvbnRzIDE2IDAgUi9Ub1VuaWNvZGUgMjExIDAgUj4+DQplbmRvYmoNCjE2IDAgb2JqDQpb IDE3IDAgUl0gDQplbmRvYmoNCjE3IDAgb2JqDQo8PC9CYXNlRm9udC9UaW1lcyMyME5ldyMyMFJv bWFuL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9E VyAxMDAwL0NJRFN5c3RlbUluZm8gMTggMCBSL0ZvbnREZXNjcmlwdG9yIDE5IDAgUi9XIDIxMyAw IFI+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRpdHkpIC9SZWdpc3RyeShB ZG9iZSkgL1N1cHBsZW1lbnQgMD4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL1RpbWVzIzIwTmV3IzIwUm9tYW4vRmxhZ3MgMzIvSXRhbGljQW5nbGUg MC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIxNi9DYXBIZWlnaHQgNjkzL0F2Z1dpZHRoIDQwMS9NYXhX aWR0aCAyNTY4L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgNDIvU3RlbVYgNDAv Rm9udEJCb3hbIC01NjggLTIxNiAyMDAwIDY5M10gL0ZvbnRGaWxlMiAyMTIgMCBSPj4NCmVuZG9i ag0KMjAgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAzNzQuMjUgNDE1LjI5IDUzMi40MSA0 MjkuMDldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKG1haWx0bzpj aHJpc3RpYW4uZ3JvdmVzQG50ZWN6b25lLmNvbSkgPj4vU3RydWN0UGFyZW50IDE+Pg0KZW5kb2Jq DQoyMSAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDMzOS4zOSAzNjMuODQgNDE2Ljg5IDM4 My42NF0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTM3OS8pID4+L1N0cnVjdFBhcmVudCAyPj4NCmVu ZG9iag0KMjIgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA0MzcuMzggMzYzLjg0IDQ5OS4y MSAzODMuNjRdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6 Ly93d3cuaXR1LmludC9tZC9UMTMtU0cxNi0xNTAyMDktVEQtR0VOLTAyODQvZW4pID4+L1N0cnVj dFBhcmVudCAzPj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVU eXBlL05hbWUvRjUvQmFzZUZvbnQvVGltZXMjMjBOZXcjMjBSb21hbixJdGFsaWMvRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI0IDAgUi9GaXJzdENoYXIgMzIvTGFzdENo YXIgMTIxL1dpZHRocyAyMTUgMCBSPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvVGltZXMjMjBOZXcjMjBSb21hbixJdGFsaWMvRmxhZ3MgMzIvSXRh bGljQW5nbGUgLTE2LjQvQXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY5NC9BdmdX aWR0aCA0MDIvTWF4V2lkdGggMTgzMS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5n IDQyL1N0ZW1WIDQwL0ZvbnRCQm94WyAtNDk4IC0yMTYgMTMzMyA2OTRdID4+DQplbmRvYmoNCjI1 IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0Y2L0Jhc2VGb250L1Rp bWVzIzIwTmV3IzIwUm9tYW4sQm9sZEl0YWxpYy9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9u dERlc2NyaXB0b3IgMjYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMTAvV2lkdGhzIDIxNiAw IFI+Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9U aW1lcyMyME5ldyMyMFJvbWFuLEJvbGRJdGFsaWMvRmxhZ3MgMzIvSXRhbGljQW5nbGUgLTE2LjQv QXNjZW50IDg5MS9EZXNjZW50IC0yMTYvQ2FwSGVpZ2h0IDY3Ny9BdmdXaWR0aCA0MTIvTWF4V2lk dGggMTk0OC9Gb250V2VpZ2h0IDcwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDQyL1N0ZW1WIDQxL0Zv bnRCQm94WyAtNTQ3IC0yMTYgMTQwMSA2NzddID4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBl L1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxMDcvSGVpZ2h0IDEyMC9Db2xvclNwYWNlL0Rl dmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgMjggMCBS L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjg4ND4+DQpzdHJlYW0NCnic7Z3fjx3lfYf9B6Sr XCI111HUSL3pBc1FRKSiWmoqpKauUKsgoSRgkgvUG9ybyM5FrIhcUJHIhiABCsaxUGz5BwgiYOki LzbGBhu79q5d/157N17jLF4TunKEts/M4/3m7cycOe85e7y7ljx6dTQ7Z8573veZz/fH+847Z1et atj+dH5y9r0jTe/c3bK2mzdvzr64B4zL3ZA7eJsaOzu9/hlILndD7uANgDO7R+bn55e7IXfqhglP 3ffoFzOzy92QO3VDe4jw0pp1dw25741YPPHlbxFQlrshd+pWiHDtRhjejch9b/jAC6v+5q4hL2bD E8IQQ74bkfvbsN9LX/3OXUPue0N4157ehgiLrObTG8vdnDtyQ3vj96yGISTvGnJ/m56wcIZ35xn6 2gjHeMKBG/LNcrt+Y+7qzKefXJ+dmLx28fL1KByk8C6y//x/5wb1pcuy0QUCsSIkOVyMIU9evUbZ e/DiCzsO/WzT6A9//Nq/Pr6D8tATO92h/NOPXkmP/MeTb1G27jrGp06emx5gv5ZyCxFSeppnUGZ0 /NXh8fW/fOcfHt72d//2a7EAcPOWAy+/ceTt/afeeu84fD7473OHT03w6pE9I8e37jnMOTIELJ+l Burh5I/Hpqz8tnZ8gBvcBAjJnKwGA4Qb3QfXX//jc7xCDCbHxq8gwt9fm8Fsr9+4QWHHwkELn013 Jj6ZOf/76fGJSdhCcujrT0KSgoCpk2/57I+fLwGBRW6IEB94i2Hr8AQPht7k9pf3/iddpuP0EVc2 M3sj4ESB56Wrn0S5OF0UiEU5OzV9evIKxT+1blT6sy37kCWa5Ah/UvlSAul1w2xDhI1ZDXxAhyTo 0dfu34xO6CZ6U2Z1bnWMQbLCEID8iQ7VLSSRH18EseMXLr956FQ4Bw5SyYq1axoWIizmapKsBlCi w6wof/vPL2C8IKXc+OyPFBj6aomDFlAoTkqKUWgUnB7+EMnxLbxCDG2DjhPgCWFIPrfzoH6Sr+ZS Lh+ntg1oZ/7im+EMsWu6TIMhBjdMFS9HF+gsrok/jbb0F0PG0KJEeOUtPs75ICKC4OjQGPYuWLCA i+tC/XF1jN2InAIxKuFLj5y9dOkPn/FxohIHvYLUs9KSf6e5wpBxhqsf/y3dgRU6IXQiDPrFESMm O/QXSgGKDlIqYCPCmsNw3NMM2XwKMiFL9IZdQyyosnP/935DhftOnufdD89cRI18ltq4LivNognB 2G8w3PHYU9v3noADDYYebQYUkgApuTGNh3m8YtE3ky3eQmww4SNcAvMWasOLUhQYUoQeatdmKZCU Em+NnjgHPfYhyQ4AT1yaBiaf5QiXY0VZNJ1NRUh5+MFnaba9ppuC0gx1blHC6flWesL1wi9+rtvk TyMCsZVqDRAIFd2+f+oCGPkWGCJLrhd8pKrwVOMrw0dhiEq5uOY8XJ2VIEXaoAN/+Uvf/rMhl5kh tmzgMBbgyirQDBxpSSMIhY/wQTDSfbpMNClHczdwDkXSsmlU5wZJrBtinM8OR4ADTHCF8HAjtPPg 6YnD56d5ZZ+ciuRqeUeFdITGY1Y0752///dUhMP3PoJOaL8ZS4VeEANOlMZAzAe5RsYXDkZuY9aN mWPjGmYh0S37iDv6THgCUIYIkkvwjYdewj2OnDiHMsGII9XAGV8vCz2iqn6JVuFz6FSkNBaQ0nfH FCk9WaXoKhgrAHGJXCbErPYqySE7HMTvYc6atq4PdHCDFQ4TQ4at15q3HF+rXo6wQw1LHJ2xEUwA 4XFlY3hFXh0pDYX92Rf36MGkl6pO51YpjQxVIKISIKWSXfPKQT7OQTCKxQguzzT622x4/mLnh7zC 1gxhKYct0DPjIlvWgdMLAKKWSjQpGL53hK7xVld6nRgC0BE0xytjPUciAHx135gao1WEDBnimYsx 3bEz6BMpfnR2EsvlT3BxReIgRziNg0tjyx+PTXERaYDQHFspBsrU2Nk0pTGgcBAIdXo3a1uFIQWA vHKltErDiqYNQMzTWK9h4tCwCNwgZ0pJOy184/kiBBOyIQZtRXjg9GVcIgDZ+e7GN5ZAh/g96GEI XHrHpAFQSdAvb5qkBd9IryXTQq+RoSLkiEMVPBVVmcygNGdgCAfAoTG8RUsIH7TEhJwIgnppMyTN HmEITOgBFnQC5JWiLdO120SPmm2wnschZwoQQWrRlWjivGtqp53odQLIcfyGQZNuOk4kY+F7laLj EVNBCyMOTkNsHCfGcb6ZDFkNlssR+sKfmjDl9SOnKQ4qb8dsGF3QHGibmX8dIAXvhCdxHUiV4fpn RFcffTgASQHKEIAeRDlmm3g2FIUh6CFFZxtskvQ4n31Fyw5/IkWTariRS/MnImRf7QXA7R+cMmMf bI5NB2kJ7cd2nMlMAUY6oQgZwtejSUx5VfQ2n2x1hhyElWke2nBSES0BVqmnc1xxWWXIjpkeksPA Hc2NLEgRem8eKljhMwPg7g//h9fn3z3JCXzXABMbuDkIpcHRvEaAThojnmLsn4xNopDYdAXo8RSd MwBsfLX26+imBSCFaOJEEOgAiPdzJAI9vKKRF1lCOADK0BOIXAOhR0ecKcILpde3kwkbJWk8ik3T wkhsvIfSyYSLedrZGxiR6PhSTT6GdRxxTsaoUQEYJkzBHEBNJWYsALTwJ76RGIQqyAYJwSlArPh3 Ryec0ll8YkPLqQoUxg6+uh2geRqdhSQ+k8FI3RmO37MaJ1mRXJDEdmi5807ewYy7JKoOvHwvWIow uv+UQSQm+VOAHHQGDGgBEL0ZR2DoVBvncEQfKMBtB87wytAPx7tIgDaApmIIeuNGgOeuFh3U+1kA giH8y/rXLq1ZVzdkp68rwpuYvCYWvtSDEYWDnqMeJ6sdVpgSc4IiTAFSTAip0CQwBejcly4RHcow BchBCJP39k2Pdpo5oHYMxybVAWIppMo4N5hQ2J+ZmKIwzH/4wWff3z4cN0DrOgzhbd11jO+CBtJV eJFIpwDTOyawRYG3UuVNo7SK4zIMgPzJRYESbjBMGHoEDr8Ol+iF4JWDtwDuL8uBMz946m2Ggf3N 2NAL6uTbvbMQTUoBytDIAiX8G1jYieKRuhWnOkS3Cg/gatIksDKlkAJ0KBdJINbhJD8NJrbSGIML 0GghaQ8CYJ+Uj/ZDzMkxOgUxhAdSjAWx8XGcYQB8afQkpbC+Xcf6AHjx8nWuCxVSOVcQE0gBBkNN GAj1AUhOAS8qRQnAUXj1sXDFfmMyIeYTOM51BKM5tnOqL+w4hJfDcEBKR4DGDmLgYmGzzmtBzxyG HbrJ8R898y6GHPQQIUf6GJ7QF2/WYJ70jp1QYEWEEUSKAVSTqeYUV2ymN+zq06qp/Qa99DaxIQxK SM4URVlSUBcM4+Y7LpF8ZnQhhY4iQ14xZAFaEDB19iE/rqCZAAxTx9IYRxBhLJjpozhOMeam6Bq9 X+VOcRqCdSnsk0fBBLcAUm/bOebFkB3KjSQADcHsON6BIYYMOpJqXp/Y+j5XIf82iuMOR+K0RIDe UGhhSCBmvz4K7oHh2o3OG9Tp1b1fPYUO32LzDMHGEd2gibRRuBGghcCBeH7++lEMGYCUX/3X+H2P bMMTZo5NQA3wPSPH+Tq4GUqiPe0irMyp9lrIeZz7aqHXIr9KAuMIjn0Gv04stACMLJrXB8qgBjdF SNET5gyQzSgQvJlnMejeNApA21NhWJlV4BWGjaPgHhh+9TvOwVboVQDW18l0AkjYxYoBQhwRYIVe AISexeC7+vHfChCST795vLgEw+NdAXLd8b3kkGaetAT9E9caAaYM7Y45Yd/RxIKGienlbaM5rkjj NH4mPQrQOEIX8Gz8mQJM52ECoBkgxAgomDMMNw+PwfC7G9/Am3UF6NwvXxE5J8p37rHCsJLPpIbc X0rTaM6OCvvQXgoQOzKpMHy02G9kgDDEd8Fww+6PECE82YFD1xkGF1fQDH2FDJ21iLZVRFifnCkm tZpGcP2Y84t7uCKUuvZyAEJPO6Jf+qWKCYf8AmBkLzDUGaJAAFK8ldxCDyeJ/cIqnK0T4DEa6mrI EZHxYy7mH5QUG7WXQ4/Cn9gvgTjSv0b5pQCNHUJjRB8AQdEyRbP34EUnab3L79QH5xc51f5TJmll mUsWp805xYqbYj+dtC+GxgyQF11wCI6ajSxqzyVbTTfl5xZuQM8ZyhEADIkgaKmSAUKvyMD/8Bkm Y+HSVwrnO6MI1W889BJZIm3oBJAUHcIIjzrnszccFJeeNud/pO8NVgrP+eqczdUdBmL8eQzfBOiy /5wNfZINDn39yU7zM/PlAgCkTv3eqTf+xgr5+qtTds4Tct1zPtLfK4WaqR+ZpQD1bJ0+wkBYgKPl sBeAqCgFiOVqLC310J2T56apB5dIYuOcQyNA8mccICIs1mmUCuTjrijrVBiwCxAnI8CuH+m70JEA iMdwqaQ30DsV72sEQLwT6RnmnN4EESDOraUedYK0MGEKYBsBEqBpJHVSuQAJHL0C7PqRRQLEURg1 BBiLBhuLgy9OHilTF+SBjAGYhg8BtteD/6ceGoD8yAa5ao1DEjgTp6xcE+4qJ1u4NAqk5gCIx8hX oOstUaCTKnELyZuYAmyvRwUiPACSDSJCjtQB+qCQ9ROP8hVIFCa6CdAVULejIJI6wBwFcnKqwEaA OQr0xi4A8YR0vA6QExgye2tAgJkKBCD5levQqFlv7O2weLW0u5qhcu2ZZ6afct+L5YMMvSrQvAWA +LH0/hFxIV+BmDD7mDAFVnWAjhb5ogCYr8AAOL+wyDndiX1E3l4hJ6SZw81k1bRbBWCmAp0JFKAd NHnetj9LgQIEGtrDfgFIO+sAnUMwuPekQFcjM1Atnt3Ydcz1qC6qjJt0Zh0+ltUVoPeSfC6Ma4RD doKLg/pbSr4CXdJWB+i4gzwwU4HOrDowgUw9jng/0cp7UiAAUSDF+1zyTId77BuVyKByACLp4u7P qQnqj5X2To3GYA3ImQoUICUApiPffB8IQCMI6TTWWhnQcbnNM628VwUWz7+UjxXILQakgVGAmQoU IEW9ocPAOFoOM3lLgJkKdLpegJqYN3/pb74PFCDyQ4RUVZnhdz2AAKmcLuQr0PVjPgrkIooUoMWb bpkKZASa3sMiE3Za0qWntGr73hP5PvCjs5MCLB69KQGm8waacL4CibM+/FJ5VNlpQM6xcgFmKhDv BBna4B3/KOnESE8KnNk9AjTXlEZx1X3cu1QVOQoUIIWTn9t5MJ33e/7dHhTIyQCkAJDO1p/1phLO sXJEla9AcnuX0br+E2dYwRgAMxU4dd+j02s3fnD2ajC0KlA4pfbmoVstzFSgfgnTw8kbfAMgSs5X IEHk568f/dr9m6mqDtAlIgLsSYFwpgFYccy/idHivJwLNjIV6K29S2vWFU+sn5+2hijW7yxKpg8k cPgAjveMFuMDf/rqYeII59cBOs/gPeWeFOj9ax9gcQ42LXbZqJSvQKdS2XnrveM+W5TWybcIMEeB rwwfxTq4dsgGhfh0A1pyBoZY0LWeVIEAJBtsBDhUptkpwEwFxnpv/HNMZVdIEk97VWDM6r+/fRhz TtdWURw55iiQL0UzLnF0cYIxnYOgAGCvChRg/T479ZPh6Bl6UuCekeMj5ZptZ7PVYcqQnf4UaJn4 8rcO/2onDA+cvlwBmKNAPoUqGA8+8MROZ+kxZ+/5xlCuJwWSyWB09Yl9n06l/l4V6JQvPjB0mDK0 9K3AKIQV6pEh35XvA/efvkIIpss/eOrtcH3e9aCzPY1EVGCnkYh6I8/hTJjkK9DBpjO9PmqB24n7 einA/hSY3l3CJQIk5szB0vX6YgLeKMf1mft5r9zb5b3mgc7G2M4KQKdreJf6BZipwBhsqhCMBXft wy9OxPGar0C6Ez8t1XijE5cIw5wpXx/M4UwCR325C/RQ43y5mt0HKDoVTqBV3hpGgbiCxtkY14jy RZzWkwJjsEmBFQx9PpcrHkspzIsyFTg+MbnvJ8+3rFvgXUYrXad3wGKQxUvj3jcPj4nO+7zQ0w/Q zpZK6IhPMsI/gkjjfCCcHSlzgs3LVGCMlaLAkJEXXw1JRahTzfSBt8z/J8+3rFPyJ6fwTu0VYg5O BHl/M1Z02B42n+BoKc6EA0T7pWDvjTPSjOZwKfhAOv67oxP5CjTVrzCEgLdiiSyv7hvT4jIVaE+x U6y1E8Pxe1b/6fxkV/8/VE5l68Qqm79p0268Q+WDUZwMEOk5o9X4LBh6ZozMCf7QSr4CsVMBxjJF X5371SVGSpYDkCsSzwB2WqN+oVyTOV/eSG2vMzDy7U4w+sCdvwXUXrx/xKb98kqqDKU6vVULq8rx kDAkBPQ0Fo4hUkqSor1QLX4mX4HxACAFHaLkRob+MkPOhe67RCKk/BzHNUYQN87H4nCwZK35CgQg 0c1pnMBY0SRxIV+BSDq9Cny8cAJNq5X0hBhjjpx6LTYG5xnhA2kNdV6ZsGphbSqn9RSFMdUAWMdo OT15JV+BxKAUoNeCanc89lSdoQvUabk3fQZScIw6MYw3ZrEASITlSrUvlkZ1mLkAuzZJgBhpMSxa mCNKSUaxwkwFIukUflwUMNZDs7/MMF8u8qc9XW/8dS3IhnhqhZE8Q4+BjO+2P3djNkgcnF+4E+oD ZY1FExbgrTV1+//8mE8doFGvU21x3ZF041VwIMa4uL5wDlv+YmbWXhNzvYXaNcKmkovfKDNGF0vT h8cidaF4abqu8iXf4EzTmMwNgD4OUGW4IEheBZhfYTyw5k5cFGcAUNrBv3qwnthce3qbYcWNzJZL HL8sSpIWBeN6qBxQAI2kLu7JzpcpH1+aogvjzXnYgSvoGi3XJ1MzMbH80b+59HFC2kZV7kPb8VH6 cErKk1cCWX39XuyQ1tILf1oQtwPAylVIF47KkNBc+amfmLoh3LikMP+SzZeSsyMpuqDnmnPHhu0A V5W/asL5fpaIjO0Dn8jiCMhXornTDo7KBdiCsa7MVKK869MZPmFKJS4baKwnvmX73hOElU6ZNseB 6d0BeJJXpMsmsQgnJfh22k9PK9zsPq/Qo2E+a9M4AKlvSAKHQCihBgpBHPiOkV3pajoEQDoCT4sk KzBbeFbY0hFOdt7Ym9e/2PmhZhtTKI2lUYf1gsk/+9NtMZqI106FXtNBWqKWoEGCl//YJgbCZ70E YoSYR1KAzmkoy3aMmTDBxWl0jdYie175FvriWwreqp7beRAgw/c+kkMvNMn5uMQWbqLj9YFyLRbK kYDzSzn26wZqyGNWwdCb8hTq50/eTQGmDMUYMJ0A6aSfTpDBhQJdjEfjsSO+ju8tat5yAMvtewU7 GBEtTr5usHYT8XvfzWvHQX+TJ+cxpdjmy+eVNNvUIeimhEn9cOMrKIGxDjOVZU8FmAqSr/OB4u9/ 5TEscTGPkqUhm6sAxvB+dAe9iQ7lRJeVXx8/4uE8rZ4wGOpLLSnAwNgVZjvYyvHi46XeFvMMY1eM XB3vOqnzVI3OHvBuT/ILEYLdR3VShspvqJz81x8aaOqlQjKzFAy3HMC/YWiD0ltXo0bbRH8NtmLa xVPn+0/1Si8Ykn8ibP1qxZZ9vtsvbcHYK0kAoopOvxJwmwpS5JKl3YzJZ6dk+wO4auFHY3Tg9czc x/HiwqUkW3imxl55Ddp0Z1APOnWVnzGloj0Hv+hkkT9XO1/eMkijSUyLudgVhkT81MxTkl3F2UKY KJyZ4y0GHVcqPF7dyhybLwbgqjKlYeSYGrKpNYVuegvA0Fx3IBVltoCtHI9PtYw1Fqu6TaONA5Aw MXrdR+xo3JyxRG8xs43q+IoIzabZmnN7mlpPvVJojYWe1qcO+vZ1XBFV15JI01O60/JMXK/bfHn/ K5xhBPdUZuSfaeqejzGHM6+LkSL8tdau3+UIjp72HXlbGPpTkK6Rc5zoWpH4au9YhRQHi5HS09jN gZt6y7ymWhPt9w7OYAGuKp2hK502LCRI9ei8oRxFcgWRoqhvhxQzA7SZSU/X0XvZt4Oe2/Ubcz/8 8Wt4PxoGScy2MXAA1tyeEzKvfk8YUUhmgIZ2/qVxAfagAkenzV+lkJ5zC43tMY9yFheHuWFhlmNQ hdoefvDZHK9YzMDUpg7q9Pyd86X5ZXh06P/3caK1vWFObsTczkDUCD2rpc4ci3ag0TJr6s/oLdlv ws+Xj1x509PfE2jvLJB1jKbfIdH+7NcVekR8PXBh0ZtGu8Zo3q2bs1HD3yJb+v9KYEyJEXF7r8Xo UypOOBtiesIoLq9FzFVGASOOsR0j+Uzkz5FLrP/lO8v1Px343q27jvkYco6owqix6Jg+6ppIp591 DN4pvqvG9vhiLr2hzBYcrN3uqNG+3Vz4iWy6lpm3eA7opEEv6IsTcTGma/QDqjdNPjuh7qrGl7/0 bWLQwLPlvreT56b92dv8SBF2jXq988XHIelscGWGh4M9DXM8x2yn08wYUpxe/8zK+UfJhTmXP3yt FPPDhJMJknRMbbhxnRjFmXbedcornW2oQ6vMUXAEF0cm0/ij1hcWfuts5WD017O1yg295H722n3M 2STTRRdD5To9jqBDilQr/AOm71IDwH0+2pSeer7/lcem7nu0UZCX1qwD4wr5l9N4xb0HL7qCMaYK 86OtJPWQXAhnHR8ob1vE7RidoUVEStfiCT5H4wf9yaYDpy/TtpndI9NrN9YxIsWVY9Hzxa9DzMVv FJu0pBrrhM7EzOASo+lUYwpMjVEQJJVTgOyR0Cf70uNS+s+nHOG64hS9gcvfGa44RhfYLDfCW5sY /UlY+hK3C1NNxp8Rl9u9aOMkber0+BY1SVzDFlrGF4BCkNhvZSwDWI6vKIwfj03Fg+eG2vBjJthm hqguMsOulh7crIQ6XYJSPJm+afTi5es56TFq/GJmFlYVQbquBoz+5MUSUMrZTBr9p6X3f+83eqeh 8lkMvWXcWup6C0AjNQWiHmqTG1Gs739JE4L8f087rlnHQSAPFsUit0+uzx4bv/LyG0cI2fgoSfqU CiQNHChKt6av4whC9VZChAl/lOyFHYdcbjeQtoGRgies/M9Q1TiQrxjgdnPhH9zgKuM/rfvT3/6r ZbXq/6bxH1gzeOTk8p/a3PqnLbejX8YaSUbys6KynTtoA2NEbUiizALjCjPqlb8hPIppZJE0rt1Y +MZPb6ycEHMHbRFuMPAVGGLulA35SVIp/h8nHOeEDQplbmRzdHJlYW0NCmVuZG9iag0KMjggMCBv YmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDEwNy9IZWlnaHQgMTIwL0Nv bG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50 ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzMDY+Pg0Kc3RyZWFtDQp4 nO3a0Q6EIAxEUf7/p9nETTarASkwvWhD38cTjTG1JaWjck5U5W29i9q3ta31VFQLpKpWPpeCKl0k F0ttlRUBeA03oXHsnDVBo9hf1OyMar9cpzRujRVIPdiaorqwSanDmpbMlkAyYhrJQokkgyWTmpZQ alhS6dYSSzeWXDI3KY6Ug1SxXCSSsrd5HpabRFJXy1Eiqc6mXGdxlLMUlMorKHdp4G/tTRQgBaXy pjZVtTiKkQJTMV+LTW1qGRXzyx6S4puzmI00YXFUCk7FnFt4WxyVVlHgPJCccoKzW3IiTVLg9uDl 65eaRO6vyK0cuWskN6jkXlhGtSUVZpLIkwnzlhkSYKT1XOzh1jnj9xQLIR+sllFrd6Euq6E1M51Y VTNFerGhWoJBx3lJ64t9AMDyHrINCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOSAwIG9iag0KPDwvVHlw ZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjIgOCAwIFIvRjQgMTUgMCBS L0Y1IDIzIDAgUi9GMSA1IDAgUi9GNiAyNSAwIFI+Pi9FeHRHU3RhdGU8PC9HUzcgNyAwIFIvR1Mz MSAzMSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVk aWFCb3hbIDAgMCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgMzAgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0 Pj4NCmVuZG9iag0KMzAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDc3MT4+ DQpzdHJlYW0NCnictRzbbuM29n2A+QeiT3aRKKJI3QZFF+1M251F2s50sujDtA+KrcTaOpJryXPB Yv99zzmkZFESZcWjoGjriJdz4eG5krz6bl9ld8mqYt98c/VdVSWrTbpm769uit2fVzefd+nVm+Q+ y5MqK/Krd4fbCj/9M03W6f7bb9n3r16y72+eP7v60WMxu7l7/owzF/7hzItdx41ZGIdOGLCbB+jz 07uQ3ZfPn7nsnv4SXP/50/Nn7xeXyz/Zzb+eP/sBpsMpjxOJzkTvF8za13dEaPb1rH1jJxbT5hWu 53jc7GvDV7j+KL5/P3/2toOJHziRz8IodKTUI17++jNbXsoFX14Gi2AZ9lC7+lEOcBwJak3zjet+ z7/tDuwvle/I2IRv5zCQFZp9r5ecL94tLwWM4q5CWQLKHv44jbfwAmLuo/EWwnUCfxreQnhO3On7 g7Vv5IiRedUKsh9+fsnY1RvcNz+/fP2KuVfXSX7PFml++dP3S2Nz+Ix7Buqw4oFkYeA6wtMQVku5 KPI8hf/hzypDhhY5+7i89BbZFv/asrQssUNuwZz7seMF5rxqomRLM3yGwewWp2DVJmVl8rAUC/zT WV7GC/Ydu0Fo19j1HQNQYlGWNSJZyQiVdZqDxsCPGWiK289LWOSEvcNZjp1fv1r6C5blrMIPG4KI ZG2pA9FQsSRfj+8MzSYZOL6mhnDaf9BY79kG/1a0FaWjCBA1AYqlSFmfrZqaQ3lItvhj+5kBZYQX dbnLgC78m0iUSOKmKCvsypL1eq94k5YsWV5GCyBkV+xVa354AA4Hi33pWJZJxtIJTbomyBe3yxe3 yJcnHVnLwW+I047E6DP0+GNhkyHQdYFnjn1NXP23bYQnnDgyR9i0I/dCJ+5gdmPrK/zOvOwSjIoA rbp6v/hj+cI2TkrHNSiAzzhkApM9O5M9C5Nd6US1ok9AUv5Y9nVeb4GCyIndzuB673lamZr7rzdn Dx8O+pCbU75gN5tDeaF3IWpn2jYpGhTYAYlVzXMQgtic66seBj215vGQLEmHKmHRKLgh95/RSuyq 4n6PlCe7TbZiZZXQXkpPEy1CTsp6DNNj38Dhnb5WgxHGvb7F7X/SFeyi6gJ0B9i8j4ArkLBBVpbE 4aTmLmgN6BKDwvVcpWsnKLog5o5bA6s+Fn056nE8DJ2gO3KE46Tg1rsiy5fRoionyFQkHdGZ38Yy Dgaz2xcZUrHVNktR3xN0pnV4iiu8Z6VSuw5DPf16ycUiZ8VhD13YIYemSx80aaWGAtrI93sU5C5T LQySoHBgHa0M6hkl0OnILg/ZNWXNYAW8euIjeyu1g0mO5RQ55p5idHs6K6O9sNdX83YaU3jg40hj gp7UtKws8QTFpyEOVuEx1KGPB07xJOqEF/f6ZvldsQdUHigOYWTvaa+h8riv9Roacg5bDqWj+ECo bxPwQ3YlmLvMITG7YMqBWS0vQ5piO2mVA+HIGpkdQU5glz+klRJQqy2Vjt8ZbbWMbgTegNH1A+F3 IG6TB0WQs335x/LCNksA/nlkTmMVo9Dt9b3FXXioWm5bYyzQk/IUHojGep1RJ1iPZEubd4Av6GaA vuwLZVt9e8LEYYKhQU3udoYpoQVmuYsPS6klN1nTh9pfOy2pEpwyGY4j1PT1AflOX7T+IJOG3lP6 pKvmykmCJ2NQ8LVJ2JCiKkFpgTbf77WHSn7tP2yLzH3Hj8x5JvhBwuYHddCDvdqYx19Ba/taa0uL 0gY5Ip1BllLrkVv8Tau3Zqh0G7sJZoCttRIqaR3JY8h2oASQozkJ4q3a6vbIDygPTUytDgJ4jrLT l+S/PDwkt1tCgWDdoNN/vfSauBcWddRdO4qM70RiGjYSwrig09dGpQQZ7Pal8OewBVdkmvfBg6OJ pCW8yyBu8mFVaIHYXbHdFh9Lu9sdortuTDMJLiZXTogm/PTB5gXMl8LhMQS6Eh1N+G8Axn2fPn/2 +9csh84tEZZDIjwykSdbEzVuO7gN0vTcPfziRz5KlQ6tgEkpOYAoJijnW7KL7OYatiiYUzJQ1KFc xosMG4u8zce3RO0XYsZBKULAY6DGekDeGlz1OOguXsMU4IT43jhbfQtbB2YSNuy9Aew9HqHZR+zD +OiTRGiFYjJ9mnN72nEFJp0oC2FGMYrIxyDjDyEDzocITWRAEeACqiUWeolnhywgmBbChDw/fdof M5l9veQSPeItiDNxOs2B56Su0SMM0X4GtfQyakR3EL7lqhMuSVmBruj7hY9He0hGJHgsIpqTOcNQ YKA0oaD0gXs9IGozCZyWfgDthmMCBzrlHSP3gVr3gFcdSS1j/RGVDNghvUywRvXWyXGF9ILWSwtr FTzFUnGJlBgEXbBVcdgBYL13QH5IZm4/43+1Y5DOL+0SAlMwSQYuIO0Y6dwhzAOC3wIbtkqMn3aJ warLGotNkq/LDQrXX/MvgYdRnm8CnH+3eAGQxU0oO2Qo6elilS6jxRo8wxBklxImoNHZR1AxCRlE ln4C6tMVJWMb8UzR54gWqz1GEaTqQffUKqaWE+yhPherWsJBmn0cPbsM+a6LaVGDTC1DTywv4FZF NcQVVQiAVat6+6L6NbzNuVYVfAnfBO48AZS4R+Kox9J2RALte1A5EdzqGFYHq1OMY9mGO35AONx9 3W6NvLpZymOz8rt0M3k/ZgcPUI/D9vSuA3HjQPPg/DWbVDuyKfA7GIiINJQN/2PzMAGKPu04YgsQ 4bv9DtwJ/ZHxtmbtl6rmEf7YEWh6WEA0kkTtYywaIbLuYSPjRHtPwsJpQbAP2EJMh+JLsvh+cTut BhDTRmkN79cA6hKWWOR1jlKVsSYVBHwX60wGgBftityETGEoSe11cOyU2PrltU4mdELiBevx6Pi2 IY3V47t9RzLNmJChlIRtuphkahroOOj1pRQ2RCqsHXGvsd5WrhD2PrtVcXS7JpB0FsAWHvuoNmtI trQCBKXdrrY8Iyh2krp23+qw29bixbI7zCJj/n2CeHgcs0vGZFbxAFNeTS9mAZ9Dc2JrHhMkJxRm X8ra7FTuBmnJq7Fqlx+jSjMmsCVlvECSojLYt8fVJ5krwdnGLNG+YnudhNxSzrrEPb3JdjaxgmWJ J6KAOdOQT+ONgP3b7ZvgSqz0ji0wdbVfZ6DnqoIR7q3cm944JSYcW3k3W2HbB5cllHbMLMnGaJqe lTHlio/JrcdUWo3Bj9GyWNLP1sgydfIC2un4A8TIaVehDKk18BvBkTLAGzpYZdWA/5jlqNNuKE9N eh2jJtIp2J2Wo0put1nZzLEeT6FOUDIyDB1Zo4dTfqKE/jbJE8zf11rdfmiAU3rZmGZCGh+LXrIz zDyDYrMvx+Mbtn0qXXRGjanbh2Dax1ggjvjCkx4T6gogANEJDh37Bh1uTjv4AM6Qw41htnMPAxKg EsjTsrAiitFh1ClK8GO80JItjEeTsDSPaM8TPCYJi7Wa2G/2tAShoQQWCAxWDSimrMAC1CkrTJtg PgSrJ3U+RCxUqdYSxM2Dp5B4RkGXMhEwCh+FrMFCiyAGvXsQRFtW+GwUuBujULRRmBxi8cEzbcfA TyOl08YWpEaSvRICPz6Q7KU8DIX9q4QOZ1Hs/3rJo8UbVu1VgS1W1jZWiYZjBhL3LCYBMAmmkgZ0 zqxOga2xD/1cYQKhaqU0WzllW6h7NsXSix3fNyn+an4oQjjxEF+v3y25v7hCQq9R6OX8oMHQQnD6 1ASGAjPABpQnWCw8KCRNKDtMYRXVUTKLLToB48C9NvC2jpwHz3obweb2azzRcsH2IOX3FyJ6wUi+ HfydOngWzMfs2fwS4EUBxvgGNpfzQ4mVQ9WGQqtCMQxmyGGrF2oX//e7LwQPBAVm4QTcChHTPmus 5fXsNGId2u+s6wV7MzsxYPqF/+TEYMpUdIkhrXQx/9YVYeQIbkKbXw2JyMMckgGl1rOzKyPX6/Hv CRSrG5DlaEP5H3lMd6rOBMrvYcnD02WaSSgMlml8H2Mkk6kqxa7y3tFiVdW1SfN03pNq3pHkvPQ4 Xt3QcRMlvABB8O1m13qwVUNhwrPm478ASoxlbwPK+Wzuu5ODR9inznjaDLohXiRRaP8C6/Ar/Eu7 8ofzaBiBKOmgswHxTEaNrYaL9TsDCP8iKHIQSkSBcgtK9/rNPNQE0nH9p2ZZEDgRN4G8SZpqZPKA XrC10no21DjG0/IG1Kouce9PxxNngBRYXu+AHDcKZwGJsAzTAkJ5CM+XlFa4HnchzwEoXLxd9sRU CZ+8nicVRCFCMqdtIGS3SkbB6d8H4ziTOgtxm2J1PDmU9SeKZ2u/ApNWWFJA/zZh1/JE3fkLlamI qczXwjxfp3h2I6VD+V77LEmr3I/hdLEq6jMe4ybqLJEUGGMY2A0yom98vH69WIK9c+0FY2yua40D BdG62V4Qbc8/VDG2AtBc0u0j5VA7Bcf2YRKIwjqrhC2wCHygQ4SGzj7e1qyTVqrZzqERBJoeFhCN JFH7CI/GiKx72Mg40d6XsokHp7GG44ftmvGUG4CDR1oHJvc5qlF9kvcxtWhj5G90mCYrTie349Dx o85oa7XOdbFkaPSl0kb1MW2qLBMw5lLg3QpjnhM36PBTNYEcvMYGzvYoOQMYeZ7bG2apNAXnlPOF y3vzvxi6qZFQ7TE51ktYccc4sOLFL9YrqbCZwChaSbZJ5OBp4AGJFLSXj/Wlx5TujMETlrguvJYH NEEPGMPuVNkOLem04jPHmzEG4Bcswbt/tID7tSrR6YtohboOqAtuVFBluBaDRbQLVt8o2FF9olPR 0jdIVxhvU6Kbem+TSlWocMaPWbVhyaTbaejB8ZoCuixxS/N9yOoJNzijOi6BBxHF4i/8oG/5wHa0 XjWP6DycAQA8GEAdLwDd3ZnirUurcevq3g0S13o6gM4HDJT6LhgJd76qlQP7iDU39gDtsLL3m4qt 0ztUVHlqK4zJgKqvBrKT2OdKjIenFcU86WPmacrVBB6MlsVoprOvJnhRiDFQtypWplQMaV1AgI2C KWF9cWGHK6NKznSk0FaIOhc5HkaO55nYTbydoDk75XYCHzyz1Znq/NsJiH3cVKrxtlPLO7f5ulNg DuaY8HoZN2Hi8vVukjB1fhkDzg9Yy9aFCSpS5BhSkONuTUqdyxMBFlh0ePJFTBgGQne2DSB4enij SnhA14Y1IdSu+aUOwh9jFIqamswl8PBTc4z2oM/R1oWdnOnqARUTZ19VLNLLwCRo0kHis8VIi27o 45k5bQrIDgCRH5qD0+2z1xsMMdEg4P/tJ9PPXlNwlMD5NTCaX3DURRoDSCtQpd1BMlAfTsd9hGQz +vqpKROXx6PWGAXf012FTmBOJ9TV3YvWHZkL1kziYOWNAvenXWQwAeBcNxdiAaEHypjPrZrwiZzQ BGct9Z0NRJL7ZQDZpfuaqIR2Nx6kQG1X317qXlSiHf0Umi/ucPuCkdYoUJh0jYTwY7vZoUcBnj01 oJMM7wq15CR2Woml+piJ1n10Q3fuhZJ+hJciDITWaqEQ9IeMHMn7ufkgY588ijbY2dWIjOlWawsI cx2XRx6lQOfYzmPuhowRuCKN1pPWWa/lyeTy+Y6Hi/UfA3pTiMNzNzklKifcPzlbxDmdyDUweAIL 4ZESawNR23duhgohMcFpQKLLTrt10hxAmn+DiFA5aE/LRfWojsnF1uXcXLlbWBelu6GGFZ1bEYFZ CkKL4D7u5tS57PBdzIWZKDizM93nHmml8ZVtBVNGjBT1M+FYwoq4NROuH0u05XnrZnuetz3/UCbc CqBmVNyUtC1ZXjsFx/ZhEhSFKqy13p3ywORHwchwW7MOmlXzCIOs8JsOFgiNKFH7GIfsJNYdbESc aO+L2OC5336CxfMCfA7ucWlwb+SlxWD4kTav/YzXW8+WBQ2lI9xO7ykIjTzNZ3n6kUd++wG85jbA K1BX4Cy9Y0lZFqssadKD6q4GdzERptKbu+qCpc49vmhUMnphpmLp34cMH79JtmmODxzph3wKlhxn 7jwJVuzZKx3NnLzVVUy6TMBDjqlBHYQUD3j3ST9dA0zKcjxVn9UJWZzX+nZNEKLAtqebshojb/hZ xIODHvVlk9YBVtpFRDih2xkxBSlrXcguIl7bik0QEcwghwvzXU/oZLsgISg+NqBYL0iJoNe3JVFa XOrEcVtkbNeS1BtfVuA2LloLYNY3MDnY4/owmfEEpnfyCcz20EkvYLYHnHgAs931xPuXx66Pev6y NWz665fWco71+csoOj41e7PB19byv/CpIAo0jw+w3mXH59sc9ezT701Cnx6DWusXaWHcQwpaoqJY dbev76BV6um326RUdynhd6+MwLH6Y9RLfsPN/CMs+0v8YX+RFUJqYRJjYdf/AVmnwMcNCmVuZHN0 cmVhbQ0KZW5kb2JqDQozMSAwIG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL0NBIDE+ Pg0KZW5kb2JqDQozMiAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8 PC9Gb250PDwvRjIgOCAwIFIvRjQgMTUgMCBSL0Y2IDI1IDAgUi9GNSAyMyAwIFIvRjEgNSAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA1OTUuMzIgODQxLjkyXSAvQ29udGVudHMgMzMgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1Ry YW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Pj4NCmVuZG9i ag0KMzMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjcxNz4+DQpzdHJlYW0N CnicvVpbb9tGFn434P8wj2QRUxwOr22QIrd2s3CwSaPFPiRFQUvUBZVILUnV8f76Pd8ZkiJpjSNv 5G0Bh5rbuX3nMoecvCzr9SKd1eL588nLuk5nq2wuPk+mxe73yfRul00+pMt1ntbrIp982t/UGPpb ls6z8sUL8erNa/Fqenkx+cUTiZguLi+kcOl/KbzEddxEREnkRKGYbi8vXLHEn18vLz5bV/bvYvr3 y4u3tBf7D7vUaNdnSxjXBo6KhmuVcW3iJOq0c5XrOZ4crjXxq9zgQX7/fXnxccRJEDpxIKI4cny/ 2fH6H++FfeVb0r4KrdCO7rE2+cU/ol4I1Dvmueu+ki/GG+/bJXD8ZEjfrGESKxquvbaltD7ZV4p2 SVez7BPLHh6+zbfyQlbuo/lWynXC4DS+lfKcZLT2rXFt7KgHztUWFG/fvxZi8gFO8v71uzfCnVyn +VJYWX716yt74AmhkN6AdbJ46IsoIAi2FD4qx8BP5DvKHa0+gR9p5icw8OO7TtAQmMKeq8z2LcGP 1/jzSZSZrawcw8uiXmMs1f8UudiVdmIVM5rD/HzPa38Ut6u0FrymEvUqE/PMDqwFDUg6aV1jggKJ SPO5SPmXuLWvPGu1nq3EBif91Zy4EV8sQK3PTwUaVdWyUJTg1m9nH3S7RmZCX9TIDNaLnKXDYyfY JvsLT8wDsS2tL7ZNzIt5gSFIRaOeta6gAmzpdGDyIo+QKwe0tbYEbb0KmPq+/Nm0O/LY0Xu7T4CD 93h4ur4Tei08/W/Bs7/6BH7Uo+EZxhRZwxPwWe23OxjP06gknaoTIXkPkSVOYcOn3Tg/FAOyiHtA P1Ye9w6TMf3Yd6J4KNsJ2vMfbc0wJNTEDYWXEEuRhGBuLvin/6OBRSmVo4b7T+AweLx9feX4LYJ+ g0kGhmTbLbKSTFZoG2jz7yvtOYv+YFXDXtoLxaIstiSrwLqvNLCueG5N7E3hbsdjCVHJaGFipTcb jZWVSEWORRyghgD4dqQJveTgIKZQs69YXOKM+E1vblhoBMC1xh/DWKwImtUq/bPBtUOlQmK92Zfr /IECJoiGLCyPOAucYWaHVnlHM7u64Gi3LNPdileAVbFLy3QL69SwxSmCy8CJW6oI4eQWm2XBrqW9 bbWtBJ84c+yriMIrWAutbbrOWTSwVaXbTtyTUxKFZFDBfo4DAR9QVYQWzjT49ZWDdRt19VboX/CZ /5upSd1uK/HIWA2uCFQsP4Eqz27FjDQeQONLVgsUPtOaRhGFfazthdYaMdfnyASmL7QxshaLFjiH yS6lsoHvwNb3yBvEsSOTk6HdmrORzFSzyTgEWgeHrwr4LjQwn2v4VlnFkXpXlDU9VWxXbXBAin2n 2JPFmTgbWqdvR7xbEDpiRkdnJI0QACcVC0SJ/WajS9sT1IBUmJjMvspycVPUTRAhNrSqR1GHy6C+ KUzqTHXBwHjWaEJgw00thVB0DORiHYycg5acIkxIxWArzIjJbXpH7klKa3Ek5mtGGYXnDIzkNcDL SN7CkwFeU/3g+b7jBUN6J+SX0JRfRmJQTRu1x37YQI5UJ4y8qDPSEVUCBKEKib1sHWUQE7kMOBpj zBdApYaED/Yqdq0F043oPDOtqTSpfrIZusV+uRokJul4J1mMCsKkpcjUGDvbLY7iymSu00e138Fb GNYUUQ5yH4+iP+lobAixjNKU3IXjWVWI/W6e1m3ZNBc3qI04wvz2y2u4SEjxmwwBKwTaCoj5JwlI hUgXCWA5lqAfqyQVKuuq85t9WWZ5vbmj+syz9lr8EtVeLwIWO46BDFOCLax9qCM0UhYZ2wcuADOS SMQwplFBlHQ5CKx1dov5uQnkPkkQBEMJTgB5ZC6i5PEiyk+kI+WhiAqtHaQhHagJHnxcokx1nkSF NzjhHWv3n6YdiirDEU1TX0SqiIwzWDo1LfWD0bHiynVcRfXxjCoI21ioBsTOQAAaxpYTNB2bNe0Z NB1JJ2wvYO+QUXIkmcQq50i7JSd6gsZ2t2KEpUZpPcfzhsdV6/8giLeJg8MroivOxZ8cdNpbJvCo rx71bdaM6bppikOuba9rz9DYKJTzcYh3XCd1yYWjhZhew3H03tG+E9zVDyInjg7xKGrS7xIRoY0j vZT2TNwCr+K22G/mmtc9gpfPq0qopBEYc3e2R6fsyZ2bDEtuT+fOeCkFWZ3vWRLUTZtNcVuZgKPC wPHUkOGTJKTU5X7jDk6PdCxhV9FNL44JpD66bfQ3VKT9y4t//SByWtvDYnIMi8Nzkv45nt87qIsO 0qFbeR+2dIGjEd+L0CNtPRC9Ep8vPxXUW9F9Z40HToeE2izPlgUN6tuvNgYNH34WOaDf1+xHlv87 mUXxF4dDbsU9Ih8HevYouvqyVbTyfCfwHlS0PNqzG52U6JOUiXvvCPeejNEEBvd+0t25A05W5JGf RlWvFuYxRINjRAOJRuqAKOyZcU3ctywsyAUj5S6KMht4JQ/OinyGkR1b/HsYPKYVRRd8NdLK96nh OJXQkcGQyi3pfsXSz0iyldDC424/Z+U8Oz8bvqtQjQ3YuHoCKnR89NQq9aXL8bFP5eYOgBHcSaEM lSHcfoVKoeG9brAw3LAsby/c+JEKu01Nxx3hPEy3Pih5f+9SxtUdM/InvIObtgGatvRjvi9xBRwW SedxTyUjJxzx09wwKettzu8HymNo9Ok9gbcpnTr7VNjk5fjWfCYt+hGKuwE99MlgPAQznaJq0mg2 P7+wSYIarUdcUF3qI0FxYfoUUUQHs764TxFFEiTJAZVn2rWLxsO5Fji/OX0qfqORfHSBZO9sGrhn Fzby0HF/Yr/wo8AJ/CN+cYiD/78QiNfXLRPNK6q6i82zYoPKpKq5D4FQuMdwdf76JPbwvnbAzfkV 78UB9g+orHG3Z8UfQtPWllEjb78savJUmiNJpdCM7o6kyG9znfOooIosVmB6Q6t0641IVKtMv085 v5tQaZeMDDlF3X39Scy4O0h5t7Y7Uc6u1cBz2Wn6DBwpms4KWxUneGnRZUqyXtk5T1t3oFLd8/CO bVuxCUTP1ZALuECJLfSOQ7rAJNZNVwKv22vPihGR5QyJtl7JOe7p/nxs7bTXLDsQpSDfFJbMSsq1 REpHURVR68ZbotdWjvg+YBy7JgWU5GU8VNWD16TB9Uc2Nx7+DicInMQTvqKTiBI+fZBOEDIXix/6 05QpmmnfP0zzda+dhgRyuMBDdykanO860js2f5RAo6lmHpqiWDJkQcV4h2qW4DB/XASWUOFNbLOd xAjc+wsUdG3eb5puLsR62qyhBxjoVhhIdGji+Qd09JCQ7QqTGN+Yv48y45cHw2aKCkOw230XdtpH LsbPCEaH+/yNVfNxFXf2dZOJX39xJ0nsNhTlw6bn2zbYinyxZp/e4uMSvEHcpLgi4H2HjPVegTbU Hm8I5m0nrqzqFLvy+TpfUuT4mVZTVPmoJjJsO9SmZlTkoiQacIwu1m7HPbQZvwxGB7p5ladfcVNo xMdWV7LXGZvR8gL97Yan1I66ZpupUR0ohSbwgPopdjB+kDCyA10h3ceca/yM4PD6SAE2ii7CXnvw H3+Y3jWRj95fjP+M37tJwwbTDkUKpDvCeIdpdSDvrTao5b9GlwEvDQplbmRzdHJlYW0NCmVuZG9i ag0KMzQgMCBvYmoNCjw8L1RpdGxlKP7/AEwAUwAgAG8AbgAgAFQATABTACAAYQBuAGQAIABEAFQA TABTACAAdABlAHIAbQBpAG4AbwBsAG8AZwB5ACAgEwAgAEYAbwBsAGwAbwB3AC0AdQBwACAAYwBv AG0AbQBlAG4AdABzACAAYQBuAGQAIABmAHUAcgB0AGgAZQByACAAcQB1AGUAcwB0AGkAbwBuAHMA IABmAG8AcgAgAGMAbABhAHIAaQBmAGkAYwBhAHQAaQBvAG4AIABcKABSAGUAZgA6ACAASQBFAFQA RgAgAE4AbwAuACAAMQAzADcAOQBcKQAgAFsAdABvACAASQBFAFQARgAsACAAMwBHAFAAUABdKSAv QXV0aG9yKElUVS1UIFN0dWR5IEdyb3VwIDE2KSAvS2V5d29yZHMoMy8xNikgL0NyZWF0b3Io/v8A TQBpAGMAcgBvAHMAbwBmAHQArgAgAFcAbwByAGQAIAAyADAAMQAzKSAvQ3JlYXRpb25EYXRlKEQ6 MjAxNTAzMDMxNTM4MzcrMDEnMDAnKSAvTW9kRGF0ZShEOjIwMTUwMzAzMTUzODM3KzAxJzAwJykg L1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEAMykgPj4N CmVuZG9iag0KNDQgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gMTcxL0ZpcnN0IDE0NTcvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAyNDIxPj4NCnN0cmVhbQ0KeJytWkuPGzcSvgfIf+Bx9xCoq/gG ggDZdYJsnDjGjIEcFjnIdq8967FkKBog+ff5qrta1sB8SO0Ag2m2msV6fVUki3RsBuPIeDIuGBqS cd6Qz8YlwxSMi4ZDNG4wlp3xeGRvPBuHbt4al4OQenTz3gSSpgkB37OJlI2PJubB+GQShgiDSXgL ZLKwzCZnNl7Y4l9whoijCRbPmDCKIbYYFPJwwvdkyDprIA2JECEbcpAEzMgPzkR5JgZbQ8HifcAz k4mgj9AmYvw0DCaCPolcGD8PEBP8MpilwfBg8T3jiXHwx2BkEuEp48AgjHGSN2wJ3x2eEBqisWMy yeKJwRLovY0mob/HC0g5wLZQnEMGPSwaYawM+gQTZdAlCA1LcuZkoBpnCAPT2AHj5GwsDfie8ITJ pW2ZoN0gToG5cjQWv+AHh0YSe1oDU8FAQ0ADlLCwsd5LHwwbJmqMG+LscxsZneE9GyE24bNNTjpj 5Aw2RBhZjEQEnw8knYGNIUpnD/xYdMavDhaFt4AlhqeIgQOGPYmBMYgoDgVyBumcBELicoDLQ20C vJyHcQACQNHJOPgUWagEh3HCAXAJ3xKDaUoiHZAmRoH8XkQheNCT2ADsPNsJNGjAC2QFsizwsWjA xGSBXgeoEvp5D9OIw72fqATRQgVJfAjSGZCN0J8Eu0k6O7BIogSU9Rm2JgdeGWgHMoF2MTM8HwbB KEIkiB0J/AKJLRFNgWEIgl8CC14lhqxoLFFkRWMANTgrDYkQcQ5GD95JA7EQxJYSBEFgjYgKUdwO cUMU4YHPkMQVgElIgJgwDlliDnEUJwkRYHGQ6EOERTEbBYkisSEiNbIIHyRO4CGClNEKLyA2Ohib ICXCy0qQIdasfMLIPksjIMoEdMBJjCQNi4ZENKI1ThADPJAhrMQmGiIYAg5xCi0kCCfTYfQ0ORcx l0RMBDDiUyAPKRNPoY3IQjSggZC1AkxAMU0SwhDJYTBCSCUv8EHMJS8KZolfcTeiLgUBL8ItRSed JVQlGGHilLw0pvQl6QHjZMk/UDIPPCUQNLJ8QjiK2RixmBnuZkRelhTKwEe2LKGFJwwBr2bYCVGI 2JbMGiWkIZWbgtxLfpsiV2JBAmOAec3XX2+eS8IezM3mdvN88+LPD+Pm9nh4eHX87n58v3n6XzP8 ZjbP3xgrfb755ssvZpJBSV48KdE4mQduioS+xYvW8ApVXrHFi9fwSjVeiBMlvCkSTiZW7VWwIv/c 4l+i8E3n2etJ3PVyyRQuenlb0wsZqMHSr2HpV7rCD7Oss0dmwYoih6tdcT1FbpklXE8Sr5dL1lFi iUBrDRpnS6b5kWvDBNuSPBVJuC151XmhmWbyGl7VNBOaaYaK+bPHrJpnToS3H7a7T0iX7punWPhc 6r/ZL2oy1UbWwxUJYjN7UDGtxnZajdXpoiN6rGI2NhMOFfNitG0pqxknhiazYkbtMatOET2TTIqr SEXGzQRCxVwcU1PYNNSYpTZYihmux2w1WKbPKlJR2DZmirk1td2Yqpg5EXYDOV2q4Cy/bCFrPFNT wWJaTLGtYDVP5KHFjItpscMsr52iZsVVpKKwzbmJi+vS3M7huTo55ebkxMUM2mNW9XnHMrPiKlKR cRMzXEykuePGKmakCNHiVsykHW5S4Vhpmxk1KlRZ3jZuislUiiZtgavIkcJLi18xn/b5rQWPqr+I VWbexk8xqUqlqC1xHUHURlBxmdnlR2shpOovYpUlbmOomJWlrNWWuI4hamLIFhNzn18VQ1Kcu2ym s8uSderzy79+vNn88vL/mCqm758OzMOlA3NBmp/udu/KK9h5Zyj1xs9XyZ4RtfcJlJXtoM/qZrrv jOr24SNpV3J3McZJs8AMrEXRqQZbE4ObK2Zbzpvs22pzdc38kbSrdrhY7VmHqYxcSw6nlez25f1Y LLbMzp5rHbpR1z2ebpp0o6CrYl026kJJVwU6Ay6Jfklni7MX7ZsSfn/35uEwbr69P/7j7vjw1f7+ 9T9NUeBiOrLNJG/LSd7SpT5J5bxAlbxgL11a21yQppoX7Ly8lsJ/DWYXq+SGskpcUyleOjBdpZLO TrY+n16uEl8IBzkUmLlq3rAaSFZh66pzZXtgV1yMdmiKS8oOTTE9dWiKS7MOTTFuOjTFBU6bRmd8 zlfQ0AoaXkFjizTUrie7CtFpr/5DufRxFtif0DYnLL+SYWww7CWxmQCBF86ITguD8pTlNYXpREM+ VQXoz110Xu6/yqlxBU0qm6ldVM4VIm775byu/Alt+wCrHEs9qnI09eVUN4YGjroF4xOO6GyVHKgN JK0Zq17TYe9nACnwSiBROT10iMrpoUNUCfFOnTlUqDqJITYyUafYXI6tPscGhOLFqeisVkmxk4u0 UK36TKf6nwGhuDYXUTlHdGayNVMmr5oz10yavCYseE1YcDksLlpvzMvA69YbV9HwChq7gsatoPEr aMIKmriCJhVpqF0JzhWiU2WtnHce1YIf08oNmQum2is58qNycI22utnhJdOd7bPy6Xy9nOm0jqz6 TBd+ahJckOly7FO3j2avIloTELQmIqgSEqeV0/ZwLEbsUjfTp9X6mdUynlueuut0unRxOv/onRxy Og+5ZReq4+l9EdILI7rGnq7HzUsf/R70e9DftXxDUX+PSqfHkJT0e9LvSb9rhYf0NI+SypdUPj3L oqTjZB0n6zhaEyI92aGs42QdZ0brdLdsfjp9en1qJfe8QDFb/MVhHG/2++PmZn8//rz9YOaNu3hm 3E1fjdYpxC2n6fz09dn4x/Hp+Odpw/I9xtrtj+Pmmfz7bvf648sLdH25/2NzO746bn4Yt6/Hw9wW mqX9n9393W68fbsVCeWHb3cYYXu82+/0/XC8+98Wjent1/3h3cv9/t3myf7Vw3vINP3y+9txPM7g +nn76rA/e//3W/w/e39yt73fvzn74fb+7vV41nfmg25vDtv3WlJTXZ89vP8dM59Z0Heq8/KpDmJP FRA33dWTlp/u6p38sdys00tvZul1fv1Kb0Y9vtajV2X0FoveL9FLHnr9Qu836M0DPdPX03Y9x9aj ZT301eNYPejUI0g93FtO3ZbDrOWQaTm6WY5UloOK5QDhrAy+1C7VYKz9eCkuL6WrJdyXopLC/FRU 0vG00np1OmCdoMT4/dygxHolSvfXhVyhzB5v4JZtVCOH6PjqI10zr80pqtTflliyJhDSJ1+WaL78 4i/dtdorDQplbmRzdHJlYW0NCmVuZG9iag0KMjA3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDIyND4+DQpzdHJlYW0NCnicXZDBasMwDIbvfgod20Nx0l1DYGsZ5LBuLNsDOLaS GRbZKM4hbz/ZCx1MYIP8/5/4LX3prh35BPqNg+0xwejJMS5hZYsw4ORJ1RU4b9PeldvOJiotcL8t CeeOxqCaBvS7iEviDQ6PLgx4VPqVHbKnCQ6fl176fo3xG2ekBJVqW3A4yqAXE29mRtAFO3VOdJ+2 kzB/jo8tIpxLX/+GscHhEo1FNjShaiqpFppnqVYhuX/6Tg2j/TKc3U+1uM9V/VDc+3vm8vfuoezK LHnKDkqQHMET3tcUQ8xUPj8JSW8rDQplbmRzdHJlYW0NCmVuZG9iag0KMjA4IDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDU5ODUzL0xlbmd0aDEgMjAxOTU2Pj4NCnN0cmVhbQ0K eJzsnQlgVNXZ/p977+z7kmSSTJKZyUy2CVmcsIQAYbKChECAqAmiJCyRTYyCVq0VsK5xo9VapVVx qVptZTJpNYjWtHaxi4UuVlwKqNiqVaG22rre7z3nJiBfpV/4/s6Xf+X8Juc523vOee8yd86ZzNyB BCCTRIeNjQtOnLE1u+cMyO+bgOwXZjQ2NS/znjEHckUjIN82o23ugv2umBnyCfuB71w+Y8FJ9T+9 deUVkPesAfwXzlrQ3nxmdKUB8nuvUq95s9sXzHx66cJWoODvgP30uQsqYhldF95NfVH/6GprmN1+ ke/S96l/G+UnntzY2rHgwbUeoKodcN+49MzuXm/vrR9Bumwztblz6Xnrg71v//VkSHfQeKbCnt4z zlwR7P4A0pXjAf3bZ3Sv60UayL/yD6k/1xlrLugpPv2aVyB9+0Zg4S9WLDvz/N7JzjOBxlchxe9b sbx72SvetHWAdA0bfwUVeHV2Gkv6MeUjK85cf35+j/1WGnsFEO5bvfyctdKd+AbkQCbZbFxz1tLu 9wpfjkLWddH+eujM7vN7M+Z6H6c6tv3Btd1nLi9Z+N41kIM3A4763rPWrVcjeIL8e4HV956zvHf1 2imLIF1XDHjrwI6Fvqrq9r/+7d7FzqnvmLLYbgLufHlCM4t3nts95YOrPrrGBdMEsjVzewbFxtDH TTjFhQ+uen+vC4dqhtGtZiX2hWiFwgtkuFCBk2kvXk3jMhRllfwo9DDpt+irqIMCLVa2okf2SHpZ NilGvV5WdPsQVYdwPmtlZg3bWxuCoEfQq1/9cbNUZQxJO+KQVFWl1vfqZ7Mthc4wWcrRBh4O92Ob 7mwk8ClQ3XwKWYfyQD3lYzw9mfY2MIvCFRRiFEIUqig0UZjNtxaYOdzPtk/rn6H/Ge0BLZ5Hwa8/ GSW6l1FumIwFfHfkUh7I4DYno9B4LUrILpfq28huPIspX6hbh1VUP4vSlcyWjpjn0BgnI3S08anv RdS2VLkWcyieS/Fc8reeylsp30zbGT20/ZNRargfs1k53/Z1KOI+XosW8nMetWN+TKc67yf6dx9t bMH/Dh3UA2Ptwyf55DkiEAgEAoFA8Fkj3aQ+MtY+jBbdn/5zfBUIBIKxRIL6iImCC+K6KRAIBAKB QCAQCAQCgUDw+cC+0ChJ0tcMPGOgyGigPw0YkKZZFSDb4J1fi2oqaXfa50/3OfLS2MdcntPqZ8/O nJ35tZzZFcCEa2fPno0J2YbZJwG3pMJlwyhsClIxsODzgPQ/m4xQkjovjjvoKjPWLggEAoFAIBD8 n6BAkRh6RZFkmgNl6t+wDuGfJhUmmNWPYYaF1MLVCiupDTb1I9i5OuAgdXJ1wal+CDdXD1ykXrjV D2iN5iFNh5c0A2mkPq6ZSCfNQiZpNun78COLNAfZpLlc85CjvocAckmDXEPII81HgDSMoPpPRBAi LUA+aSHCpEWk/0AxIqQlKCSNooi0FMWk41CivosyREnLUUpawbUS49R3cALKSGMoJ61CBel4VKp/ xwScQDoRMdJJXKtRRToZE0hrMFH9G6ZwnYpJpNNQTVrLdTpq1LcRxxTSOq71mEragGnqX9GIWtIm TCdtRpx0BurUg5jJ9UQ0kM5CI2kLmkhnc21Fs3oAczCDdC5OVN9CG+kBzMMsSs9HC+kCru1oJT0J c0hPxlz1TZzCtQNtpJ2YR7oQC0hPJX0Di9BOehpOIj2d62Kcov4FXegg7UYn6RKuS7GQdBkWqa9j OU4j7eF6Bk4nXYHFpCtJX8MqdJOuxhLSNVhKeibpq1iLZaRnoYe0F2eof8bZpK/iHKyg9DqsJF3P 9VysVv+E87CG0l/AmZQ+n+sFWEt6IXpJv4iz1VdwEdcv4RzSi7GOdAPWk27Euep+bMJ5pJfgC6Rf 5nopzie9DBeqL+NyfJH0Cq5X4iLSq/Al9SX04WLSq7GB9BpsJL0Wm9QXcR3X63EJ6WZcSvoVXKbu w1e53oDL1b24EVdQ+mu4kvQmXEUlX0cf6c24mvQWrltwrboH38B1lP4mrqf0rVxvw2bS2/EV0q34 qvpH3IEbSO/EjaR34Wukd3P9Fr6uvoB7cDPpvbiF9D6u38YW0vvxDfV5PIBbSb/D9bu4TX0OD+J2 0m1cE7hDfRb9uJPSSdxF6QGu38PdpN/HPaQP4V7Sh0l3YxD3kW7Ht0kf4boDD6jP4FF8h/QxfJf0 B1wfx4OkQ0iQ/hD96h/wI65PIEn6YwyQ/oT0afwU3yf9GR4ifRIPk/6c6y8wqP4ev8QjpL/CDtKn uP4aj6q/w048RroLPyD9DR5Xf4vfYojSv8MPKf17rk/jR6Q0Gukz+AnpbtLf4Fn8lPQ5/Iz0eTxJ +gJ+ru7CH/EL0j34JelervvwK9IX8Wt1J17CTtKXue7HLtJX8BvSP+G36q/xZ/yO9FX8nvQ1PE36 OulT+Av+QPoGdpO+iWdJ3+J6AM+pv8JBPE/6V7xA+jb+qP4Sf8MeSv8deyn9Dtd38SLpP/AS6T/x svoLvMf1fewn/QCvkH6IP5F+hD+rP8fHeJVUxWuk4pourunimv75u6Z/U1zTxTX9c39NH/c5vKYf ENd0cU0X8/T/D6/pz4zhNR10xYV9kTXDDEXRaf9N1ukARQfl8H++ddrbN3TxNxkMZpCd0WKyUDAa THTph1GrNxj0BoPOYCRzncVILfV6nVE/un9SHzOj6VSXioEFnwfk0ZsaU+fFcYdkzRhrFwQCgUAg EAhSjS2Tr620WeS/W1uZjUZtbWU1s7UVAatYWwn+4xBrqzFBtmWOtQsCgUAgEAgEqcaebfmXtZXO qEFzy+E1inlkbWWEidZWJouZra3s/LbkDL4Uo2aH1lYsl6q11WhmvGJtJTgKyuhNTanz4rhDtmeP tQsCgUAgEAgEqcaZZ6MllV6bReppOaTTQ2fSoLmlXrOywmq1mK0wmGBxWm1mm9VkscIx/CtYtNwx GU0masbWVjbW0mDUk6bmjf/RzHjF2kpwFI5hbWVOnRfHHbIzb6xdEAgEAoFAIEg1riBfW2mzyH+3 trJZzDa+tnLZaG1lM9Paynlo9mliayv9v66tUvLGv1hbCf4fOIa1lSV1Xhx3yK7gWLsgEAgEAoFA kGrc+fbDayv2Kw46A/RmDVo5DX+ozwqbzWp1wGCG1WWzW+20trLBdWj2aTLTg5qRucHBWpqMBnOq 1laj+W9CSj6MKPg8INZWY4Lszh9rFwQCgUAgEAhSjbfQCb1eb+UZtrbS09rKokFzy+H/W9nhcNht ThgtsHkcTpvTYbXb4QW7VSDDYjFbzAaLhcz1TtbSZDJYzCn6UNVoZrz6VAws+DxwDP/StKXOi+MO 2Vs41i4IBAKBQCAQpJr0qIvWVkZtFmk00qrECINVA9aRL0w54XQ6HC4YrXB4nS6Hy2mzO9lPk9u1 eqvVYrUYrVa2tnKzliYT5VL0xr91FDZibSU4CsewtrKnzovjDiU9OtYuCAQCgUAgEKSazEovDAaj NotkX5EymGC0acA28qE+N9xul9MDsw0un9vr9LrtTjd8bNHFYR8TtBptdlqKGb12mx1Ws8luTdEb /6PpVNw9W3AUjmHZ7UydF8cdSmblWLsgEAgEAoFAkGr8E9NhNJq1WaTZTKsSM0wODThGPtTnRVqa x50OiwOerLR0d3qa05OGHLCvXDHYxwRtZruTfcUqw+lwwmY1Ox0peuPfMQobcfdswVE4hrWVO3Ve HHco/olj7YJAIBAIBAJBqsmt8bG1lYtnLBawr1SZnBpwjnyoLw3p6V5PBixOeHPSfZ6MdJcnHf5D s0+Hy+6yW5wutrbKdDlctLayuByjWwYdM6P5b4JYWwmOwjHc5sSTOi+OO3S5NWPtgkAgEAgEAkGq CcazYDJZtVkk+4qUyQqzSwOuke82+eDzpadlwupCesCXlZbl86T7EATStXqXx+Fx2FwedvsKv8fl gcNm9bhS9KEq1yhsxC8TCY7CMayt0lLnxXGHLhgfaxcEAoFAIBAIUk2oPvtf11ZuDbgPr60yMzPS smB3IyOYmZ2WlenJyGRrqwyt3uVxepxW9/Dayu2B0271uEe3DDpmRvNJLbG2EhyFY/gqnlhbfXbo QvVj7YJAIBAIBAJBqimYlQuz2ar9/8lmA7tdhcWrAe/IfSP88PuzfLmwe5EV8ef6cv3pWX4UAJla vTfdle6ye9MtgCU33ZMOl8OW7knRh6q8o7ARv0wkOArHsLbypc6L4w59wayxdkEgEAgEAoEg1UTb Q7BaHdos0uEArA7Y0jWQPvKFqTzk5eVkheBKR05xXigrP8+Xk4co2O0sGOk+r8/rSPfRUsyW70vz wetyZKQd+sjgZ8toOhW/TCQ4CsfwVbzs1Hlx3KGPto+1CwKBQCAQCASppnxRBDabU5tFOp20KnHC 7tOAb+QLUyGEQgF/BB4fAqWhiD8Syg6EUM4WXZyMrLSsNIcvk62tIpm+LKR5nJm+FL3xP5pOxS8T CY7CMXxcNCd1Xhx3GMoXjbULAoFAIBAIBKkmtqwIdrtbm0W63WBfqXJkaSBr5LtNEUQiobwieLMQ qowU5RVFckIRxMC+csXIysnIyXBl5bDbrpfkZOUg3evOyaLyVLg8mk5TcoNCweeBY/i4aCB1Xhx3 GGLLxtoFgUAgEAgEglQzcU0UDodH+/+Tx0OrEg+cfg34R74wVYSiokioBOl+RKqKoqFoUV6kCBOA sFbvz83MzXT7c52AszQ3OxeZ6Z5cP/ueVgoYTafiV18FR8E6etNQ6rw47jBOXDPWLggEAoFAIBCk mpr1ZXA6vUGe8XppVeKFK1cDuSP3jYgiGi2KlMGXi6LqaFmkLBosiqIGKNTqc4PZwey03IALcFUG coLI9nkDuVSeCpdH06krFQMLPg8cw1fxIqnz4rjDWLN+rF0QCAQCgUAgSDUNl4+H2+0r4JmMDMCd AW++BvJH7rFeicrKspLxyM5H2fTK8SXjKwvKKlEPjNPq8wvyCvJ8+QW0FPNOLMgvQF52RkGIylPh 8mg6Hc29BAXHJcfwVbyS1Hlx3GFquHysXRAIBAKBQCBINS031cDrzYryTFYW2Feq0gs1UDjy3aaJ mDgxVl6D3ELEZk6sKZ8yMRqbiFnACVp9QUmoJJRVWJIOpE8tKShBKDerpODQv7U+W0bTaUpuUCj4 PHAMHxctT50Xxx3mlpvG2gWBQCAQCASCVLPgnjqkp/u1WWRODq1KcuCLaiA6cqe0qZg6dVJVHMEo JrVNrauKTy2fNBULwL5yxYiWF5QX5ETL2a0BG8qj5SgI5pRH2WcJU8BoOhW/TCQ4Cq7Rm1alzInj D8uCe8baBYFAIBAIBIJUs2hwJny+gDaLDARoVRJAdrkGykfulFaP+vppk2cgUo5pp9TPnDyzvmpa PRaxRRenvKqkqiRYXpUNZLdWlVehJBKoKk/RG/+j6VT8MpHgKBzD71lXp86L4w7bosGxdkEgEAgE AoEg1Sx7cg6yskLaLDIUArJCyIlpIDZyp7SZmDmzYWorimJoOH3mnKlzZlY3zMQytujixKrHVY/L j1XnADnzq2PVGFcUqo6B3aX9s2c0nYpfJhIchbTRm05LnRfHHfZlT461CwKBQCAQCAT/ByjDIQcS z79AOUpJL0GHIbD7VQQpZUM+SlCGiahGDeowA7NwEk7BQqxEL87DBdiK70onGOJBr6qC/fJVMbWs GLZuwImYza27sQbnHGmtvvw/PJbS4+4PE/tuG/Zw1EgGHGoiyTIg/3cD2nSdnietNsDpgseblp7h y8yCf+SGhBEUFhWXRDGuDBWVJ8Sqxk+YOIlt1cjUu7GpecbME2e1zAbmts2bvwAnnXxKRyfwmf9W qsK1fzSmT38i/R9/FOP1J7XHp9dOmzqlZnL1pAnjq2InVFaUl40rjZYUFxUWRML5oWAgLzfHn52V 6ctIT/N63C6nw26zWswmo0GvU2QJ45rCzV3BRGFXQlcYnjmzjOXD3VTQ/YmCrkSQipqPtEkEu7hZ 8EjLOFn2/DfLuGYZP2QpuYJTMbVsXLApHEw81RgODkoL53VQ+trGcGcw8SZPt/L0Zp62UzoUogbB pswVjcGE1BVsSjSft6KvqauRuuu3WhrCDcstZePQb7FS0kqphC/c2y/5aiWekH1NNf0yTHZyKpEd bmxKZIUbmQcJpaCpe1mibV5HU6M/FOosG5eQGpaGlyQQrk84S7kJGvgwCUNDwsiHCa5kW4Org/3j hvquGXRhSVepbVl4WfeijoTS3cnGcJfSuI0J34X7Mw9nqXNPQ8cVn6z1K31NmSuDLNvXd0UwsXVe xydrQ0w7O6kPaisXNHf1NdPQ19BObFkQpNHkyzo7EtJlNGSQbQnbKm37loebWEnXqmDCHK4Pr+hb 1UWHJrsvgfkXhJLZ2fHt6j5kNwX72jvCocR0f7izuzGnPw198y8YyIoHs46sKRvX73JrO7bf4RxO 2OyfTCw/VMdT3JylWuYf2rMS8yh8Ip0QieDSIHnSEaZtqmayvBp9S6vJjOiUqFViGR2RlQlzQ1ef q4aVs/YJfYErHOx7B3QGhN9848iS7uESQ4HrHbAkO08OnWpUP5JOlJYmolF2ihgb6JiSj7U8P6Fs 3HmD8u3hXleQItp9aKN9291ZU0G7PxRiB/jqwTiWUCaxcV6Hlg9iiT+JeEVpZ0LuYjVDIzXpJ7Ga jSM1h5p3helM/h5/tqcnTIWH/pyuDG/TipqElPFvqpdr9S0Lwi3zFnYEm/q6hvdtS/sROa2++lDd cCrhbehQ/PJwSvYrvJZOykWHjFmmw5bQFdCfgZ/UywaNJjoreYkUbE64umZq2mkJhUbZaFA9yFrx 6HCzYTcTNaVH5qcckT/CPVufQg7rCuWW9oV9fZYj6prpCtTX1xwONvd19XUPqhuXhIOucN92pUgp 6utt6ho5ooPqI1f7E83XdNJGrJBq6GyVUd8flq6c1x+XrlywsGO7i67xV7Z3JGVJbuiq7+yPUF3H 9iBddHmpfKiU5YIshxaJzvSkbOJV/u1xYCOv1fECnl86KIGXmUbKJCwdlLUyFy8j2BO9ob3jk4eQ Py86y+hVrj04qLMN2BwxFie9vtigzjpQHAw461w6DzZSkOEknU5hMQWFq4S4zpM8vyo+SNE5WrRW i1ZpUXtV/FEynIUqdUjnGfBlxljxgMUW28hik5nl3cmFVfE6s86Nk7mdGwu0ONlWxatbWS9uevnk pQONTVqreq24dti4pipQF6F8kEKcQi+FbRQOUjCQ925UUNhMQaWg4zlmt4HC9RS2UtjHbHlvpipn nV/nohoX33YXAhQqKCjo0plp2xNcnToT7RUT5lK4XWeETmdJYk1gO3WiDDRxT5WB0nIeJ4tLYrwi mZ0Te4xeKW9BEQJUICUz/LwGyfr64cTEai0xEC2L7a2z6IADFGQddBJNE3irgeLy2MHHKS8pH8Mp SaxU+XDAlUajKR8NOL2xeJ1LeQ9tFGQklH4MUZBxlvIONlCQyXxbsuwENpCybcDiiLnI/gCCFDZS ULCVVOL5OAVmf2DAm8G6/3PS6ebt9iYrx2uJAVdmrK0uTXmB/Pm58luEEVBeojiP4p9RnEvxT5Un Yed+3j3gdMU20nh3kfldygU0Uwoo31IuRIzi+5SLaUrIzJ5NOrRxnk0WR2N1FuVe5SJusk45G+Mp XqOsTsYCwR3K3ex8VN4YMFuZf28kXemxx5TXlNVII6v9ZOULOB9T1qKCAtuSwQGzPba5zqYM0mYO 0m4JkI8SbucaV36bpI5ovG8rG5FBdTuVTUin+H7lkmR6YGiH8g9u9i7rhca7k84YFg3YHbGhOrNy JztDlLdpj7/NR/v7QGF1DHWFyjWopCDTTn2ZUi9TyqW8Ram36DC9RYfmLTo0b5EXb9FJC+VNqnmT bCqUPehVnsdmCrdTWkddXpCkPbidJyLFse3Kl5SLaE+4dtC+k6j04gGzg3l2UdLj5WYXsSf49MeU ZzCXgkzO72bPyLN2KNfxTdk8kOlnDX6fNNto131ROxbU8EJ2DB5TNiqX8D2xie+BxA8oS+e/8mXe WB2wuWMb6Oi3U/Ys0usp7KJwgIKOzNppG9qxmIJC5m0DDmfMuUNZyBufmHRUBR5TZtKmz+R7a2Yy PZ/7PGM4oXMm/XmxH7AEyuhFLKZz6AzJisC8HUoLnT9zlTnJZQHyfV6S+mUN5wxU18Qqdyhz+L6Y kwyEteKkN4snmpNm7bxqGLC4mSeN3LA0aXLw4tLhp6QSHUjzxQJ0ntbwra3iq5hJdPgm0aGZRM+T Kn4wYgMuD539y5QY36IYuihspZCgoKNjHCPzGB3jGPbxEqcykTZ3IlQKCh3biThIgS41ygmYTuF6 Co9T2EdBz0u7KMhUXkkjdJFupiBTjxWUd5HGKXRR2EhhK4UhCgcpGLFTKaNxysi6knQjhQSFvRR0 dKzGkR/jqM6jBPGRif3Q7Ab5lniNtAEbpA3yBmWDboN+g2uD2xSfUDAuFl/FpJxJMcmkLnOveaNZ qTTHzW1mxWUOmuVBdShprKmiKO4x1FQ91/p66/utimfSZsNmo7yzzia5sZfCAQoKdkouyrko54pf oeys3Vt7oFbZ2bq39UCrsnPP3j0H9ig7y/aWHShT4q3+mtikxdJZ0gbpekkXkCqk6dJcSbdYOUvZ oFyv6AJKhTKdzgVdl7XXutGqVFrj1jar4rIGrfJm61Zrwjpk3WXVJwxDhl2GfYaDBn2bocvQa9ho 2GzYajAEjBXG6ca4QXewrkF+nnbqVtIEBRkbSTfzlIvXDJHu4vnNPN9F2svzcdI2ngqTVrIUhTD1 9RzZbSTdTIHZsXyYtJLlKYTp6v4slfWSbqYgy8/Gc/IrI/GI7IoEIzIi0sGItCuyLyInIkMReaiu Rt7NvdxNXu7mXu6mlrv52LupX0pRCJO3z3C7Z8juGW73DNmx1KeVdZH28lSctI2nwqSVLCU/kwxP ctb55G9Qj4tJb6ewl4KCCtLpFM7iuQCzkL9BGpe3DBSNoxd8eUuykK6RFOVrUZ4W5fBoICs7trjO KW+hLrdQl1uoE5YLUJjOcuqQfEuykdnekpymRTVVe+sm0asoc+UWbKMgYy7p7TxVQTqdp7ZxG+eh fIJ0H0/1km491G4xTwVIR9oq8hZ63EIpp3whlV4Yt8r8LqTwuE2eQfmR5EpPYFD+XrLYRdGAFiVZ VOeVFdr3duktrg9yvZ3rjVxP4eqMW8P298L2n4Tt94btdRZ5FiJUfJDra1xXxR0R+6sR+08j9rsi 9jsj9h3Sy8inilA8O9/+Sr79j/n2h/Pt9+fbb8i3L8q3z8u3z85nXRUjCLucy1Q6nWtO3Be0fxi0 vxi0/zJofzJovyNo7wzaa4JkLr1Nr6d26Ztcv851wsPj7YHx9tzx9kdkujJJpyadMO+QZelU2BVL MlobGFTMPJJDydYCinKSrXUU+ZOt8ynKTraeQ5E32XpDoM4sO6V+mqwEZIfUb2KxLRndRNVWLTIl o6dTpE9GJwcGpY+T0TBFHyR7cil6P9mTR9G7yZ7xFL3Dokelv6FHpm6kvyZ7bqPupddRzLqV/oxC +QGKB5Ot08n6YW106XuolQqomJZVzAvpO8koOSfdl4wWU3RvMhqh6B4tuisZDVB0R7KnnKLbkj03 UHRrsmc/RVuSxWtYf7egmPdzMwp5vC7Z6qfqs5OtrIfeZGsFRWclWydQtDpZ+xRFK5O1+1nTM6R+ ic5sqQdR7ml3sidK1YuHN+Q0FPPqRZjAe56RbGW7pJl1UmeXmoY3pFFqYHM+qV7q573Ek9FKMqtN RgspmqbtuanJnlKKqpPFtI+lScni22jPTRweoIQdn0elCLnBOgonow+QUSDZU0JRXrKniSI/a0lO eYdH9aCWO+VORpmVKxkNBn4gWdHDe7SgUNryUOAj6veD2kHp5GTg/figSUoG/lFM0UOBN1qXBP7S Okgz3sDr9BR+4KHAXjLdU0vJuDXwQnR/4Pme/MAvomQR9wd+Hi0PPFF4QWCweEdgoDUv0E+OJXqW BLb18B4eLKRmycB9xYOyRK239swO3BwtDXy9cJD58FUyvoKNQR1dFr0gcEnhpsC5dCqsb70qsC6a G+gtPj2wqpgN5AusjM4PrKANOYPaLO85I9AdvSHQNYF7fHr0qcCCCXwbWnr4Fp1Yyytm9swPNJMH VDGdVZAHU+i8jFHT8gk72D6imUrDwFOBkyY9KtOrsLSRwjnxcuNjxouNS4ztxnp6vSkyFhhDxjxj msljcpkcJpvJYjKZDCadSTbBBDltUN0XL2VvnaYZXCwy6JjqeNolM2XvstKcRJZMMi20El6lRW5Z UJ+YVNoyaFTnJ6pLWxKmtlM7+iXpuk6pJTG0FC1Lgol3F4QHJQutgvXheinhaUFLe30mGSfkK2k5 2d4xKKmsxWV+9tbSdkjSuMuu9bO4+bJrOzuRcd70zOmeWvfk5sZPka5hbWosPUxmaekRudzETS0L OhL353YmYiyh5na2JErY20/b5TXyqqbG7fJqFnV2bJdWyGua5rNyaUVjJ5lN4WaolVeTGVpZRGby ItQyMypf9AkzqZ+KG/trazWjuVI/M6InzVxutFAzavikkXK11MCNGpSrudFt2oBR8oMGjLOIzPRr EOUDRvVruFkmM+svLKSeegqZSX+skAz6C2O8et7h6mKt+rta9XdZ9aAkHa6fUKh5W4xCPkKhXEw2 pWPI8vr/RSNpYNp5azvY24Zd4ablFLoSV5+3IjOxcUkw2L/2vOH3Ewu7lixdweLu5YnzwssbE2vD jcH+aR2fUt3BqqeFG/vR0dTe0d8RX96YnBaf1hTubuwcmLOp+uwjxrrq0FjVmz6ls02ss2o21pyz P6X6bFY9h411NhvrbDbWnPgcPlbL/Hqppa2j34T6zoZFWjwgWy30bOnyhzrrM1y9tfypMyWUebH/ ER2k+2At7UzYwvUJOwVWVVZXVseq6CnNqhzsreHhqsyLp4T8j0j3DVe5qNgdrsf6zKaVjfS3jli/ /lyC9vG6ddq+ztQq1pc28XoyWE+p9RyypDQL63jpcP16nHuY0lLNFutKGzr6W1ubMlc2+mkSP8Dm 3aWd61Baqg1YWgoak7aaT/Qz+ETfasioerr1ldZ3WpUhPsPfRWEfn+EP0ex+F4V9NMPPU4Zqd9Xu q1WGWne17iPbPbv27NujDJXtKttXpkwa9oAN1SmRh4cf55auO5cVl0p8a/l2M0fIaUqwrR7ZDet4 xXq+YwitnDctpY5KDzUvPZxYp1Wey5topesOn8NUwbpff27pvzJcSpdg/XUI6GfzkKPcyH67WH2R wn4Kr348S/1Qvxrhj1ep+xQvXa4jWhimAJfSRO9V3ITHcRp+SfPGJqkcHdBJmciiC/tktNDu80FP L6/FNGtsQRvS6Vr/imTHNpyA16VmbKIX57n4Js0L59AivQ5fwVZphvoaNuF30ko8QK3vk+Iowmxp proX89CmPiyx76RNwdexRXLQi9VsySKF1T3UwzpcgUfwB6hYiJv1W6mXNszHWvVhLMJvpIXSqWoO TsRaXIybcQcew37pSmlIp1e7MAFLcI5klLxSsXKJeh+q9bvN31d/rO6Ci+zvoF7fkEt1zepbiONV naSuoNPDiyp6rMWdeAgvSJnSBKUBDpp+LqJ9cRG2KcXk40xcRdv2iPRFaZviUO+mrZmEpdhAp9T5 0pAc0u/WH1QvhIe2bzx52oe78UM8gb9Qb81Su3Lmx9PVOfQaaUIpmmikS3E5HqQ99yN6/FhySiHp ROr5h9Ie6UVlrfIn6vlevIl38U+pWFopXSxPly/Rxz7apH4fhbSFcerjRJyCNfiOVCjFpVOp7Tfl L8gX01L5IeUFXbHugFqtPgEDaEmOS3A/bdev8Ts8Q8erWWqV/iBfrAzoL1e/SP5WYAVtxaX4Frbj HUkvmSWblCYFpSppEm3ZF6Uh6UU5Vw7LHcoSZZv+GvUC9VqE6Fw5Dcup5Sp8GZfhYezES/gL3pSy qWUFtZwutUnX0hL5x/JO5RRlkXKTLq67SfeA7ke6D/Vu/Y8+/s3H+2ivs34q0UqP09CDC2lfD9Lj CTwnKZJfyqOepkmzqKfFUo90kbRZ+pp0l3SP9JD0M2nXf/H1JfBRVFm/99zaeu/qfU93V3d1J+ls ZCMNgRSrgASCC5u0LCKLqBBUIiifuCLofDCiAqIjM4O4zQwoW+MGg4wrCm5PP+VTdBidxYzOm8jM CKm8c6uDZr73fi/163tvVd+unHvO+Z9z/rcrAH+Cb+BfNEjvpffT5+nv6HF6gotxldxo7lHuGJ/k P+bPSnN7Y/oh/Zs+a1+ur6FvY9/DfZ/0dRtWiKLHt5FR6F1LyBpc/UbyAHkEdb6XvEU+QL/7zDhO k2/RBmdBRG8KoUQKpCALVbi6aTAdumA9bIId8Ap8DqfhHCXURhU8KmkznUBn0dvo1/QcZ+FS3Aju Rm4z9y73Pb9SqMfjaWGf8K14WlJNx85t6/1UJ/pi/UF9W18T+qKInudBzDWSkehzE9DK80knHsvJ CtKFOlqFGn8YPWcXeZY8T14jx1D3x8kn5KQhLzv+hJboIb1EB4r2FMCER0n2OrTMKPSWOXAl2rZ0 3AS3wTrYgsc2+Bn8HPX7DrwL78Fn8Hv4DtdEaDUdQS/AFXXQy2gBj9n0CnorvYfuxeNt+r/oJ/QL +j0ncy4uzmW5MdxC7m5uPbeb28u9z33AZ/gR/Dh+Cf8q/w6ufJwwXpgtXCHcI/xc+KVwRHhDOC30 iZvEX4hF8Y+SRWqWOrAsXSc9KT0vnZT6TFn0p3aUfuD/MrAJLuNr6Uboo0Vc90v0eu5Nej88PfAb ZGE9SjAfyXSRe5E+cvNG7gvuV/Q2QvjRxtvDMIodIy+QY8J7vE/4I3mVhslfMR7ez82lLyHVDkIz N5S/kz+GUWclyvlL+hmV6C6c8Re0xmxyKYTI/+ankm9Q/8eF9ajTsfRTeJq+gtS5QD4iO+jzBEk9 uRIGo3TzyT7yPfkpHOQSsB/97hZygnxNTg34wr62dyRtE4N0hTgELXQQpvS9Siv6/oKo/xzuJJ9w 36PvT4VJUEt2kt+j1T+ARojzOh8h72DkKyPb0Gu/InsQg2/waUTQd+Qg10hm8qfQ5rW9r+ujheu5 2+EMHYHmDBiRezKLxhiDt2CsYnHUQXahJ2AUMRD9F/IWKKjF98SPyUNkA3mO8xGVe4yuoX3ca3yC 3EdOcRPxt67G+BSFRrzTNWQxriPR96W+A+9wFWkhLTAPZpLR+M44UtZ3DUq+E2OR1jerb6swQ8iR t2Ei+MghjF5B1OKDglnvxpl7EYefkHFwD9mjzyeHMa8EQYV69KZuYYWwUXhK2Cu8JLwlDiI3Imq3 oRW/ID2YNRJwBeriz+Qf6OsjET1ViJ8RKMU4zGFX0xnci2QUhMkyjIHlGLdHog5moiWvw7vcRu5F PD2GOeRt8i3IyHhfIh8hcgKI8yvw95vwPheSS9Hq15GdGB1vhz14ZT4pI5Wop+/BAS30evx9LM4+ iHH2MMp0knyJkaPPkKsKhiJNnor3+gfDMv6GZtKBfID07Sd5zJSjuWPkDySN2XUkYnQHfm4O+oaD xEhe+D1QUqVP6muhi7kXwY/Z0IFedQlm9mHQiVI4cR29xAeTSZN+Ad7taYxlHcJjmH1zmBl81MdP Ey5FuT/GTPY2Wd43HR6SGAIoRNG6UYE9YiKRkXspvCxKRc6keYjAv8wRi8S/DCRkEoWXKfcCjCBm NMJUEszJZ1p7WyfJPa3tva2kDcfyOWwG1SVdSZeKDUR5ci7BHT6nCeQsSfCH2RM4u/r+AKz2kDHq /seLdDcuLUw3kTJ6356YGUiRC2lh1/iAdWPZ9jJaFgiEbd7xYaKF4o3kCICxhYtjsDnD8TANVzlt cRu1FcGjmQ+JIIZiHx0P5lCmQnt34XTBnc/Vdufk7knymCtHf1kgbe29X7YNqoOxo8eOHj8aUpls NtPU2NxQ7/d5JUnkWC+mFHYNrq6Sso21syaMm13fFFVGzZ49atTsy+Hg8l98fPTS9stnj5944uPr 9XdmjzbemWNs4r3DPYcrs6HHzdYi1OT2NlJTJNZIwMLbHQEXAUl0+B3UUYRVWsjrlcC1dmng0QAN hCOWtQke+FD4R/EnyWcK7b2oV7m705XPg8udz7MXio9FZ4r7UfB/PykMWuSdNmzspCCsqb8yOGP4 BReG6Ttw64X54dMua6q+XL8V1kyvGzL98kGpRYynX6QvoPeh1G7SoZWvdRxw0sH8Fnq/+Qn6mFmA I4SzHbF77DYbzq3zOiW2J81JRfqAZtZkkKd6lj7IHKHQXUBvkPEgbd1t3YPqSAEK4BMlPFyyO+AP +DLEJRN636JBozN10y5sLPxNfwYmCUtqRo+Y+ZNd+iv6R3rxyrFN9VPg74gQDVhmDqFsMwzZLtKU Zn6tcLez6OQfpFvNO+mTZh6l86B06LWylOiXyjWZSeUlADabvc5z0TqUrscQzBBygHSepubBeLhk ms1km/xMutCiQaOyJeFgsv6MvqBmzIiZ9+6GIVh3XWAIp9v1F/Tf6qxkJiP1rfAiNLDaT3P9i4Jk SHTMPd5m4S/0FWGsZoWGuBOcI4K//gkTo9DT240C9HSDyzAjE6G5qTGbSSlSv9cZNhQXXL9YQne0 xXJDp82/YOqqX+tbq+ofvdhlNkmuWcNHzr/z+g2fMgnqYSldSYcjbsOajX5CSFiAEM9+2ST5tPwl qW3HtUKyKUlX9h6kF8DS48b+TN/ntA21ypFmLYaKaqOcl2KNzwFQK7eL3WQXreJfGMNkZm7YjlK3 trWuFWpyq+WjeEdMJLRNH7UGDglLvl8hrGe4ntB3mtsnLGLRBiZoIXNEjIuquSIgBSO+hE8NVpgl E3SZYkWwPOsWstjtEe3uQJGzaCrR0plGouVqsGloxmbosEYNo9l2trJqt1OJYyXFZjo22MGueXyN 9lDVd39jyzyTW45IHzVdCyhaOtuosJso7CYKu8lSBToZHZqBE41BezfbPAogh8TJAcYlcb7R40dY vw8/NSfQ/6l+bxm1UpsHlYlkPElFp0N2UDGdUlNUtNosNrPNZONFn9/rp2IoGA5GgpxIsWDlgRMr cxU5Kpa5lHkkI2ET9QTmQbmATdIRmwcpW3YeCfpxlAMcGbsTrOn/NxkrbyWd0AleyUHRN9BH0T8G NzMPCfgFmZ0zt0F0Bfz+hnp0ZW5fXrnuvqnzfjasKpkb3nDi+hVv1Y3Sj/GWTKglF1LDXmdLTX2o UqQ739x99fop8wujO7f+8r8Pbv3lz+9+/iTMH3rPoEQw9UzvN/qpeRfUJVpuYL6yFpPCFWjVALn9 BeKAX0MTMcFj+5XZ0lKJwgi7cUWCfyEJ9MNjxAn/wATURPyUag6niQgmyYYX45hBixwGDIejw7nU ucvJyQiLUNDxEiXERF8hQRqAz4yMcpoFv0Jru9xbYDmlzZ3/rvscfJeDQg4dz+XFtTb4kk0N9Ygc V2OG6SCr0m3+se3x3ub0tAlh96BEw3g3/F1YdPbp1WOqVLV87Bp66PLaZCJ92sAMruhhXFGU/FFL 301/Q3/FcVnbAxy1WC1WIELEvd2/10/9UYoyWaymaBHm7HfXBnZjmC6C8iy4TcxdrPZGU5FL73UI YOOK0KNFiCALVDjpfs8ZhUNRiIbLnACHACAUew75wUZioLLQiXGos72nt3CatLV1s00LzWPS/PY2 kxZwYBNyYmPPG/6HShg1q99fcYbhpzjJ6COy0T8bdbUZc0+7jPTA0kTBlXfn8VR+nQUZUkgmm4i7 qdHQleFALE+IkEQdDm7gOs59AUsfue3yhy5Vm09uXPjUnAlX6r8C9eoRlUraD/ugZuPiex6yHy7O eXz8nesO6vvcuTFMj8m+33PrUY85clyLS86Ac1FuZe5O353+bZ4H/E+6d/qf81iro21R6jVBETBd sH+PEc2dtI4wwxwkXUl6jGTo2yRMTLgcu6vR0Kvbhz19e7/mEMJ24i1Sz94EgGB5Dh4gVgjvLyup GYPBAdd7pEKuoBUsMLicAQiEq51lUMbCQ1moaoDOc6jzTowSPZikenpd+dpQuLuVBNvawt25nNx7 Wj7tztcWut35krqgaTgdqC0MyBJTGUkq/dWCgTiM3BmoXT5dWznz3nnquM/X/+TApZfdcJP+lq7/ anJ+ZC4Zk1++dMJVh+kTqWT+htaLu+63P/7Er6678J6m/OP/8b7+Yb68rWaEw/ToDTPXfYWKaUC/ /DXq00LsZKsWbLMj5waO8FQyWwST3UZ4k91utRZhliYT8KIJrFhPmKx24MnzcI4IxEJlzWYCwWSz E5NsoqbnOTPeWII5WrCWb+Opk4/zlA87CVMRCTlKEfQ0S9+F9p5WA3FtmC3PtPbXG+782pocjzHf 6XSWdOOBBleDL4UFXnJw0tVA71h18816t+6bi+y3j1t8bvNx/QTUHacB9JAxmBH2CBOJAh1ajUME syVkKSflHO+1+CK+KNcijhcPCJxVACx/onxMxjbGQ5jnuNIqFVylgtEfiCIbCcC8102wSirCN/vd Ce4QR3GisgcIHy7CQ5rF6Yl7qOekzU6L9LU98I6JPE9FopAYfKeFNVOHabuJM4XT8jsbFFCYDpRQ qqSDHswip9FJujFt9iAwuwvdWM8y8GleTkOIcRrijWMI5RhWDcTpnQY4efRanMH3g5LvB6nR41TW P+u1GR/JzegusA9pZQq7qcJuqrCbKuymiobTFM1tLc3NzehPuMTlDjBzBNA/SWcBlhc6IcklJZ49 7SzyqfNeiXkhUPLLdFKRkIjcdGXvnxtgxnNb/1PXH9o5Y/iIXLZj7rCqePai6/Ttek+kWZio62vt j97+8upvbh1e1ZIbmRhdKdtuvGT3SfYtzkS03xEj9mcR42YvBwv8K/zUUuz7p+bD2raSS/te9XFt JkEJBuOCOeN7kb6B9cQDyCnM8NC+TEYmQhwT/V7ZrpzEGv3zPSRcESzS1/eVincGXKuXGcIbKj9v CMSpUXOcYaUShv/abrn7tOGLzCONZFwTUS2edCYaiUWo6FYdGdWizIMyV3geSThxlLJm5kHEE59H knZsyPnEmqvM3XorKWAuwdLUQSWs/krwZsUXQt6dBtHndZeUKLP8yh3Z98ktqarYiJFb3rz2jetW v9/1CWzSXzc11SSra8aNyo0vFxZFa356fGuZ2fvfh+46tWodmLadhnV/6r12vbZe1xvVJTvAu3g0 1jHjUJtF4QrUZhrrtnFaOWfjPS6b1zPGtiizMiOpMDgwtb6Lv53eEXrIvi39lP2pdNG032t7RmSP SWoBM+dzVg5SIjY1SGyNDazj4+zbYFZP1WD3jGg3CpYf3CWi1eZIG2m0cRfbOtQrbNfZbieCarPb 64PpNLE5g+oghfgiahCDi+iuh3SaJWmfvd6LUyDNKfX2QU57Gup5ccCveVa0R/ozYKTIES3mqxt0 UuM6uO0cx4UbS8XaSWddpWa2N1ayGY4NZjAzM5tDDczMrGjrzrFojIjr6c0ZUpeELlGctY6a3FrH 6h8837jozksOuXWtQz56lJXvM/o5hv9HyjY482MJLZ2vrNGifg5ZCOtL6KDPbVj6j/dfP3nL/T+/ 7KvXj7zT+bKabqmcMOryxdVxuzdRN6N2/HyqL953w47fv7Lhmh2jb3p44d3HD6yZs8lUf/OE28Y0 zR03/hH9tWggddf4y29pWVI4YrDar+Acd4RY0b71B0kIaWrI7WkUxxPJNt5tdXLjzVWHfOALBX8g eD2957kS1n8DiKdnIAmdOmbu3DH4Gj127jzWc0eMU3z1Lp9XGs1j1beMDH43YjVJ0lCnbVJkq7tt gbxC7kqtle9KPWU/IEsP2vfYKaRTlCipVNLisMYsgWQwFrCicagpZva7fDE/pC1E8V+XcsqJFEnK SZpM0WS1S/a6XHKKppK03OH0OhxOusIBDssqFyRdspP3p5IuB+UhkHIq6XJMTQCnZU12cpgoLRaz yekH/3NwG0lBjZZKWEJ1mWWZNZntmROZUxlRlTOJjJbpwCsbM7sz0oZrUEGdcqEnFG7vRcYWbDPo W1trmNWEvZibfnBw5PcFw1lMGCaxD7JB4WiOlUL5fJDI3SAfLrWFgSeS3Noqtbb2e1AOkhJ6B+Oo SSRkgzHx+ksnrKxmXpTNomtfoifz0ZrIVfqw8ZePgT944E9jq5XhvcsikxN+kUaveuME3HbHyFw+ IptU1XrFNn7I2Sd+VhEXVNUvl7k95pF/h/f0asyLU/o+F6Yh/0pD7CDx963ZY7Y0RoulXuzv7dhr M3BgC5sjzZ728F3+e8IbIuuipiWuJe6VrpXuda7HxSfsjwVeDbwZsYh+khnlHxFd478zcFfkjugB /vkyS21mUbxLXGFfEbnL85xTGuxwudMxMpPGAAsyL1K/mcknXW6HcFWMc1zlM8PsWhe4wssykHGr 1x6EeqN4QmZldlriFmppD4V62v9UiOwpjbqRUxXOFNpPl2JOPv818loZyS1hZeeFF698pt6EsTrt j4p2WyagmsySmYqRjN1vUYkYxcYadKjEHBZUKMXnyhyGZyh0EsxvBhlypVh9LzLjuBl0B/tYpE4b kZoVYeySMC1b9e2WW94f1Dbr6MNrPlix/B+P/Ze+68CbMOPIhkdnhRK1krBErywevW/F5oP79Q+2 Llt3Q9eS38DY4hGYdXh4uraBoSeC6OnESiWC3NWqzQqvQcWnWCOzJseahZ5FwYXqQxXFcmGhazGe bHZt8e/wiFc4pESMKIopEXMoqWiN00GVpkiEmNzVUWcsHqOx4aY6CTokkFZXDdtXwn5na3sv4zio XJlk5AzNtBOv7K3zct5mVCkqeX+mvc4Lxln3DGMPqK0Vi9WSYi9nip2Qyslht8floWJ5tiJbmeXE H8+o6PcFfEFfyMeLaTUnZ1SoZE0qjE3WE2VNDq/lVJ+ikpzcOpB6shyJdAt/GhjPGtxPtFJNSdS5 2+fFzCmmOKRiAYN3ugwuGqke2uY0+0flq+nsv9+/7/lZ9x1aP+z2mbIn0vD49BsvGrFgnKomfIu5 mxc1ZtWRU/Ti8Q1/e2R22Mb3nf30kozFufwhGA3Cw6uq4oiQCkL479Eeg2CS1u3nQ2aaaKhrWNaw seGJwIfeDwNfBv4RMK+0XO+7uWYdd59XWGfZwm2xbPI9wT1hERPeMT6toaNhJSdYOIuFNrCy6n7+ YfMO/jfmnV7BBkSaYrO9aYpJiUQsqCi5KYMGfV4Vy4lTAN4UYmIyEatQUiASm2QnPtlHff6c1+fn AlLAv8ddExxUXgE1NluwggZNouSUJku0DZsN0i7puPSZJDoZN5bqG3blDuVoba4tNzk3O7c0d0tu Q+7RnCl3u+xf5t/o5/xhrQEaiNMet1P78GQiVN/vHoZz9IOr0Mn4XOfyWlaal4ohubu79XxeLJRy Yw6B9zWRe/u786ecLPQHuVxnAX9IJ7iYQRtcqRqaKnFpdsqVIp1haGNfAU3NsIcjWhO59Xo5k7G1 L5jraRwy5aU/1KvDzl5dPTQddlgFSyQzsppfmoktntPyEK/3fvSLn/UOuf7+Bv22ZfWJ3Xv1KarP oQQXcDfP8qXQ6fSlm9aUsb/SqEH77kT7VkFSa5d4s6WKU6wTrIIoiBYEA5fhM5aMNWObzI21TLYu sKyw3GVxrKrYWLOP32d5hX/F8iX/peWMcMZicSRiXiUVS8R8ipKZUlVVpOXaVdlYxmkCEzOyOWZC AiRNofRNMSaVJWJpJWWSpAy1TbbTyZA5pIIa3l0DNQTsTkfcQR3DY04Sx5gwvKwsFqr2+qrK07Qc yrFqSnsdsTy7oJJyNU19puqaF4Biyh0GEsZKLGMQo2if1h60T762tds4AcOiMhY7aNXWkl3x/Ev5 S2NSv62+K/yPnmGdxcKSyQybMQwO2AAZPBCZ583VkJ25fLItlfI8uSQbQDD2Di2ZigGTv7HCcd01 rb9AQ73XvOaa3mm/vUmfy+B43kpsrN+07o6IE210cd8pMS1cTRrgas1vkYU0pzoqbozfHb8jfYf6 k4q7Ky2p/lxl+x+5q5LlrlE4WCQtsnZZu9IHuZf4onggfSBzoNIyOjW2QqtcW3FXpbA1s7nycfGX 0hPW36lvVkgTHEFGiJYFoey1WHCWwrY3NC9euSUArtdiASXVMCB9KWRm3ZO5sjjIcXsgGFSEphxn b1LMxCW7qGs4lIWb2OfNNrmxyV0eamx6AS5GW10Lp5itJvW0j5q+32mOm6mZxdtnzEZCy51pbe/f JGbGwaoT8EXk87mNbUOVtqIIC8RjWCCuT1SKTiuqX82mMQhLqi1lVokjKY+ERNwpi5V4ZsnaVeJM 2EcSU4WR7zDcsqLmB04CnUbAZeZOZdKY9Oj5nHfewpj7MBG6GN9jpm6SSbJ/H2KwcKc6Su95dMsb l8x66yeDFjb7xwxK0U0XDpXNt+lfbf5t38uDxwKmvCunVP3OHa3zYkJUjh57Wn/75y/rH6/3eSHc UZtRVSGe9kzQvxwydPHTS9Y/DfWwUzZdWJEnpXhM/8qeJSHrteqkNjjaZknEqKKEEzG3okQSMVBS 1kTMpaTcLkrBFHZG4hEaGW61MBMEx6baTlmgzqJZllkOW/jZ2FBLKJFkb0YiscZTSViWPJykdUkt OTu5JrkbT8RhKzAYYuRj++bYGkHR2IZmemI1s/p/o8DHdkSZlhhK6F8HOj/9HRs7rQgK9d8cvjQ+ dweOcaX+vs+5HlxpJZmmWUqLzODyivR9LZjy+ZwUaLLJac4QVVapOtzyqBWsRZi3pyoWCxZhwR73 5NyGg4aLyWe687UyYt2QG9M3OpQh+EAxxYHb/gZHMaqa/hVBir5T1ZoOOa2TXr336femDh92scQP DmeG5VoCuA7hvPC9i15+pmvvNWOnTcpHfZYprrAnWlV4n37AloRrymB1Y8c1qWSD1jwPuuCm1LIs vzG1Mb0zzf1oyIlKyYTofVwklSZsicvUNep2VVCLcFCTE8lyivYFEzWp75JHUCm7NP+Ppg5l6rJa dnuWGzadWa4/j/X09GJcxAKmt7Wn0Mq2lQJ5w4BG6c39/0wYMNITure94ezEAZZ8b6hhyWAqNKfz 6o2La+Gknv5/WHT7orzDPHHH9pL/SotQA80wWVtexriRtQzMZTeV0bqWMc0dLY+T15AYR5uhi3RF u2J3kbXRtbGtsSdif459H7MtaznVQuPuuCfuldOyKjjdTo/TizReNTeLA4FQMySWUfq1GB8SU5VU bSLWpGCcvFsbRWLRBBBSHo14o9EIaW4mpDpW5o3Fygg0x6JcHMKkuQn9K6PGom6XiZDBLRE5DOHh luPWz6zUGm4x4lm0rNEQqIVFWbPP39hSFi+vrWHvudh7Nadq6OGaEzW0JjS4pQiX7EkikopQdScL egUDSJiEcstzLA2hgUIsDQURWeyHtcbGXyBvWluTE5BWYR80Buefl2V5qbCclemkMwfw76AbmJog BS4vC1Hsmr95oJW5E7CMlpd82z86X9XbWhr3/jPY+61gn1bQ6xzVk8qtFN/M0Up4m/sPtGoyeOW5 2wYkrO6zOf7YuTHzA/VtqgrxxlrrZdzMhQ1ZlXl9DFnWZrR5Ejqfdbsx1vzzWXuedVqXLS9Ho045 Gos57UNiJiOCBRSFDolJSsqViPkn9nNfrCuScjQAzlhseGnPNRZRiMvpAIgFkiYsJAgN+E1OMzBe bIfZdrCv7kDcyq7yKIlARwRIZCnCY7VihDO5p7OwnBmgnVUBy0vfm7OYxnKB+/yeKzbGBgi/+ijB i8ESf2WqXyu3rj66Vj4KzArsiyzSt1vLeZqIU3YOJssTy5JrEmuSPyUbnRsTG5N7yd6knU/wyUo+ a1U8lWFRLvZd9qynCbudmsfNnuWXvSDLG2F7dLe8O2oiLLthJmIPkO6TTd5Im8we9za7g23E5PC0 kWLft/1nTm+bs9j31R6cg/3HzzoCbaU9NuNJSWCFpIRodlCfi7lByTNYYMti9moCnT6SquuEw1OH JpVzS5aMSejxZdNjuZHDhYnnDtALVuWGUCTRqclzzm7mF5/7xQ0XoYFnXs29mG5WqMr+yAyt+y1y aDspg6e1hkXyIs8Wy4fuD0MfhT+Kfhj7ym2WglJZgAZtgXAgmpWznqy3PGwpY1QuwBpff7HiHEC4 WW9isJrPqhk2C1jj3gwP0q3iVtODts32nXSn7VXhVfMrsQ/hQ7ud8pJJNIuWAARowBaw+2PmBaEF 0RuFLtuK0IrYZuf+4P7Yh5FvTdapDkcT4fxNktltDcWvnW64AxYhWohEZHSRdo0DLlybaEvQhNMd d1M31iWsWuxk9Ynm/LcJbvZ4AHur+/x3lKwcmcLKkVYok9VYxpsxq0ImFA6Gqei0u1XUU0QFnwlH ARFHLptDBXuUYgsei18lYR6bXK4VjxIVNKyJfJx0sn3wvSbRnReKfT2a1Z2nQXfehi9a7Pvjs648 FoBfYyewM3vejGfP2PPk/BOpM+D8CF0L0lifSTSZyGZcMhEUyfj+kkUMd5OMlX8AWeADm1/TN+n3 vfYz2AYtz82dvOrSrQvHTJ83f5sw26Zfq7+r60f1c/88CnaogU0TX3pYP6k/tvP6eg1CX+A167WM 0Tciw3gM0R/GMH38IEkg+m35BEP/LGt+cgY2B88EziT+pfCVpigBWwKRr0AiJiopOwvlqUiNm9RE o6LHjWTXJCch+ekc/xr/o0jb1tdmIBMpfalZbSc22UY7bHNs1LZazfwbH2Dhtp/oMy7H6spWowxA XoDa6GdnaLKyeMobDgZCASqmvMlaiIexUXzpWkgEymrZ/jWqsJ+WsxMj0iKcfigUmpIJY89T5Fz9 X0ylaEVkzKzeyZePikRGF5DppPUdG+d+lXStuuOO2+kC/e5r84qqplqu5Zax0YmH73hBCdItvfvp T7dsvpdpsEP/T+FviDA/ycDr2hjeuii0KLpQ5d1Wp8Uz3jnes9Z+j3OdvM59j2etzzIaRlkWKQvV rfbN8mb3Vt/O4FOJHZk3nG947H6GocSaAUShrL+X+/sgw1wbDjIG3FhDiNlssdisgk2ULW6Lf4Q8 wX2X826PrcvWJd/o71JWqPdYNgdfgVcs5imOlyyAoekjLeh0NVrLsWEPxn1t5Yg1FQk0uTiJ7Ver VY1SEZr3coPEJqEIV2oua/xdYhKnuR2hbPnVSQbJEi/Q7CTFdjvbveHDSP2Mp8nt7sbyUqljwDJX OMNgeWDAnH1sSoQBk73ZPYNtjLWeYaShrdvY2cbgWigBdSIDarMtk0SghlQ1k/CnVCizRVQSlLHJ uPFU8cVVVH7Ujp3NGnYGVEh7sEEHQN4g96O0H6Od58ek9P2SbJddeR++nIhSD75ICYkFwXhWwMe2 0bLGAznJBGthABDZfg73Xs2R+8qrN3c9p38y4Yz+HmyBIZCHB/Uj+rV7511009TNWy69qX2O7c67 TMMy+3c3wioQoQ426Vfr7+j/1FcJwvOP6J/qO5644brH4EIYex/7c3ZWh/4XYjJFquFGre3S8PLw Fh9nSgVTF4YviF6gzI1eoUhuIhBRFmSRr6tdGOmKdCl3p45F3kydqDVt9b8f/lfwbOhsWKg12Yr0 g70Gao0BAy4OtDwDL5ZXRkitTineVEq5JXUPGpNURpORNcpppUfhZKVDOaFwJxRQApVRJZVRayJF +EILpAgR09U1HoR94t1kUlGQdJmQqICARJJUypW08tNAkaOa35ZWsczojwI2WwfL/DXDDkLIKP0L rYztG08d9TLmz5iLcdZtVMLG7kBva//X9Z3LC3m2qZ0vsLRfcGCtFTTqLHSSRLbKG/apoUy5WuWt rIVsGJucv7oWKoKZWhKO/LB1V6KRhdIDA+UY6Ky2/P9h7FvA2yjOtXd2tRdpJe3qvrrtSlrdZVmS tb7Idqx1Lo5zc0yBQEJNAiEhJEBsA6FJDjiQQIC2JNASStP+BNpCobQJGBIT2odQCoU+/D/uDWh7 WvKXnD6FnnA5BNpTsPzPzK6dpPT858SPd3ZXu2vtzHzf937vvDMpcPZaRPL4eoARltHg9j9xHqYg gDVpb0BhygF7kRj0HlOLTS+y5eMTe69c8C+gTw/n2hrnN5asrH3xjuV3PUBubOw625/MP7J936U9 SqN1pV+hUuRG8r6pH1Rv2bT/qwiZbZw+bolDz1IDRb0mlS/IXR+nGCewCmyBKUtCoFAUCmLOVUrE Csmmtnxb4fLc7bnb849oE/mjmqc2ywEs0n3EKqFNaSPbHqlAHL0qFlViClAmYO/qk1cRITFEhh7x 5QoClxZ4QYjwEcGyRdiS2y98h3+K/4nAFHICb1Hp1gqltvqsy8HMVG4aXGDQshNA1J3uUBe0f61L 4BSY+sBTTyqV5mDnBKg9bkbxEyeRS/gYSw4NOjxQGxrBRo/IAyQ8MKlxtI93zVG9GMVTApnKpQsb +SuEbfxW4dbcLYV7hMf4Z/if8T8THNCg8UjXCMyWPAYfjocq8I/Pa8HSIESSq67qjCohnWkmz9Ap tFM/5nPRt3atv94X1UuPvnvu5xp/fUUfXVFWQp3uVKrpk7uGb6lu2PX0gxe8+9TcntLucEh20Jsa 3Y++etXColpqjp933YYNtz76USjpzeZI4o23tp1TXnVO70U7/tfqB0+I9t7YHNSqi6F126F1x4jH niYS0N9KIS2BXGeX6NZiCR2a3LGEpQx3SPB7lv0UtqEUi4qJhDUWFWC+9PtQ6FM5qrChLBEjRYEj hgFq5Lye4AyapicoSiAmDUp7JUqKiQqIKYPKmLJXsShHQZ6QyB+MYx8ufowIdhH+ovTTJA2mume4 0RlyFKYxiHMBJnP2WWYNpzWqi7YnYwPz06vXBeZ1Fqc6DRbh0tt7Lgik6aWNu8Y2x92fvHM6KbH4 O8/ZBzajGilPH6e/DWukGVD6A5IQTJCSLZPIq9vVLzvvVA+q/1udVq14viQlApEUqWGYFI35xwJP O1/KvpH9c9ZJqz6nmIjF02olvirB/jj+kUo+5DzsJKsci0iXhIIJ7HysOUokki6UxahSIADgM+0b k1aYhcTGFLBamVZI5YZyWS8PlofLB8p0mUNCTpLtyeUG8yB/Q8nMTkzdFcYrI0Z2ctJwXIUZh5SI Z62CLZ1OOVN8iisRmaxDFSFaiVsz9hIhJOAGVTGOUKZTGhmFAWrUgxJFxkwTTeeTSRsZ/2kyBGYH 2CuxZfKH6vKuYPuNa67evywdLX4O/DpSW+py1E/98tCanVeG9BX00lS889qpDYe3DKz9wRtk7qIB GCNTzc2xc6em3vvVEyX9pUfIr11XS6DFDAn39P9lEYNVIRl9fI/1bzlykXRF8BFpQnop+Hbw7Rxb kwDbFCBSRBuxvGV1y2B1E8xxWsQqGkkYru6o7q0eqB6qWn8MXm15i/iQmG6hr7FeE7w2e4t1Z/AA 8bDvEPE8YZWCOVghpWqNWBTrq4wSo8BKiGGxvoMA1mCQhZAmGJRCIY4nwrDV/80CooRBVwbcUVcs C/NNAvYEuxAVlRC0hUq+HK3olpyF4Cemd41LvA0i2O36FTnY+iFD4sMVc1lvLpe1E7zIkzxflAJe SQpYbVbOlpWCcD/IsGw2l4cX5QN23mYRs6EgWhhPYs6HTZ/L57Jo3Tw7zGH4SkxBEl3exrHWaiAQ Inpt4EfQoHNkN6FDA6vDfXH62GHRpYnBluoEefl4fM9Vs+RCIRRcNhWSpkLBKWkA6a0xqWAQC2i8 wl0brUHHCHd3L2suoDBH7zaGbI0dJxq7Pb0HwQwOkLXQWQO5/2Q41zj4aGi3yHVzKEHuBkMFw8Ee ycesDi2WBTC1XYmZi6GREWJ0BGmTkTgZqEjMilJSRLBCzwo80HliutWg4zweHAkzrey7ac3L1BoX ZBqHGnemGnPnt+nk0oWlCrD9uqO5pbdO3rVA9knFv/5eFTuWw85JJVP2PZ88QG38dJ/l3If7mFSK zETT26euJsm9W5bDaAlsbNwX2DJ1I7lg1dxIrkRi3iIO/WgL7KleENB5ILrlOsSDUt2PXGnZLWsw w6EJPgpcPH2QfoR5WDxltaxhtjC76VuYe+h7mIfpR8TD9CHmh+IzrhntiICUjZyH8ft40SpqAKXx PNzhswQJsjYOxyzkC7FopMpybg/vsQOO5AkASFekDoo23muDTyF5+2Y/xAkBrKdaww1zOziau4CY IP9VD3m5QxzgbIQ96/USJAkf7F3t2WkL+vxHEfcOtMevMiA2llihQU0EekpAbJwawh1mhEC+ZjcN u0dhN5Z/YEmj+LL4sin3QDQIAHHoovG4FYBO2kmyqsfyx0/fAuSRRdc/Fs+0f5Km5JevS/VtPwc6 BHrpJ0Qg+dyDDT9Nso5lOy4FX4a29/npD6k/UM8TFaKbXKz7GFGsWWJirUXvnq99sfUr7P5WqgfV +CVLWg/XwI3sQ8XHuo8UXyy+EX+9+Ebrn4rWVnYBu9izOLCo9cLAeu4eYn/rd8BhcJizV1mwo+c+ y9eL36hYiJ7BnrX+NT2jgX2+g+A7nc+C4z02zj/Yc20X1c+RPreP7EJ/5SeB2ntdoKXKQcMsNGUL TalCU667+r3qM1XKUp1TXVa9ofrl6v3V71d/VP0/1d9XT1b54Sqodnm5OLeOu46zkFwXt5Tbxt3O 3c89xL3E/Yaz8lwYtg7ldXOU5EgrBfjE3PpSVz/Zci8xVCqRkp4raIKkSKulzdL90kHpWYl9U/p3 6VMYXSXdKWoSCUMELzQpTaWmepOlaX5unpBSUmTqHYIoWevWMeuzVksMFiRhFWF8ngDP6KLes6OH 1HvW9JA93/UBHxIK6dnBbH06DMIFol1sJ9tbaF1NaZvp92myTOv0IL2GttDBOR3nQ0dSucUYHy8s OzlyaqTw3BAM46eGYBoNw9LHCFvV0YwO+DnsJ6fQ8NrUqROigbZG8TjpzEQJ8WVO7HZ2dyO116hh BU/apahEEkg4hEZtOjojqk2kLALMweIpPl1LO2WXTNhjVhkk1E6qXSbEiEMGtgTcdFi6ZFNHZsQ1 HNpuuglAT4K9yUiBQDlYyuTzU62GNBljtVk1j6HRMyNgewCT/xkXw5q0P7noe7cNbpwArQE925sP RdKLuurnj75y9S37A06b1xEKyy2b5g+usm3tysSDxZY77r1i+abv3XnxxvZc1C35lEK2smBptX9n 38jc/L2Ne/S4mJIWz1tyD6gtPKetvVkNo6y+MH3CEobeJUBkwDm64O7jiIAYIIEUdCWVwAR4Vw+r 6V0UK6d53jkqCCIfIAgRySXZkDuHpIxLWlGhd3TN0QZzkzmynNNzg7nh3IHcodyxHJtzOgkhqATJ YN7l1kVQFnVxUDwmTsKcLpgdGMHZkSGchKFkPBhHFCMEizFcPhFQkPhxJYJutZI4NFoo4EtzxqU5 89LcGZd+bPIq4gnsxCin2A3dv9HGoZTFQaeS6XAoEiIZazqWSlkSGRC1B2XC4VRscF9l0hkQcsgy EefkzFltjPUo8y7U1RvoYetwbCy5j3uYfog7YuFu5m6xkmOWMduYMpbaR9+bZDBNthK4THW10bQQ PWoG3Wnw4C0zmjRwcMuX1jy6ZtsrO5duqe1PsLZCFexibEu7qosqbZm5ENpMTW0bmbztvr/vLLet s3znHE8kTKamvt1YM6Z2Lep87Pjrg50oVgxMn6BWQy+mEh/oV33EgKQVrLQ+JL9AvqC+Ad4BfyRZ GweayLz3AmW99XJli3WLbVS+1/OY5zHvBHnUe1g+qr4gv5pyEcDnIShnZJI4DvvIJDgOSAvwwsw2 7vFJQel9F3D9RUrzbLzfwgtO4CygeVjjLcE6no8Vtro0AYAD4BC8I3Qw9R70EUJEiZCRFta8DpWH swVtkgWsMSrr1NhgsuNOQ/M5hCZmYLITMRnLTozigHRyROzGSq6hkdoIjk2moB1pYEdS2H5INCei OqOYm5kU4TO0KW2Ursx9YfMzx9dvf+Ou7y3o6FpmZQIBpZzQzlvUvqRy4QfSv2wFoRefvevg3atq 8wcuqweD1WX37/qgq9CMbGU5tJUF0FZkogi26erXHN91PO044re43e0cIYsyGVCKVk56UJFfUA08 De3nSfAgo8Cdi45whV12O8ejZXT0YGBrPO1l4aMIA7fBfEWUSCmPK9AJa0gAywF5CKY8oZJhZagY h0ZWwqPgsL4GS5Mlcrh0oESWlDRI68hedB+6dcbKJkWLGGzuuEmadaKoTqENFT42jk4a2RBMP1Hw FfHMiiHDZGaNJpvIOzzJlJoiGXfa0BI5UwlPOkPkHXCTcsUzICMUMiYtCa0kj62kNOwY9gwnhvOH SsdKzLBzzL0lMKYO57YXbw3cUfya417//qaH/N9rOtrk3CHc7iJRKw6txNZdMqy7ZFp3ybRugKfg DBnGE/DRrUaCMONIsW2prR5jGozZ5O3ULxiu2NG4buHmvvEN5214asO8DV1We3nu7sWbUlKqpBUD 2QsHICZ45SpvPGaJL/vqip4DN//o3ve2ab0gtMkfjeSnbr3Tq3zjgccfTXvuMHoBNQRtzEfEQKt+ IeNe4h3ybvZu8K2TtnrZlO1h8kXyZdfPyZ9Tbzje8H1I/c1hG/MZ8vIV1Hpqc+J6aiyxk7rV+Y7j zz5rnpv2A85qLaBuEOMoboiO+QnQ558A2SfDaQ9LTwB53M5bMd7jYev69WBC819BIAtCjU0gqvPY OO/UCDy47molQqVEPbE68V7CkojlDEqqRTQtD5ey2yjTZQ33GjvsTpMw0wjGTQvEo0vLpoZOIBss FFBnKRQMeeqpKZQAnho6AWHYiEFXu+RoyqCrI25FJkJevwxkV1gGAR/cmHQ1oiULqJFHQNywRiPi oQZ0w/ZjtRlj9VFDU9PWVQsu6b60I7F0YuvkphVTj97583fVlE/V4l3go6NXnjvvAv/+mw7c9Ow7 wPf2gw98QXFXV+5X0Rw8gqDm0pughRb0z+slwHiUJCkwBKswImvJFyB+zblEh93uhg6/IAr2pMK+ kABJhYE2G1bC9TB1EEKTlvTNPlB07myCl8B4bCshUb5QUkpvlqgSBLtAwvA7GNYkOZfQYZnYmyv9 9s0iKL5GEDmz0vP2SQEIr01CD/maw+HO2c2pAKjUS7kWLWaftJMQYtjL9h32vfYDdgYNH6zBu5P2 9+2sPRgrlUtkc+ln8aPgMsCgYYSRASyAgG4RxriREyMQCuG9P4kfF049VzCnthZwEOxGSTv0nMiN ihD+IJ0rKs0tMnE87o5Mqt0XRxNdXGprtTWjnXaiyKPOSKcDvqoPvOmNrZj6Tb3Ve9tt4JdPbr9+ 8RxtDmOxi4FohryDWjB1/cUSTHaSIFxeSt5+6YLS3mOf7yjObYtbIy7BZxPKrQevvxTNLV7W6KN+ By2pTMwhloJX9HNSIi/Um1K7rbcVv5J7yvK09Ync4eb3kx/Nt9mq1lamxnTFBmgOmm3OmlM6lH7l S9wt+f3Wh4sPz+P1/uTcuCMniQTVySa9PTlHyY4Rewh29h7dXevR0xmtR5cVuPFJWrkH9OD5RZLW M0FZdJ/XmHgQbb/Xbo+WSEovVTRqgorodtiDK/eW2AXpqNCPTc1dR6Vug9821g/6+6XOielJ7Hod naCzRRplSTCqsKCEohvF6LmmuTq8CW6EemkuEOYqc8m5/XERnRTxSREIoiKS4gRF6960VoaPIjUg aIpGano8XWhCf0+BZ5v0bE5rQoBZaNrctKeJGmyabCKbrl8G4TJGUtBuT3Sj9hZPouTI3E4NjXwK +8hJfLpgCOxPdU8VsDDtJMLQJib26kpcK6w8WcAewEyanyZ60HgJrD7kiaOKBv2wKc2fleij1KyG exNEwAWkAsB8JLZwrLmvtrcEjEEpJFjC6vwzJPqscU0L7mmUEbLNozT5TdA1XvFIm59dzIwW57T3 fP8Xy0c2nH/Td2+cXLXg4ps3XnPrF44fGlrcObi8rXuwGLtufby25VtfvF8IX0V94+pKtq3rsq+c S3flks1ks37L+V+MVyoXlJsXBfXRBTeXKweuuP3lnusm7tl89f3jveVPPnAprdVzF88LumQ/QlR9 BGHpwMrEN58mmOn3n+BrWFpRWtKq0X0kOYiUFSxNM34mzVgEB5EgmhSHmBCbGPdB57NOMgwIT1Jx TpC/012JTFJJqAlrUnGoaiSpxCfI3+pr1WxSaVJVEIa3EtJ6C5uIx51Oh41TrMCa93r0eG/doy9Y qHn0Oa0efR78rXXCg3IFbjJZuCkU4SaRhBvYuz266NJe9QDBA2KeVz2k6AEelIq5jzUDpflQM1lq HkY10dOKXmQcPgqX8Gm4hA/EJXwSLpuacak7oXE0EwaMy2cz+BT8Yu9nQClzLDOZodCp8fZODZfQ dnAJvxS+1BqNa5lgccCAIqhnwR6Kx0JFM3uCLg0mdsivzf4zlFKG2B8CFAj98GkKuS5gjGvEkQXz dawcs3rtdSfS9uIjj98Bj6CzdaIZlE4kJHSi3hv31k8PRA8h+DiK9LCwy7rMqZBIaYS0CTPylATD umYmAxjnIIB/ftmOBRfekMvOaaRbgm53IZxd2iR4uhrprqAr0wPx+lvnzLts94HGVza1sskkGw+t Aw9c2xVvX9DgLwsmuGSSifk3UYc3ahxSL+QhvFTpKwmeiBC/0/3yDlegLrgINxFRXKJbjDCBpOJG YDLhSCoutKNKSSXyDF66k0FKH61NO8gARieAPcK4XTYrqoMIPGvk4jqVs9sNZXFeCujw8XiuaGcr njoaU40pz54ALvVSsawdCoA9AYCTwcB2XR6USUVeIx+QD8mWklyX98CdY/JxmYkOHIOOBzbcx0Pm qCNqNpiMmxGofhJ7ElzVZ09rObueYZ2me1ddpOurVr3SPK/B9sje5rn0lfiErl/U6JoKr223JJNk IrCWTMDdFLTOAqy3JLROkYAv60a1tsYNDrmBQBMMISq0yIgiw8PgjusORnka1x0M+iJKbf0qvJOh bcRMuOZRzfBGzaBivKhpvFlDqNRVWEWHeLCHBwa/ul1xH3AfclMld929x33MfdxNu9H1FU1D5eFi s+bCFYQ6+Fk1NCNdNPrgCB7EP7s6xk9Xw9JPtsy+PPXSpejl4dsvJQjmOhg/+8gBXVlIArdb0W1y Oyd4iG6iT/FAw+ljQFt7MKnA9O71JxPFpJKFO7o30ZtUutWEkFQ8qqpnQCKpZCbIN46oehdoTypd cF/Pq3OTSp+qsoliW5wFFrm7Zb1FXm+zWViij+nuyma8Hlu/DmMSDobnywmN6D/Qf6j/WL+lH0Ik pyAoAinkQ0HotoLIR90ffDb4apDSg3uCZPDteCLfXIQfFfFHxWeLrxYpvbinSBbfJoR2pZ1sz8/t xQE8mtDW9B7vJQ/0Huo91kuV4Gayl+oNLuyfIM8djyOnUhg4LQrFQbB7aqYc6jaoRBT1TE1bHemv xZl5cTWs4DUmOJi+BcPaZKkSjvIOmimnI+kK3SwDho3yIRnYHSWmRQZhu2yA25nBDUQAEYvO26q7 lRhnjXFyhlas8QwRi3MswIMmhEEgJNf0H+8nGXvSrtn1/td4ejm9nBuwLueP9dMd5HJmuf3vjAXh spFRIyHqR1NHo7iix0VfnZmY/ts4dHS4hO4P4sn3Z0uXwzgPS3ws8MaxYH4umvfBEh0/zp9W5mCg jjIsn5FR/fcOEeFFk9liP9OBX162c2DVtvjgVwYvuaaY6WlEa2G3txAtXFh0BXobkUxR8JbC2Xip FX4mY79JPbz9vHnnrVg1uPL2fY2brtSgn6Qz4UvA3TfMj9frDdu6UApZgVr5HLh7TE/6lCUN29o6 g73plaSIvakRs9uhXRRIC4rZf36Kr1kZUMQs1ZLWwSKgYbxOMdRvyNeoX4coH9MKIzn1GngzTLoF JxEnCopTjIuFg8KzAgfCEW9SEYz4nYYxW03YYDzH8TuG4rdPhVG9oKrxWEwQnLbgepqysGGY5I9P ogHL6af0FVIr2ArTY8aGI7rP50Uh3Qv7vuAFMe+rXtKLwrsXhnYvCu1evbUNbmBE9iLb8KIg70Xx 3YviuxfFd9ELvCioC0rxUJEsFYeh2cCIXjQjOi7hQ4pmZC+akbxoRviiGeFxnQgwshcjxiSHfCaT ng3taVBKH0tPpqm0GdrTZmhPGyE9qaWDTadDOo7o4hkhvYC42tN9C5ujuYwDvGEEhvTuM0YTz4rr MSOux2biuoDiemwmrgs4G0NxXUBxXfjHuA5h6CjKM4dGEQs705v/SUf+bJ99vn/X0ou+4BVhl8y0 BkR3IbRicaa1kTG759aBheuW1B5sfPVKHNZTwbXgwDXd8e0N/ooO9qxuaK6AcgT2QwcRB+fp0k9D IGMH7gs4Z9oBCDaQZq0cH9UtM4yPRU8XNMECLCHVYHxwsdAo6rgYr83RUKknswXtmDqpkoSqq2tU tEvr6v0qqRpSQX0S6dCNjB+X8NGoPAwTfT6IFMg7nsy0dowgz2k0nsENmfgLrY2CF3npxo2E3eF8 EEcSd0WOySTj9fg8JMOkw5FQJBihkKIwA98yKgO/1S0TEhvNIEVhBsiUUwYeW0AmInQgc8aaJoU8 olOhM6xkQQ0sAovErXZ6mBmzj4nDwR3MHvsecUfwJfJFxTbGDjuGhTFpD7vDsUPYI3FItjKyEokH TaEKpv3cgYShlzcWP2nDw8mgse0XV63b9vovT7z9anVRwMn3NxfljMObToWo52/88x0/vfVBkH3+ ZVBYuOytn20aWrg4mJizGsQfHYv6UAtmGost8EII6kvgWj3oLnGISiBciEwQXYynpEK8lUT03rs6 b7IIJkLTw2pxV4B1uSEaY1JphWdYp5gDOT0ccleM9q2YjF4FcwnQCgcrkxWyXNErg5XhiqXiNmGJ ww1z0LJdtw/aj9kn7bQ9WD6LN7cbdJndpMvs/8Cbm5QfvrRiXFoxL62cyZubgsSTBmpDBnkWDxhL N0lyMFVIR9OZVJOUy4C0DDf5UDEDspHULP9XMFnyrqReX6ipaDMmjclj6bEmy7XeseBw9F/U4cxY 4Rbvl9R93nul++T7EvuTD3kfSTyaPOz9YdI93wcwF4gUSqkZddKshcZ9xiz9mdwynfHPzMqF9gwO Bsp9U3/BqAncVqkuWnH5Ixde9P2Ny+a1tK+4tE3Vaml9Xe/qxrf7NSmVIuOBNdTvEJbc3h8r3fxv u+78y/ZE6Nvbauf9+3+s7LobYawlBEFdDXtADmRgvp/ma7zXLhomBR0yjxTPYZgPm5gPljueUFrx YVQ2TgsiLvWM16+JBbCP31sg+aDDpQlRQiZySlSUxRwDfP5AgEg8qMgYqgZeVKIYqqpJJYd6U1S1 tQi63A09XqS9LlyOggyRY+SoTRgibEfBasICVh/Zy06yx9HCV+CozhM5IaBA9J5XE0Z/S+BooGEV zng4ZqhxvG6/diwBhmcW1fhtfsBgEgysCjvQqVNDJ0+KJww0341mnaLOweLOgQmkwmm9IeoDvrYz CXhzMoAvYJC2hubbHAV5eehLvR3zeptbB1ibIxrK+WKAtZc6GuycAmdLl6mHf3XX6gX1eYvnWxh/ on7Jda931MRwkIKgoLaNpAf9kRCdwvOnT5C/gm3UQj6qf54v+8S6RXTkvGI0Z2G8fu+LqRfTvxHf Ef9TZHNiKt8htuV38/eo9yQf4b+lTvBPqjxtpx1czmdfyC+xMzqv20l3i0LsJxUAUNwBiKe5H6uP FugeYr+7BE9opQ8LkhLcH1ZCIeRY4SV7QyA0ATbpcnC//0O3m04XWLecdvOmHetunwYuQjMPjj9p 9TLnox3dZvWS5xuTCzDBywuacZRA2areCf234gTOkKCBkrZcW61t1sa0gxqjubkYegjakucbSjQd 3mzsJUK57Aw/bApW0QhLNlhFLh95/JECEqnBAvmFp7gYDKNouR09AG/hdG+8znX7VLjxp+AhfDcz sqIQ8fEoGjqYuTUeMzLu47oVPiN+Mbwfvck4fAQu4VNwCR+Eyidmn1VYeaKAtalBoGclWMkRF9yI YbhBcwd0h99cIoWon0R/SJZloS5PTP9x3O41SngFKtFUA3whvu5pgoaQyw2vpWV4IS3Dq2jvzCVo 4t5QYUZ7hxdbEkq6zVUv6VYBbox1WVaii4yr0F9OFeFXg6Y+OW6U8FUh9EgVIQiBR7/UrXAnVYS4 JDUx/cE4dKewPHEEeeII9LWn0fVKYsRYsGUIMWRniPcss84MWotKzer2jDW+2mamtpNfFRJzdvbm Or0xkB4auHPFvGGZj/vjYqL4zb7ynO4N9xXn3vPlpQvDLrdfop5rPHfnhvZkOJj76RdXDOwbzPMt YHDXrq58uW/hxo7Prb3yYEoQVDwfbPpDcp9liggSX9Ode/g9dhJveDsRnACHYftYvF7Kt5METIxH /2MNxY9a1zl5tNiOU4/S/GF7KAwsFkKgFZqk8x6/b6vX69Fh7XtQlxJh/lbyHPNMeihPMIS8izHA AMHiKYwHIQDEi8rBQ6I+dWIIqfPwGEM3wAN8xqRXnzo7To4dCyKq0eIME3/4g5AWezvlcw6v3O6y bbvx8bmWqcaja6eePacUXes/tnZOYh/4T3XlT7aid61Pn7BUqIeJBLj7aSIJv91DMCNITiZJqz1s z9sX2S01+9cjj0QmIpb32Hc5MoGUnnG0EWjCo9Cix/ImC6ZZgMgEVTUyaBnReirN0LbgOitv44lE AlYAQzB5M4LLDAL4DET8DAT5DAL5DML3DIL2DIL2DEL6DML3DObvGCAwIMa8ypAEIzIkg8C+LYny hiTE+UkT5ydNfJ808T0qn8gbH8MnJ02Yj0o9CAHGsSRQkoeSZCk5nCSTXsUHfHkBOZpx+GCnifKd Jsp3Gg/DfsgDwf77TlByHnNOOilnUB2YHVTEUQIzeWeyd//A5cEwcnKWy0OoEmN+JGLFq1dioxid 5UAYgyI24r3Z6njia6aVeiU7p7Fz3q3nLt+ez/SAGzy5cDKa7UDYfCqJuLYbBhddcvOD4BoEwqdu uqxT9oSWg1NmZuiBiPxd2PoRsEsPuUmCBG7CDSxleWVgpTQoH7Efl9+XWTQd4QlHq4xePB1RtLp/ uX8FQ7FOTmEtARAIS0rAaBVAK4xf9Cn+ienb9Y0CEYmFI5E+QfQKgggI4mLBCfecEScgLIwYgx5C RN4SDc6SYjgghEXBCegIDIwsyzARgg//VdxaFnRhUKCEIec7AK0ChUNQDBwAJOpMrwIKDKJvNt69 XMPfMKxmNFl3CJqI+bnjskWUwSH4HmQUYglqPP4ctLiC0RqnkMJ1Knhq6JRkLOGI55mZC+3Aj5AU z1Di7aYN2d1PCv9s1ZSZAjcelpjrPhl9WRl9WVJECjG0gX3n+BPeGi58qPjbE7xQn5mosJIGyMVB SGcIYzweQ1mHpzYD8JfGC7VYoAg+KLmkpq9vby3WQEtTR0fjpQj5651qyJpKufxyan3jAVC6uU3J kKkU07ZrKoGs3NXoo07Cdi6BtU9h1tOOvPYPPL4eJGNYTCx29IdWhlaFL2zeGNoY3tB8e3gi/FLY mfVkvR1ER6iP6HNczlzOXm7/Wum7xHdDrwcd8KmOksNecjJ2VmF8Qb/iE9Hq2RYFBheP4s37Mtlk wVkq9YWC3lAoaHc4JBh5HBejaYIOJwFAvBQKOh12gvVlSkQS7QKaDiXfKeyVheQ7ss8LQwDNhAh+ TeV45f0KhbMChzerVQKBkOAr+UgfbE49QOdysYyWmZ+hMi/HCwQ9CX1usFw53dQDeC2hoRPQtWLm qzA629TLRCSjQLyXMXQTQCu6cc0Fo8mdZpMT5rjO/2e9HE7s5rqxfLJADNFn6iXPbkTyjHVMA+b6 IO3gPxq/mN/bDD6oZFsOXNVV6QG15s75jY/WVRZsOPfyhVrLHAA4TpDC2bY0+dQ3+50QqSek9HDj bhC+tyvVBFuanvP41JLGp93nrZ7XuVSfl+b5aH4fbKPp98A3LSLpJygirDvIOtEwlkBdvGBmCdT6 zBKoFvGTNy1x8M2tsL9g/h32F5G4T/e++T/mjyMqITJn8sfov3UjDX7YoI0TBm3Me/yaSRi7sUoD 5gKKe81p5phymTR64eMhbKyfpYg/SxA/MUsQQ+f3WXZ8+ihIgX0kWjVe+hFBUb+Aqcwm+Pva4zQo iacIvNIUWpV5XyMJ/hVeKxr3WP70399j+dPff0U3nb4HEP/VPR+d/jtE4yjoO30P9z+4hyP+epQ7 4x7xv7xnavYekXjvqGjcg/61mT/fgn1h9gf8P/a+BTqq40yz7u2HWuqWkLHMQ+bRxkQRWMhCYAwy YbAiKxosZCILWciKLImWaEmt7qb79uP2W/0SEAczhOGwCmFZD6MorIfD6CiEo2VZhgDrsYFwMLEx JhxCgCUMS4iCMSZEvV/VvZLaGAfv7OyenXPEPX/VV3X/+ut/Vd1b4grKuR+x6zz3GfcZP0ORrnAq s5WHVc+oteo+dV/Kf8L1m+RL83PNz1NDaWXahbq09ExcsfTfp/8+wzquLXPVY63j0x6fl/X8EzOe +M8T1k5YO/EYvSaJydfkT7PPP/n9KRunfm/avOkx/f6nqtj1wdNvzPy7b0RzYjmxb76W+9msjtmm Zxrolfe9fzeX+9/o+u3YNXaNXWPX/9b15/8b15yJY9fY9f/hNXfOy3Oax66xa+wau8ausWvsGrvG rrFr7Bq7xq6xa+wau8auf98X+3sr+s8U+VB+ixwiKrKHKMjMxFson098grIIZRbJQs9MomDl8wkj yqLEVJSrGK5DOQt3+1GOS5SgnImeZxn/s+AvQVnEyjr0zGP98xjnPMb5HHj2oyxiZR3K58HzCcpx uPs8yQTn82QqwzNZWcjulrD+UlaWsbKc9VcyvJJxVjNcw0qqZxGTXMRmL4LkfpRToU8RJE9FWcJw GSvLGWclwysZrmFlHUb9NS5CVjJpK5m0lUzaSuhDe8pY+TLjqWT4NYbrUK4C/1tAtCTkVcV1Qn9L lf5pY6WCRWUaa1HMEw03XsYKYmL/ZzPFSpJLBmWsIpO4chmrSR5nkHEKcY7I0ZACxFfCqSTObZJx Ot/NT6B5wP48p9wrY46MU16RMU+UqkUyVpAFKr2MlSRLNUvGKqJTVctYTSaommScQl4YkaMhk1Qp Mk4l31a5ZZzOLVf9F0jmlArMlZGSK2MlyU/RMKxCf1pKtYyVZHbKAobV6FenhGSsJDkpDQynUL+l 9MgYvkqJM6xBvy7lpIyVJC9lD8Opsv8lLPlfwpL/JSz5X8KS/yUs+V/Ckv8lLPlfwpL/JSz5X8KS /ylOY7bfkzG1/RzDWvSP1+TKWEkKNZJPdFQ3Ta2MoY+miOEM+j8zad6UsZIUaEwMZzI5tTKmciT+ x6kPNQdkDB9qtjOcRfXRXJIx9NEcZvgJ9GelZspYSeZrbjE8gfKnlsgY/KkzGZ7M+G0yBn9qJcP0 XyNLS+2RMWKaKsVoKotpj4xpTKX+6Yz/lIwp/16GZ9KYpt6TMWKaKvltNvVPWo6M4Z80NcNzqJy0 ChlDTlo+xZok/2uS/K9JskuTZJcuiV+XxK9LiotuOC4/JXpSiAyYS+YDVREjaUa9nFiIGSQQkVhZ z7fRsgHTshH9rYwjH3deRO6ZUFeibw3GC8TOWs2om8HtRGkAZxXud7BePalA7WJcFvQ1QpIed+md RpDA5jCAh96zkXb0WUjLv0q/BzmLHqlHMbAJsxeRaqa/XZalx1MgH36aC5QLua1kNe5acJ/qJuD5 8jB+6tvRGaX5RmdbQV4lc0ZmXA7OL1tWNYJKmG0uSDPD03ryCuZtYXrQu3NAr2IclWtCjyj7ycY8 S6Xmoaea8QusX0/KmX+pp83o08O2RXj6FeJZYCEOtKmWVI6DxZJGxijHqYVJFFjEaNvKbKf/072A i0ZcT5rYWEGO2Ut4zpQjW6SxtqQ7VuZHA2ZZzSS2Mu+52FyrUT58XqlNeVfDXgezwsB4LSgN7L4V dyQLqFcM8lytsoTVsizJeprL+i9ZbmHeFFnMWxFjPcvKppG5HqaX+Uuyv76XRqUbRuJsY7kjMM1X j+T2w62XZv+yXi8k+YBaItkisPmGVw2VL9lqQI+LWW5hK/HhlkqebvyCV5tZZC1yKVklYQdaVlbq mbbOkcyV5FBOEzj+Yox+qi8smDtfX2Vs1i+3mC2CaG3Wf9tis1psjUKrxZyvf9Fk0le2rjEKdn1l s73Z5mw25Fe1djTb9RXNLn2lpaPRrG+16xv1gq3R0NzRaGvXW1q+Wt5wZ9GDMootJkNRdbPNDi79 c/lz5+pzl7eutlnslhZh1mh/YQEbiHFs2IpX59CBy6tGJquiRYmt0dVqXqN/paWldXWzfo7+VaHR bGoWoZOt1W4x5+mrW1cLFpu+vNFmaDYL+rmL5hWusjj0HY2i3mFv1gtG2NRiwZ1Gu97abOtoFYRm g75JxJ1m/Usry1/EXRtrWG0Wg2O1oG81613G1tXGpLGoW82rTQ4DhgoWvaHVbjVhgkazAaNawbAa XJg+X68fntxiNon63NZZ+uaOJjpqVJZ5mPuhKjF2A7XZ1mwXbLAO/kqaHsNHZL3ANMhtxSxCcwcN ja0VsxosLrPJ0pg8KZRulFRttulhrwVToXQIVoegNzQ7qXPBY2w2WR+w6JFPBdq3hq1EusM+ilsg Di4d6HeP5Gxh6/ZRXKVsXuFRfIp1iv+qOKL4byj/8Wtb1Pq1LCrHfSOwE310hOORI77D9hQ7e3II bI0/2srfYQdoJ3cwy+8w+lH81Uzyo7jKUJsgseVrca8Apl5xYBeW9tlH+ybZk4+0UjlduUT5gvLb ygXKhcqlym8pX1YueuQMVV87n16m1nJzgR/NSbPZCn8/UmfuMXJJ8TRaj84SC3tuNY6cHUniKfIL 8vA/CkJPPemESyToOykhy/mrpTxR/ISQYpUK58blemnbLTbo2Z8E/pC/SgxVLa8oLihQkLj8kwKi Q3WcO0N/6xiHwjcJx/+A/w9EgRNMN/CP+B8Bb+e3A/+Y3wH8H/lbwH/g7wJ/rniMcIrxCpylFI8r SoG/o3gZuFwRAA4qgoRXhBS3gT9V3Af+s9KO93NBKRCF0qEUgT1KD7BX+TfAm5U/BN6i3AL8t8q/ Bd6qyiOcao6qkChU81TzgOerXgBerC4hnPolNeZSl6uXA1eoXwOuUdcAr1K/DlynFoAdagewU+0C dqtjhFfH1V3A69TrgTek7CJcyt+n/D1RpPSk/Ax4n+ZFwmuK6WlJ82PNTZwOfq+5DfxpKiSnrkp1 EUWqW4vTpDZNm04U2gxtLvAs7Tzg+dqfAPdqcYLR/qP2n4APa48AH9W+D3xce4Lw2pPaa8C/095A ///UDgL/Ufsp8B3tHeDPtJ8B39V+DnxPi8jqiO4wThy/0B0D/u+6PwAP6v5IeN3t9HGES89Mn0QU 6ZPTVyGSSjmePHmKeVjyreRV2Z+wqxIWVWngK02NBhZpajX1wI2a1ShbNFaUTo2I0qPx4W5Q04ky rAmjJ6KJAEc1OLdpujTrgTdovg+8Cb6iXhqUfcLDG88A52mfhS0F2gJm73Xgf9H+C7PlCMqjuqOw 6BjsolY8gXJCOk7M6RPTJwJPonbJ9qSRrdwBomq0NTYR/WrRZiJL1tia20mFsbnJRupNjYIZ5/E0 wq2sLNGTLKyaBP3ZBtHKSEV0zDeErRT6c4z0pDaH83zGSJvDqoKk8qoyPZkgc/A42Y+TsQJ3M8lj 7c02MzGy0sxKgZUe+kpEQqxcx8pNrNzKyt2sPMnKSx3tHdirWTlES07NygxWTmDlNGa/8qElPxJr qeZgFf1JDP3lgxTomwbrdbCLUG3JePI4/PIELJpIJpHJJJs8SaYQ+jvE07HvPHzcw/p4+u/Lf6Ee R/+36K+oZ2HHq8OOZsLO7iNR8ibZQraTXeQd0k8OkCPkODlDzpPL5Aa5Te5zSk7HZXO53AKuhCvn qrg6zsZt5XZwPdwebh93kDvGneQ+hO0c4bgN0A21VoCGqNOPSPW4XnpGJ1xmmeQp/Wypnr9Lqp9z SvWCM1L9fJ9Uv7RdqkujUv0do1RXHCNKOJh7ZQVRw8nc92YQNczm3tgg6dFYQmcjXNMkqd1UItf1 cn1Gqg0HGJ+y5UzLtZb7azKl1prAms1retYMSC1jrnGxcYXRILVac1qLWitam6TxbTOluj1Trq8z Lo3piOms6WaHsiO7o6CjtKOO9Y4zF5urzW3mgHmzucc8YD5pvmS+Y0mzTLMUWkottZLG1hxaoi6X JFqrpHptvlTbDFJtPyvxOcrlugoepjWeEqmLU8P0ZzTkAv0fkrx5oELCeQ+jXghaAvwuIf4K4BLU VajxfPGuAFWD6uR2k0xG8J9EbQYJMnnkOiQTHlneN2WieDPGnEG9TW7HCeecItXec6h3yLQLtBu0 F/0XUe+T2wcICRtkaiNc2IraSdv8RNdZsVQsEivdvINnlC0aGC0RwzKtYxQS+xjFxY2UHHkOnpJ7 r0xx8Zo4X7zpuiCWuy6Lla7rqG+JlWKu2EfJdUescd0X6ykf6LZb7zpGCf3l6E+ev41RITCVr5Ep B/yUMoAp5QFTGtFTuCzRiN4bGZUAS7SRkVnsYSTIFGc29bnflIkX9zPaBl5Kw+0dwDuS2rIfvtTe 9QgyQ5dtoAPCcfdh0G7gvaB3gU+CzgmnGVHbLoIOiAcZXQUuBA1BxtCo/8U04TIlB3xJSZwgfiiR cIHRFPESJTaWUjb1McbNQH3YkSHmIz75zAcsfqhvsno4DlJMrO4bGDso6TMc25Faju1wLEdkDvsU 8WYysyArKyl2D8ZyNAecjL4q9guBF/7F8T5Gy+BXSk3wGaUVwJSMwEaWH8O5skWm4XY3o2rguofy 72TkQf545HyS6B1GHpmGc0zud7WIPQ8j92b4aPMX/PWXaZhveE2O5ChspzSSw8DbktoP3n9UDu+D rR7QGeTlGYwbzk1KN4Q77kHQSL4CXxxtO2i87oJG+LGnDIKS8/tuUn4P0w62RjY+uM+ISnEjJfdu 6LE7qT28/wyJRyg58jxVlEZsGd2fpLY83h1nfeW4l8GI3ae8GLs3afzwfPI6YzqDxEy0M5PaD95P E98DnXLoRQMlrMGdjO6JbZTg70uUPNMkGr2PsSDPTPSDkvavdZQ8BPpgb/TMltYxW8vyehuh3C+S Z7FMxRKN9JdJlLT26d5800PENkpJ+XgzeW8Q58PW+cItT4VUPyq/PDppj/OMF8s9k8Qj2J/OY30e 9Mwe9bPrtLjUoxZ7KA3P6ylwZHgWyGuarWvXIUaj6/4QowfXvbxvdO4WfZRG265DlL70rBm9f4wR dJVpI6Xhdd+5T7jF6EDnYUpus7eQ0fC6lO3ufBfj3qW5A5vVGId9vfOMtNd3ngNdRPsq6Abu60bb o2sFOg6CHlg7iN1GSp3noCvo4W26XqQ10DkofiiRcIGSOKHzrkSOEkZThFuUhv3SOSReohRWuo4x SgNOG20/+KwJZ4p9lB58dg7bj7cmLTs/E3Zy1rAzcypOtvNJhmohzrfj2Mn2cZxpXyXZ6mqcbPXs TDuDnS2/wU6G+fTv/fjf4yxOFNMVM3C2/qaiAO+n8xQLSKaiE2fuLFUuTs/rVItVH5AfqH6l+hX3 DdVH6he4HPUS9be57+N8vIb7G3WrupX7sbpdbeJ2qG1qO7dTm6pN5d7G+bWf+zvtPu3PuZ/oOJ2Z +yneu2/xC0bf+NYWgZbinfEU6lIQ3hHXfkiIHW92aytR461ubQ2oHoQ3rLVtctsqkxP851H7QGGZ 1sn1Rpm2gLplongnxlxC3SO3txDONFuq115D/Y5MfaD9oIPov4n6iNx+jxC3TSY34dwB1FHWfoLk 0W8FSAWpIU3sZ14hsgEnlh2kl/ThvHKMnCLncFYZ4jREsXbJ2sK1JWsXrl3WgTOH9Zr1ZtttSxPQ devltlsWK9BF6znrVUsF0IfWU9bzljqg49Zjlp42OuKw9YBlu/UM0H5rn2WzJQdoj7XXss4yH2iv dYclYBkP1GPdYhEseqDt1g2WNvMQ0GZryNJg0QGtszot1ebrQAGryVJuvgtkxN1i802getxdaL5M lNZ+69vWTdZe61bMsd10Dz291gbgFtwxdfS2TQJ3gXW2Jc28AyjHqndNMR3/N8tSFfs5EGE/AeLU AXWMpLKfhTzGfpLxOPJqEhfGqUJHDiIGxIz4mhFL2EDMtxEznMXM91CnEWLBscyCky6sJ/CP1J4k E87Llpmg2TIVyPUCmRaDimWiuAxUIeNhqpKpFtQAagGZZIyccWbLhFOzM4/hvPbF7cXtZe3F1vr2 CquhvQpXLaMG3Glob2k34bKhdqMMgOhlao8Cb2CIXpsYH8gx2Kpx3HUMtdKf7j0G/w/iOH2b/5Tw /GeIhZLFQs1ikcJioUMsFpF01QsjEclERL5LJqpfRVyeZHGZoq5V15JpiMs7ZLp2D6IzE9G5T76p HUKMZv8/nIkjS4nAYp2PkyjpwEmuYzMIJ7gOnNTWXEWN01oHTmdCEdG0FbUtXWNFWdpWuqZPYOd7 /o/8H6HpHf4O4VRFqiLCqyvVlUSB3FtFlOrXkYEq7T9o/4GotX/W/pmk/KvGcBkD7GcABnKaU3Jp XAFXzDVwNm4dd5rP5Jfx6/iNfD+7DvJH+NO4rinSFHpFPq75inqFUbFHcV5xRzlfkaZcpjQo25S3 VPUqo2qzartqUL1Q3aJ2K/LVbzP+fPUp9VVcN1IWpLhT+jQzNUs0ZRqnZpvmtOZaKp86P3Vz6vG0 4rTzWl6r1+Zo87QLtFZtt/Zd7QWdTlesM+jMunW6Ht1x3b10TfqC9Kp0T/re9MEMTUZRxtKMZRnG jI0Z2+Fx+g0Y/QJsEf3iCbQ40c/9IfEW9znoT4m3eA6UmviET0v08+MS/YgS/UYslX3bRb8QWzR0 l30jtjhRwr4SqwXR76/2JejPS+i3YvSbqcdA9IuuFHlcCeYrYd+K0XH0a7F9iRLG/9YX+FXsi7FF IPrN2GIQ/WpsPPsai34zlsl4jeybsWn0GzUQ/WaMfjFGvxejX4vRr7vol2L0OzH6lRj9RmxYy3GS JNiQidZjqKfi7jQ6O3Bh4iMmSZLSPyKlhulcQjJkPUrYF2FUZ/qF2TT69Rw8Qr8wo9+XSfO/xb4s o9+V0a/Kxo14JlO2dmReUAlGl4GkOaeSV9FXhbqG+XgqYrCPrGUx+OLs9Iu0MjbbJ+D/BFz03wKn X589BuLIz6C7AqOoH/pZhFT8nMQ8fgGoHPTdoSBflZiHNShpp8E4DXeXfJ/7fGgQ2aDjuaFBPjsx QFTIjzb0DCA/2pAb7yM33icK9FagdQWtK4TjZyb+B0mjMeXyEuu5OeBUJdYjmxbxaUP3+HGgCYkg j7iBcy92mGE5j3H5iencs6C5oHmgu6QDOtzEjOOhw00+MzGdH5/o5R9HVk5CnQ16EjQVsvW4Nysx nWhZNsHKrzW7WtbzfXD9Elxroc3z0OZ5Mg69vRhfB60+hlYfQ6uPodXH4OyFJh/zE0GTQdNBelAO aBbomcTH8BRmf3BmaTZ4uBQeLoVlH8CyZ2HZB3juFSZ2kKeSMrw0OcMh7RPo8gl0KYUudVwB6rmg eaC7xIUILIKsDsRlEWb9hE8HQQaPeWCvEd7aCm99Ak9tZbbr0f904ofwgZH/BvpyQbPQNzuxlTzJ NJQ0KIUGpdCgFBrsgwa9j4yRKrEPs7//hVhNQBSkePV/KV488xv1WRpkr4fs9ZC9HrLXQ8Z65mE9 6hzQLNAzifUsZ6Rse+L/SK+vyiGaiQOQNgBpA4iMAxIHMHIAI4/CmvUYeRSaDWD0LzH6l/Dpeowe gJYDkDAALQeIFlKOQspRSDkKCUchgY76LTiP8jNAOaBZoGcSR4mSz8Kdp0G5oNmJ3zJ/9GJ8L8b3 YjzNul5o8AHLvEmo9WjPSvR+xUzTE7946Ewq7HxXsOtdIT9NBMnuxAnSB8LukujGHrsvUc6/mDjB lyW6+b9G/TLqcvQtB1Vg5Xx36J/519Bfiwi8ntjGvwFsRN2O2gTeDpA50Ucy+SJwLEn08Utx5yUm cRDSBiHtCqTth7Tf8K+g/7sYUQW+VYkDfD3azbjfAY0yICGYJKFPHlmbNOqHGNXNRnXgngW0FiOn IIMnI3snJ1sIaU9BGqwj8/iXht7nS8Fdxiy8AiktsKicr8Ms9cBvJAx8E3BzYjLfgnoNyIj7bdCo A9iB2glyY3Yx0ULUTOpyMhlWXeFfA34DuJHMQ66+CPQSclUr+5XOeAK2/Bq2/BY23MDMJ+DLbsy6 DbO0YAYD3lOWJCKw/ArG9oCTWkx91DfsI/hnWNbyxEeY1wgOOvdkFps3wNmI2gi5Umyoj07wLoxU MS1fZ1yD4GB3YEMF66FjrjB/roUMF5lMdPBdN/TpliPRzb+MWZYnfsBXoH4l0YCZT8iRuMI3YMRE RIAgAoTgeUamgXbDJ0XYB5ckvgEp+yWvDJ1AFD6GHbeZxHIm9QT0+DWkDse2T9YJukOGiCdFxog+ LzHrr4D7faZDFbULUqj320EmKZdgyRVmyVToNQ96zUNmdCMz3pclBZlVUkZcwfwfME/TuNSxuPQh G07wBub5bmQEzfldfCv620DtIJr3FpCdZUd3Unb0kRysuD6suD7spn3YTfswOzyC3GR5OSRCg7nI DsQaT1q68mg0X2N5WY449UGLGv57oPrEC9Dmab4B0hvRbgKtxn0DailXa5CrNdDuaWhXA+1qoN3T 0KyGt4JsIDvIDRITL5BUeY2Vw/4WvozGgHnUAG8Gmf9hL0mRM3cbsq0Puq1luhkT/0TXAp74Zey5 30Hod8D72LgY3pIoKsIOtQS7/1LgFzH2pcQeeHlP0ipoQew6MNuTsr0/JGkYUcUyTVo5QaZXBfpf gQarIG14BWghvw/cLeBeyyI4bMEreJZ9V14ryEfGreKbyXh45Qqy4n1ovg1ZsQcyKA/NsAYm9QR8 +JG8Avrgtz62CgT0i1gj6WzVMKnYTelO1YJcNWIVSdlGV9IA9r/bSaOu4M1K3o8wspvN1YzZW+Ss pnJ57BWTaX5jFdI1RKXRvDWjtkAfuqulyCv2CuOlI9vxRMcdzHMFkaxHqwFE77ZgZzFCi47Er6DN ILg+Atev8Xb0U9hei533dWb1CXmPuML2iA6MMrPVspftEwpwDrK7dO1okYUnMMtR2VPU9o/lFUY9 Rce9Tzlh0cfQtl7WVPLpb2ROaYdO5WtxZ3ilYp9kd8wje/hHbMZ0+K0Ffmth3PLeMiKT6tUmr/MO puM85u3MkTU+Fa1pILr31Mo7Xj3y6Q1kbgOLwomRKLSjzyxHQyVn2Al57/hnJlcny+hL8htd+0fl uPfR5x64u+HpPuY/juqK2JpYv4H5ZCtm/gFkf4KZb7JMscDbohzB7ydlIeTLO9gwF3IKb/LD1u2G 7BS0nkPrOdh6AraekHeWPvZM50kh+06B0N/xwRN+JqFf0s+iv81DnsWlRL7Nw/vAc7jU5HlcKWQR wVmbLMaVxn4LRktW4tKRVaQW8aijv9dCfoYzRib5BTlCxnPPcHNIFvcs9yyZyM3j5pFJ3B+4P5DJ 3KfcHZLNfc59TqZwf+L+RKbSfyaVTONVvIro+RQ+nTzFj+PHkVx+Ij+RzOKf5KeQ2fx0Xk/y+Jn8 TJLP5/A55Fl+Fj+LFPDP8M+QuXw+n08K+fn8c/RZgt3hOb6ELyXf4suw7pfiJL6CvMi/yleRMr6a ryHL+Fr4fzlv4A1kJd/Ct5Bq3gifvsa38VZSwzt5N3mDj/Nx0oQz/DqymnDjbz5Of3NBxx0kJkKE NpAV5AT5CN9+HnWYkLrbhLQfJKTtrkS0LawDbQRtQfuI3NcN2im1hZ4R4nxxwr9WJVH7JdA19L+D +uZofzIl97fflut7D+evPiX1R85/4T7Tg9E7sm5Ulz7Cm9SEVL83youa2STsZ3xsHjYe9grUjvdA p0Afyu3zMr4EonZgvHBb4hn2DeQzahPQf4/18yadZAsjjHGQ0fkdaokXxOamMtp2PJTYfSrvtSr+ 1/Zaz7lwgb3BczG8wN7iuRpebDd5boSL7TbPYLjM7gauQP9d9Ld4hsJV9oBXGa61N3jTwg32KHpa 7Bu8mWGTfZN3Qthmb/FOAc9W74yw2+725mIscLMR/PnhgH27d344an/bWxTeYI96l4KnFzNusu/x lq6utPd6y4F70R+w93srw1vtA96a8Hb7IW99+G37Ma8h3Gs/7m0L7wG2Ap/2OsP99rNeX3jAfsEb Dh+yX65pCB+zX/euCx/HqI3h0/bL3i3oueXtDp+13/HuBM9Zbw9k3ve+E74g8N6+8GVB490fvi5k eA+Gb60s9h4J30H/e+H74DkV4YUs74cRzcoC7/lIBvovgT/bey2SJei9N8MFQg4tqd+a9wp53tvh MvTcQ3+hj4TdwkKfGmXIVxDe/oUy7lswUoZoSa2L5Ahv+haHe79QbvYtjuQJ23zF4WPCDl9ZpFDG u1i521cRPiTs9VVBTnK5L6k84KsN3xcOs1LC7/oaIguFk76WyBJhiU8XybZvZdqe8ZkiJfazdJSz 2C9EJwglvvHDNsoW3fBtiDQJWeA0Cud8tsgyYdCnjpiFZYxH8oCEVzBc7b0d0Qt1vknhWrlskvE0 lEbfTMhMLs2+2SiFpPKubxMiKOUYi6Yw5NsajjqUvu3hW44039vhBY5MX29EkPJWuOhzR1YIHowN wF4b4nXVF4hUw95opM4xwbcn4nFM8fWHBxwzfAOREM3JSJxGf6UJsx+KvOnIRSzyhrHvWCRPyjrZ LhZBumqMOTQ/I5sd+b7jWC/HMfue0bUT2UazNLIDGp6Ghrk0jo751ApHke8stch3gVrkuzxqne96 +JhjKfKnylHKIruM5pKMjcz/LL6Oct+tcMBR6bsTvu6oYbieYtkzBuoZusoiu2g+R3Y72nz3wxsc Vj8fvuNwMq8e8DUgE8wsPxl2+ODJrY4wPJnlWAe8wbGR4S1+TWSvo9ufEdnn2OnPihxw9DA/xKkf HO/AS0bk6rFwr6PPdyi82LGf4YP+7Mhhx36/Hjmc589GJkj5vILuKuABlmIBi2gsjgAbkbEUv+e5 G3nXccqfA7zUnwdvfOgvDB9ynPcvrNM4LvmX1Okd12gWOW76iiMnHbcZvkexlFdOgpVyhu5UkXNO dU1D5KIjzV8SbnDq/MuwM2DXaj5J94fmaud4/4o6PfV/yzqaXSsb6A7WvJfuFZGrbDdbzPAN5yTm f2lNSbEIUUx3tpYw3UMig8mZ6Zzmr47cdc7010WGhBzqZ+ds5ueeUSwsG/U/3Q+jSrrzROLOAn9T NM25wG8Mb5IyGbHGWnMu9pujme42f1PslttK77qd/qbVlW6f3xjRuMPov+Nex/o3+mbH7jvCoZI4 b9/q92CnPesPQdtooBwz8oFKzIgcjmuQpTWRHdBk/HBuu7d4BuMZUvYKecjeMvQvhtUraBzlmDI/ I2PLkL3Mz3TvjS2gu31USffYeJZjKVb0YiljqXXxbOyi78X1yN6RDKS7fTxH2lepztTSUAlwNzwT cO9k65fpJtb6CuJDYgONtVONWJ+RdwwWBeYlWaazzB+PTnFlBbqjB50V/jcjS5xV/s3RGc5a/7Zo Lnp2oKfWv4therfBvzua72zx743Od5r8+6JFTpv/QLjY6fYfNlwA57uM8yQ4A/4z0aXOKIvsBv+5 aKlw1X9x9U3nJv/VaLlzq/9GtNK53T+IXfSy/274mPNt/1C0xtkbUNZphJOBtDq9c08gM1rv7A9M iGQ4BwJToganLTAj2uY8FMiN1IEzP2p1HgvMjzqdxwNFUZ/zdGBpNIyxpZE6uo9F10nPUOlp5Twb qIludF4I1Ee3OC/766LdzmjAAN2uB9oiQxRHdzpvBazItzsBZ7THeT/gi77j4gPhaJ+9P7AuvFV6 lrk0gY3R/a6MwJbofrEldKZLKZpC57rSRFvoYlem6A5d7ZogBkI3uqaI0dBg1wxxQ+huV664KTTU lS9u7VR2zRe3d6Z1FYlvd2Z2LRV7Oyd0lUrPaHFP55SucrG/c0Y0X36LYM9reR/OpetdHPDndVWK h0JNXTXJ+UNXHFYEVlw8SzyG94EL2JmvxaL263QVi8c7c7vqxdOd+V0G8Wzn/K4ZyfuJeKGzqKtN vNy5tMvqqKE7Kvqxi4rX6d6FXY4+hZP2c6Ga5rZ4i+1RyfsV8rzLSfO8y5ec88hh7ACQM7obSDtz Gt2NxTu+O11h8X7SzizQlQ57kZ/iAFv1h+lTOHmX9vCdpV3rPJrO8q6NgtGfFw+5z2PfO+3J6Kzs 2uLJ6qzp6vZkd9ZH36Ox69pJY9fVg71l/PBunPTcycHzeubwfiUuxowm7DlYTa7swM7ICpc+0BM9 gvKd6BGWXUuk9YKyj66awP5InSsncHCkPy9wJPqeqzDwXvQUylMoFwY+jH7oWhI4Hz3vKglcina7 lgWu4U2Mxde1InAzeslVHbgdveaqC9yL3nSODxLk8En6nkZLyG8KqqP1LqNvU/S2yxzURc64hOD4 6D3nHpT1tIwRlyc4KaZ2hYLTYjpWjqfvcijZniyVrnhwZmySbNebwdmxaa7NwYLYTKctuCA227Ut uBj67wgWo9wWLIsVuLKCFbEFrFzs2hWsihS6dgdrY8WuvcGGWBnKllgZXV+rb7r2BU2xCteBoC1W 5TocdMdqXe8GA7EG18lgNNYiRQ12bYCXzgQ3xUyuc8GtMZsrO7g95nZdDL79+n3hYrAX+GpwTyxA 4xWLsnJDEo66bgT76wpRDqAcDB6CnneDx2KbpLdo11DweGyr5Ge3Mng6tt2dFjwb4d2ZwQurzmH2 y5E694Tg9djb7inBW/DqjeCdYWnuGcH7sV53boiP7XHnhzSxfvf8UEZswF0Uyoodci8NZceOuUtD +thxd3koJ3baXRnKi51114QKYxfc9aGFscvsGZFB33Piee6e0LJ4of1QaAXexnFewLMDb+bxhXhe XIwvcb8DXOLu8x2PL5Pel9z7PTfiK9wHvW3xLPDciC+h/fFq+o4Ur6M4ckPiYf1N6B9EP3vu0EyO GyXsPgKZZvd7oepwv/tUqA5rfLOvPy44+ui7gZu9G9CzSdxDTwGRG0IhXTs1ppH+OO2Pv0kxnuyU 52ryM0swQ06L+3yoKXzafQn82eDZCN2ugX8bfU+Ib3bv92ZCT7whxBY4DoaM8RWr6nxnYwtY/zba H99B3yLiuyQe982QOWxz3w4J4bPuexSLhGJ6ShrOYZwg7kXMWJUV8d32Wu+U+F45qyneRzF8ldQv VIc84QpRHQqFLyAWnnihqAuF1vSL4+k+A59gn6FvI/Fs+jYSP8DwYYbfFSeF4vTNJPQm3gzxBIkv pBkePykMhTaHozWHQtvCt5Ix5Y8vpPzgWYHzWpk4LbQjfCd5v6I4fobildu/0E+f9efYs/7i/yLv ++Oquq589znn/uRXEIkhxBJiiCUG8MoziHe4P7i1Vm+4ljoGL/feEkuMpdRaYowxd6gBapE6hrE+ Y61jrbXUWksNzzGOZagxljLU57PUEIda48caSxlrHWup8TkW3lrfcw4crhhtp6//zGd/1trrrLP2 2mvvvfbae5/744CeivPURSO9ZntdS8Oml7Pq9n1R5jNg41Q+bTVmqnuYl6d9oaqx/2XH381tvMzn L2pRZl3bF1e8XFB3KOJ/uaiujWKsr66j8RpFNt7nH6I9QzvthEd2sHx+bLRhddsH+gbTTy+CJ5S9 PK/uWMP1lxfUdTf2U9xe2dCurgIvL6o7ua6iqajJ1zQvurn+yrqK6Mb6gYYTqxfUL6XVeX999ZfE 6qP1NV+MRDPrV69vXbO0zv2lSyqOTq2vXX8gmlPfsP7wC6H6pvVHovn1zes7o4X1W9Yf13b4u+u3 r+9RY4s696Pu+l0Rv3bCVc+26qnWeGJVz6o4pUbn1O+JOatiBY/661vXn46W1h/40rJoWf3hdd5o pP7I+rPRyvrOdTejVfXHaZ8GPdEV9T3rL0RX1Z/+0nJ1/qozketdP6CdptnnC1VPHhNvRyxZf8UY IXnsGs7xGbkxU20XIkaqer5W45I6l3kFWT/IK8j6QW2mYw5Go3+3dP3NaF392Saheki0sf5CkyW6 rX6wKUF7OoEnBtGd0TNNKerTiWhL/U3qW/VZBE790X0Noikt2tZgoRrxzEHtN/WpgrrPjJ5syGoq MJ4oNVp9XoEZFD3UkNCUEe1oSGnKih5rSGuaFu1uyGhy8H+I4LdhwvDbMBm/DTPZfLagMOP3YJPx e7BH8HuwLNtqW62YbnvF9veiAL/1+gh+61Ua/3i8QyyK//f434gIfp/2DH6N9iyeQGYJlxBijvik SBeVol7MFF+mtEhsEl8RT4td4ptisdhDqVy0ijYREj8Q7eIZ0SXeEZ8S58WvxPPi1+KyeElcF8Pi C/x+FLFe2iBtFG3SVukd8U/Su9JF8XtTtelz4j9NLabviGFTh+ktSTGdML0t2U0Dpt9IE0zXzYp0 vznL/Jj0qGWDpUN6zHLU8pYUtPzI8iMpZOm2/EwKW/7NapGes9qtD0ivWT9kzZBarI9YX5H22F+x N8pm+5ftm+VE+1ft2+UH7F+3t8oP2V+3H5efsL9tPyN/zP6u/br8cft/xqXKn+HvTMpfjE+Kv09e F58S/4DcGH8u/tfyxoTPJ3xd3powmCjJP05MT0yX306cnDhF7k18PPFx+ReJOYk58lkhUb9U4ztR GfydI/9kgikE2QR5It0/xZ/tz/PP9Dv9Xv9cf4l/oT/or/Av9Vf7a/yr/bX+BqKa/M3+Lf7t/l3+ Pf5Wfw3/PgtjK2wfsX1EyDa/zY9fsqXIOXKOEHKhXCgk2Sk7hSx7ZI9QZJ/8EWHCU1WLHJADwio/ LT8tbPJiOSTs8jPyMyJRrpSfFUl4nposf07+nJggvyi/SDpfkqNiIp6qPkD9nSXSLD+z/Ew8SG3q E+fQshT+lVrJBlFZsqFkU8nWkh0lu0v2luz3p/rTSw6WtJccLekqOVFyqqSv5Nz8WyUXSy7R1YmS qyXXS677oyW3yCBbICmQGkgPZAamBnIC+YHCgDswJ+APlAbKApFAZaAqsCKwKhAN1AUaAxsDm0tu jSYqp6YcLZWOpFVa2hbYSbAx0EKwL9AWOBToCByj1B04GegNnAmcD/STxOXAtcCNwBD/Asr6berN SWP8nP91YaaoIa91ipfJ533w86fIv9tEgDz8B2IB+fc74uPiEqVS9NEnrI9aHxMLrR+2flg8bX3C +oQos+Za88Riq8PqEOXWAmuBCFmdVqcIW4usRSJi/Zh1nvikNWyNiGesFdYKmi+S2EEziXt5ijAL Mb+D4JgG3ciL5h+ef2R+5/zjhHvmn55/dv6F+QPzr8wfnH/TL/wWf4I/xZ/mz5h/xJ/ln+Z3+Av8 RX6ff55/gX+RP+Rf4l/mX+5f6V/jX+tf59/g3+Tf6t/h3+3f69/vP+hvp6uj/i7/Cf8pf5//nP+i /5L/qv+6/9ZT8lP8HUbJ9rztRfwmMG5Mb71Maab4KaUnxXuUCmjW/0rMEgOUCq2l1lIx2/q09Wnh tC61LhV/IySaRXH49vE0YRVi8UwCp5BCnHsJ5grJc0FI3uVK/uK80OTFM0NTkOu0M5S92BvKA8wN zVxcEnKC5nsLQ17I8bUux9fB0NwxeipCJWN0sg6WWRpaOJJXh4Ij/JpQBa51enVoKWj9vl6G7dHl +B7r55yB79fSda2hXqYbyMZag1wscLlYYBuMoNcXC7ptRuC26/2iy+l2sS163+j2M79Js5VzhmZq pxG4nA66Lga2jdvJ+Raqm/uHy3Mb9Dr0tvN4sX2sg69ZNqiVYVm9//QxMtqo69keqh7pW5ZrMuS6 LbtCNcj3hFajDOvSc73u2pj6dNu5HI8v62sN1d5Wvimm3gOhhsWHQ02Lj4Sax9hp1D2erZzrtui5 13DN9vC13j/cNj1vjrnmMmyzLq/PBb6nz43O0Bbk3pi68u7Qfr29eTHt1691H9LHluoqz1d5sfmI DNd5PLQ9mBG6EswKDd7mHx+Qlxfe2/0xcrH9fQ95udtwHdvP3pjx+oAcdhj51O475lq/xPZ1+Ry1 n+6W37Uf9XYYfZ/r6QntGplrp0N7Fp8NtYLWcz1+6nP5QujAyL2B0GH4ypXQkTFxeDDUufhm6Dj6 TPdHqjsoQj1BS+j0SBvpXjAhdDaYEroQTAsNgKfHByobnBa6GXSEBXxR90nKgwVhS7AonBD0hVPQ Fm1uBeeF0xjKK8O3yqsiMsuXr4jYyldFksqjkVT21/K6SDr8luopb4xklm+MTC3fHMnh8iO+Ot4Y bzHMG41fvo3qOxHegXp2jtYxcr8lkl++L1I4Jn6UfIBvNsfM7Vifio0psXFJ7yPyo/K2iFu3u/xQ ZE55R8RffixSOhKHdBtmxsQhwxoVXBDOYBhZ93Q/0a6Di8JZwVB4GmBJ2BFcFi7g+oPLw0WAlWEf 9KwJzxuzNrEvrA0vCK4LLzKub8EN4RDWXB00+eCm8BLo2RpeFtwRXj7ijzEQ3B1eCdDtZh/aG14D m/aH1wYPhtehf7S1O9ge3qDr1udP8Gh4E3R1hbfy2GJ8jXWcCu+G3/aF93J7uY3Bc+H9Izovhg8a +yt4KdwevBo+Grwe7greCp8ol8Onym3hvvKk8Lny1PDF8vSFa8ozw5fKp4avjsxh9gd9PI157Ljn 3SWP9a+ZMbnGL/fTXCgl+43+pq8T+nppXIti1yTy1/IyzV/Hk9PXIY6tZYa9gpaXR2g/R+Ot59jf cX63dn5QrOX551djiZ6P9F/sPiN2/dPbxtfNMbm+t4mJSWPyO9lrnK9bDPFAG/eR+BO7rt4pbsSO J+vW69fmMPf3SudK7217W+6X7khZeU74OgP2MAx6vNdjAwO3mf3kZCQyModZl2GO6vNvZG/M9uh7 ElonynsjlTzfed6j7jORKp5/Rn3l5yMrbtt7G/bc5f2RVWP2y1qMGqlfi0Uje2e2+XIkinlJ87j8 WqROPx+U34g0jvSbZmf5UGTjyHgZ9q6h5MjOMT7La5TeR1QuZIpsDsVFtvEp3vaq7R+EiJ+B/xe6 HH9Z8H/jTv3rPl8xK2IYz1GewXOUT1mOWn4kbcETlG14grIbT1BO4QnKL/EE5T37K3Gpsg/PRfrw XOTneC7yCzwX+SWei/yGn4so6fxcRMnm5yLK4/xcRHHwcxFlBp1oW8S+0acHs1vFvNmtsw/MPjz7 yOzO2cdn98w+Pfvs7AuzB2ZfmT04+6ZTOC3OBGeKM82Z4cxyTnM6nAWUipw+5zznAuciZ8i5xLnM udy50rnGuda5zrnBucm51bnDudu517nfedDZ7jzq7HKecJ5y9hGfUzslgZSFxFdbAUwT8JMAWzn/ UjLmbBulEfmCeIVOtfspzcY51yl+Jk7RSbaXkkv6iXRcuE09preFl59XUUlJBEXFaHsdx8WUWWmz MmZlzZo2yzGrgPIioopm+WbNI+6CWYsohWYtmbUMsNwxMGvlrDWz1tLVEsJrZ60jqYxZS2DjUrLx AXwXUJD38L+/ZFOS6Sw9TSgih5JJ5InpwixmiHw6Xz8pCoWdbJojEsVcSkliHqX7hJ9SsiihNEEs EB8nSz8hFopU8rmgmIR/qksXqyk9JNZSmizqKH1InKCUQW1/WzwsJUlJ4hH8F9fa0bbOiFPyXV7X XFeJa6Er6NjsqnAtdVU7ylw1rtWuWleDq8lR5Wp2bXFtd+1y7XFNcrW6DrgOu444Ls9wujoBea7j rh5Hr+u06yzhC64ekhpwXXH0O7a5BulOVUG344brpuMa1eMl2SBrde1xXB5NbourU02OXkevO8Gd Ai166lGTO80tXE3uDNck927oanJPcztcN8keL2llCLqqtdSEtIcTWbWaYDvZc4SsWOjYSSVuupLd WdTa465qd4G7iNrfyUAt8pI9Pvc810KiF7oXuBeR1k5o0KGBrGFoItu2OPoBpN0dci+hXhqkOnsA XBuD98ku9zLWq9cCjTqwDQTu5ZQvpVIM1VSLBu6V7jU0HqddNQWy66w7w73W1eBe597g3oT6YcP0 vWidsW4C91b3DldrQTe3lnqUKR24/VySJb2efNh2G4zH9+S7N3jkMfYbAPfIZk+he7fH7ZkzYqEB xuMzz+PHePXEAvM9pRhlFdgO7hvNfvdex7YZTvd+90HCDO3UT500ckdnlNBVl/sEjecpV4W7z33O lUyeUQM/7XFfpDG8Qj50yX3V0eIacF9HHwbdt6gN1JMemyfJk+pJpxppDD2ZnqnFW4t3eHKKdxfv Ld5ffLC4vfhocVfxieJTxaHiPniiNpJcQ/G54osMnsziS67Tagm+V3y1+Dp8R+9Rvfeq3QkjrTL6 ldYLxbd8ss/mS2Lv8KXOmOu4VnDZlw5f3eDLRAnqmxkzZ8x1HZ7hdGzzbvfumuH07vHucbQgXfO2 UhsyvQe8hx0tnqmunie7aK5V8Xxz9HqPeDu9x7093tOuHu9ZigaTqK8a3JscOx076c4FbwnN5o3e AdJyxTvobXW0eG9Ov1UsyLaFxZbihOIUgrTiDMdl0nSEtG4rziqe5moqdhQXuHYVFxX7iufNyC5e gDuLqL+WFC8rXu7yFq8sXlO8tngdxR72trkznJ4yT8RT6ami+WDhGUjXKzyrPFFPHeWNno0jntbl 2ezZ5tlJHrfZsZliUIU+ezwt+izy7PO0eQ55OqhvU3hMXDWeY55uz0lPL3knwxnPeU+/5zLFuQsj gLntuea54RnymrxxsZ5K0XCAgcfGm+ydBJjsncK+48325sGHdJq8yDvT6/R6vXO9Jd6F7pA36K3w LiXbN454OGn0VntreFZ6V3urXQcoVjIcVv3OW+tt8DZ5m71bXIM0b29StPRXbuVo65vqyyHIL95Q vMmbTJ7sdZX4Cilq7/KWPNlV3DfDSSnP56Y6Bhz97hSOxo5rvjk+v6/UV0ajvtk1QJ5y2RfxVfqo v30r3EW+Ve4+14Bnsy/qHSROna/Rt9G32XvWt82309fiaKQ4VjR9t2+fr813iLxkD2JuJ0cnX4fv GPz1MCK9GimriHPZNejr9p3EWvjcf6MdVJWowTNz/rd7Md0tJILU6U5KXkpzp8/N7s7unl5CaSGl IKWK6RXZ57PPT19KiXnV07dMr5m+/fHqx6unr6ZUS6mBUhOl5unNjzsfd1I9su0Z2xL81+JHxceo X+eLp2hfEaDdgUX8LfVePPXzJ/m/HhIGEq7BInzWVXRMSJ4I5d2UVyr5RR2esqJjBB0aMN1NcFKD XoIzGs33zmtyJw1yfN0fo+dyjM4zmsw1Q37DwB/SrjXaZdJo/b5eptcgd0bTf0aDa4Y6je06GSMX C9fGgaEY6L9D2f5x4PI4deo2nTT0jZF/zJAf09pphJMGMLZxSJPXbezVrq/F1HFGG69+TccZTVYv 02Eoo49RbHnKXXEGO6/F5JotrmQtn+QZ9Y2OmLrHq0+3/YZWfvI45WPqdU0hyCbIi7HXqHs8W68Z bBkv7zfkvVrb7pSf0WzW5XU7h0btds2MaX9sP8S2P7bdsblxfp3R6tJ5sXnHaJ0uWlldzQRbxh/f v2h+p36/1zy2nz9ovO6Sc7vvmsf0sd5Pd8vv2g+x9uv6vaNj75pLUKLRJQY7DL7sWmiQCar95Krw jInDtA8qc1V7RmOGHk9rCFYb2shtriVoIGjSeHp8oLKu7QS7PCNzcWRO7iFoJTgwdoxdh1Wg3VWZ e68q795PcJCgXfVF91HNJ6ke2guVuU8QnNLap/vqB81FAx91FWn1GOrQ77v7CM7FjOkH+ebdfC02 powXl26ofuS+OGq3+xLBVYLrntvjcmwcMqwXriMqjKx7eozQrl2dBMc16CE4rdV/VoMLmp4BQznd F64QDHrGrG+um+qaq4Mu7xZaf1oIEgztjwF3igojdlM/utO08ckgyNJ8SFu73dNGdevtdjs0XQXq 2GJ8jXX41L5yz1Pby210LzDoXDS2v9whgiUEywiWE6wkWEOwlmAdwQaCTQRbY8akf5z8TuN+p/xe Y1y3Z3TtGG/tuVM+nr+OJ2dYl8fNz2vjHZvfrX13i7l6LOn23N5/4+V6m+6WG2LRuPm9jk9sPLjT mnmva1q/oX59z0f9G9rouW1vC1+9RbBDBexhpsTUa9wHkn6P7BmdwzfGzlF9/o3sja95RvYkvE54 bOp853nP8p4kdf4Z9XlSR+2L1c16PemGdmn6jfFJj0Uje2e2OVNrK81jz1TPyB7Xk2PoN81OT/44 fkL3PHM8Y32229BHXK6QwO0p4+894b/wxX+fs6a0if8rXSRIScIrRK6NIIkglSCdIFOIRyopn0qQ o8LDqynPJygkcKvX4M2hvEmT94/Cgw2Ul6rAtH6fZXPLtDyi8RmqCFYQrCKIatd1Gt1IsJFgM8E2 TUa3qUwDrmunpreFYF+M7WV3gDbhzTmY055zNKcr50TOqZy+nHM5Fyldyrmacz3nFqWrD1URDylX zrXlJuWm5qbT1dXczNypD5Xm5uTm5xbmunPn5PopL80ty43kVuZW5a7InZOxMXdV2lDaUG4051Ju Xc6lh6pyG3MbiWtMUf6u5+3f9MX7H0x488P9eMPDJLzh4UG822Ey3urwIXzHNxPf8c3Fmxxm4B0O M/H2hifx9oYCvLehEO9tmI03Nnj+6vVJUoqkfmu2XTwhRE6WEA/sUCFnGoGDoGCUZwQjP6dIy313 kE9T+TnzYsotGL3GfZ9GL1J1Agpur4/giSdanzgQkw4b6CMGuvMO/HESv7cQ3+QWeL+H+mYPM77J HYdvcifizR5peJvHZLzH40N4g0cm3tQxBe/omIr3cmTjXRyP4y0c0/6/6ZXEfnFw9DOgyc0icH+v nh51jNJ0Nc14NX5SSzw6jWUfLVDh9vsfpM8gcSNWkp8cylv5HZbyLvmHFNbfkn8sMuR/lfvFo5aX LC+Jj3D0FHPifxB/VHwU7xVJI0jR3s/xyEh5E5WnWCLvkduFWe4gXekoM5kkJgFr/ZF6XEipnSj3 dbztgt9gWijcBom9IiX16P1y5sH0q5kXU/enHqTUR2lvanvq0dSu1BNIp6CDP02Ok78jf4fq/r78 feK8Lr8uZPmAfEAo8hvyG2TZv5A1ZmpTt7ChNXFk2Q9FfPybZF8yzbgmqRvP7haKCVQ7zbJHUu8C 6Xe8J6WmiUCqn1J/av/9FZSW3r8UdPX91RMvTrzIdGpVahVf8z3clynNUVPmmcwzI3LyB6TLlKKU 5owmLjtGpy5nTH7i6dBPkhVqGZbNvJx5eeLFzGtkn8z2oXxh5g3NPpnundGtMtQgozzsub8G5fp1 K4jPdp2n1J+JdqfaKFVpSW/DtdRrGEd+K5PAu40ke8j+SSHbn7EvERb7UvtSYbMvs39a2O2fsX9G xNs/b/+8SLCvtL8gEu2r7S+J++7ZhyWpVbqB8V5N+xaR4rx3yKimFTJEsOR24HsME5fT9SI1p2vp 4XXIAykFE66knJpYOtGf0ZWyaGLphCsTrtBV2YSejHMpp1IcKYvobtnEsoxbE0tTsjIuptyi5EhJ SHFMuPKwnNE1oWdCD8lR4nJcmvT1aTnxUuYRNZjSl7JsYoRyhw4TSzO6Hk6lEj2k9xbJ3VLljADb dLjNxow+2LiIaLJvop9kYB/lZBvd6zLaNGoPcTR7uJ2sNyVLBbYrZVnGiYxTKX0P20jzIHEWUaJa qETfw0kpy1LOPZzJoyS/KlOMlr8qf1XY5a/JXxNx9nJ7OXlAhb2CPOBZ+7PkAdX2FSLJ/rz9eTER 76ZKjf99/O/FA/F/iP+DSMPbpx78k2JckKCUYAWi3BT8xiSE7zIUaZFvCuSi+MaBJOYa5PLFMv6P 2RE5iaLRP5JHyxSPUD9qy0Bt/JZgGzxdwNNN8HQLPN0KT7fD0+Pg6fHk6atFIjRxGwTaYEYbHkPd /DYitlyt+1HYuAZWS6JmhCeLiGa5UU61WhLzNN6fY9nd2jq+3ZLYqvV3K+rGG4tFg2b3UQPvpNbf Rrl2ze4ajcf/7/1f8Rn2lrQ7tsACTQKaJGiSoUmBJht08Hu4zbfbgFrioT/pA8ZwqzhsGEOV1y5a DL6n8lZovWHkbdZ6Q+f9pfriXlrzX+mt8fqC/yP4BHYF6fy/X0kJQiRsBgQSbQkXE/YnmQC7E/Zz nmRKbEyKS9ifaCNKvZ+clJzYlthIvLbENroyIU0Cnpw0mbhDABunsRp1feodaDLoSbhIVxdZmmsj rNbclsi/DFLsn7J/itpcYyePtL9ofxHvFbvHtUkcwAhqn2zG7wQEEvMTCxPdiXMI+xNLE8soRQgq iZefWJW4grhVdHdVYjSxjqAxcSPx8xM3I/kh74asMY3VqOurout8aGI9ZUSXEaeQ7kVJ18bEbcTZ lrgTuCWRv8cm2yvtq/7cFsZ1AALxtxLk+CUEt+KPJtgSZEq2hCROxOmKT6CzU1d8F/O1PDUhncpk cqISSVpKVxOVuQWNy1BC1ajr62JdqibCSZAuAiWTNpnKTwWoOB0tfM5e9SesHzLt/08jSqnzkN/q rkj5UqE4RtfbxnCzpTxEs4Yx3AwpCzFx+RhuqpQu6ui6bAw3TkrG7yy9Y7hCsohFdD3NwJXFdeyz U0d4o6N39xmeIu+Wv0US35b3UJT/rvxd2lm3yq1Usk1uo745LB8WVuqbt4RN7qQesss/lXso/pyS 3xaJ8jvyO+I+uU/uE8nyGfmMmCCfl8+Tzvfk9yjmtMe3U8z5Ie3K76dd+ZvkG7y3/wrwq8Bfu43+ ioHebKC3GOjXNJraLi2SQrT3y9Ha/mHwSqSF/J6GMbw5kp94pjG8IslHV1fH8GZK/A2Bs2N4OVI+ XXWP4WVJfCY8OIY3WeJ9wa4xPB5didZvIy9BSsEKbuSZpDi6WmrkiVuSbFgzVN6guGlYM1TeZXHN sGaovIviksEnPgw/5/EXiN0SYreM2K1Q7F5OO4EVFMGtsSNhr75tJDYb+P8TdKWBrjCM1lcM9Ku3 0a8ZZF4zlH3NoPM1Q10q/dkxHqDS3N4p+IYon0nVFmePSlPr1PMs4wOE4/gfpvnNmRp3TOyy0C7f mi8ClkpLqaWKYAXhTMpXWaJE11mmWhqJ3mjZbM2zbCP+TksLcSrp3j5Lm+UQUhVdrSDJqcRTUyWS UeOovlWWzaSBNY3qYbk64hyiux0EnI5R2mbpEKP7sXuNzhekSWghfzdWmH0EdN4x0/nGvEyjKSaZ V2r5Go1eq8E65AFzqdltLiOIEE6ivNJcRfQKc6p5FdFRcx3ljcTfaN5MVCnd22beaW5BKqOrCEmm Ek9NpUhGjaP6KqGLNY3qYbkVxGmhu/sIOLVRajTv+zP32/d6skySFqH3VtJ5Q5hpx6KcHwW+NmeM BZ1/3w2CIRWSKfYkx6m85GSCSQTkreasUdB0BpR+pd+0mnCvss+UTPgG4cuU9pni6E6tqcEUR6mJ UrPSa/KatpjyTDNNTk7KPlWSZPPUxNpiNY7qgy7SNKqHyvYrl4nnpHq9pu3KDcrnUtpl8v7F9p5/ Vt/L26l/HKPA1/KFsQA+xW+lgIDipELerszTgOkFBDTHFfJ6+coo8DXdD8jVlG4SBOU8eQvhWsI1 lPLkZrmaFmEL5c1KAqUUutuppMkHaJU8gpSnSebxkyqkai0ZNY7oY12syaAnj//7lThHqN5OJYNw rXxcPq5kyZ1/7b7H21dvGnYT/IzQNlQzlDDkBtQQuP+ElYXPcxJGk2Ny93DhSIwWph2MhynSS4eH iZb6GctTTWv5sxpwjrG8tImiE9FDvOPpB+fYUC/hDMjkDNWAtrAk6EHGot+yCXiQOBWWJK7Lwn4l oEdYVkK+FyuHYK/jcytpF8BLiTNliE+sW3EXuw11LyHVMpZtWHXU3cB24FO4OxE0VnVpELS6i+hH KQf4m4BPgBPEXexIpGPgYD1T9zIS9oLyHNDnQdcBbwCeCoy9pXwRuEOrMRu7kmzYnA39Gag3G5Zk o0WMWyCP/QvNOsaHGSvroO0G6HnAA5DErob6RbXzPsFPTJhTA5njwMug5zRovP9ZmcnY1AacB1wC ber+Bbui4T7Q2IUNN0HnLZTNHO7l1jGWBkEHQbcA5zBWZNArcXcncAfwZNxtBV0HvBd4C/gLgGuA B4DXAaMuUzJjcdM6GZifI92ER3WrHFsm+B3AdfCoQcaQFOaroFX+JnCywZkMzKX64XvwefLJGm4X /HyTGf1g5Zl4EPgsdB4EPmvJYZqxPNUMH+BS8lRLBWPI90NDP/MJ8/+39Kt8+H+/5TT3pBn+yRzC OYytDuA57IfAg9wKaROXlSrMPCMqIFOhylgOM4aeY5A8pkkK4DXoMXX2qXgT+orL1kJbGiRrcTfN UsuY78pz+C7ZeRj4PFrRDQy+Wrt5I4++pYU1mziq3GQs1TKmPlH1L4VkN2MT4gkkD5IvS/Kn4aXf Rf+fBT6o0Xmg8zBGasyxALeBg9gyFKGyYmge1zK0G5FKjVfJiE41wCxTAX7FcBZ8lWNUGnAGSmUg mmWoEWzoUzzHwTmvaoBkv4rZEknzGfhAP/q8AqNQgZ6vBZ3G/Uz+MAiMEUfPpEE+Db16E713DP15 Ux079k+ygds7TLsriocsQ3dVmvfMP8KY/gH8q+BPBN0PfAox9pfAGabnCBeht7OBU4GFhtOBnwO2 YHYcBH4KGM9gzV8BXgqZLESwUuBn2BJBp7PhCwLy+IxO8ClbqeGxphm9g7HaSzxrlBrGUsUQ5jv3 rS2T+9+yibF5LvewaQdKJTA2FXKfKAnqCsKeY96o8hH39jJt7ua+tQ3wXQvmrOkCerubLaFoc5Lw e8O/I/w9xLHJTEuIjfKgdpfxbMi8Cm+EfqkLHAH/wVpAMicR/VhDDfDTkGwB3axF5hWI/7TiyrXc M8q7HOHlE0PrQLP802hpMtNmRFrlJfFtwofUdRMrwjHGyiHUizOVKR6SVdzPyrvw/2GM+DD84Sri 3jDHw6Fe7v+ha5itgiK9NPw7Hl/5e5b3Cf+HdQa32sJnsO+ZL3CfqNiawtiSyTJ8V/kt8+VDzDHV g/8eOMLE49hlopOivMA0jbG5GnyaO8rDzJHaQScxlqep8mYvy9C5h3qetYkMOv+QvLmK9B81HaLe eNa8gej/w7SpzVxCuImxeStLmr/FtLyesbLWTLsX81vguBhb4yH5cfCF6SdU9rPQ+ZZpFtE/YFp5 1/z3xEmG5ArofInlrSdR6uOosRf6n1IaCbuULxOeojyPsmSnYlbqCXvNxYSrFcZtCtks7VS+RfiG Qmd05dfKEaIPoJbrSi5xfgKcqbzIehQ3ODwLnlUayP5/VP43yXeYfk2cHyuthN9Q3qCy2xWKdcpX lZ2Ef668TvgTCp/1hbwTmE/UQtpPGiol3rN9T95DMmHaW0qKxLT8PDjz5C4eWaalZvC3yaRfquda pE2Q2Qn+T5lPkqRB/gdFpY8wn2l5NvjvyYeAiWPKYEw0l31P4hn3MmghZbG89A0ed+lXoC8SfUXm 50MvyOwh12VeZ2cp/5fwI9Iuwp+RPkf4f8CqqbDqaemXKPtL6PwP0LTWyDOlS7xTYr7UzHypWDYR Pw6S7wOnSm8zpt0Z2/A2NHwfLbqIUgfBbwV/L9Ezoe1J+ReE36H9oyQeRL/dz75hakP8WWr2EM43 yRyp4C2vYpTXMF9pZdpihU9+FT75HO6+BvxdlHoFPnmMfZI8ivlZkDwJ+hvwvWUK9Y/JLP8z0TOU v2WP4pisRNhypcJsJnxBof258k3lkxwrFB59wb5nMisUsSXMC3MfvO5N4Gb594Tfhu+9Cx97lfny D5RvEt4Ibz+qNJOGB1mb+RuMyQ8Zvwf8efBfgw3bWJv0FsvT+Yjt3KHw7Dim/JA0JCof5lFgrMxW HiD696AXA99SOMp9S/kO4X+Gzi8o21A7YdMRhWaonKu8SVFrB3ahyRz9htOBC3n/THsCwkOt4OQB W7Td9VZEvJPA72I9+hHWrxewXldgl8V4k7oX4p0hrUfYIWD9rcXdNOAK3iVKtVYndkSTwXFi13QV e4Ne7PScWN3qQE/G7guSWPXuM7+OnedHsdt8kvGwC5bzvhr7+eHL2qmH8UpwsD+nlYZXEzyBHMJ+ nurLxm6cW4qnkHRm49UB3x3hczRHVEi2Ct5rVUDGB80zQLdjxcE5S8FJwQQNClYuOu/hRMBrmRmn CflJyONcYMJYWHDCMvWpJwiWVA4Ns6flQ08E2A38W+jBqc10HZwo6Deg+S1VnlcxBacYaTvoXtSo nsK+wfs65Shj2amusyxjVU9bT2Ct3K+WhbaF0H9Bk6RS1ofBuaSe1yB/mrE5YyhK8t9hbNrBWP53 4BvwhH9hTPOZLWngHY68gO9KJ4ALWIMpnVtn6lTPWSyv/BY6z0GmhfczCsZR+QPw3wBjB2J6DHQC zhr3w9r90HALtoXQz5sYW5dzK8xLGZv6hudgh0CS8mrWbyph2uTDKLQCqye1mejJ45AsAKeXP0+X p8KqQ4zlDaBfBI4CzwP/IuiF8O0/MjZhrilu7NlkcN7Ezuo99awEbEOfWMhPWeY4vIh3FH+ENuzx 5C7my/Nwdw58Y0A9V0JzMSRb8TyhBZxJGK9F0N+Fu53gpwNngv8MeqxUnQXYQ+4bvk6lDsP+M6h3 Msq6QacCX0ctv9FkaiBfg1Hm/rwPrXgOeBnkd6K3dwCfQV0ToLMYGiLAf1C1YXxPoufx+ZPUiF3f g+oMRS0dGJ0BWI5nEWacYsy70IcXNHvYEgWlKsGpZz3SFGjugZ4e9B6eSJgxu2lPwLXvwV11JsqQ fxN31Zl+Xt1/qnMNXvcuYwueq1iSmG95HXrwmRh5Bdt5Vh1f8B+Ctt+qTxJg+T7U0gV+APoHh/5J SHHPMG1rUz0ZGE9FLINa7YRtiE7W1bB5tRpVMBM7gCvZ8y2ntWjwDYx7BLMYPYyz23GMyx9xBvyV 5gmsvxl3V6oY+/AE9NVNtGsaanTIGeglbjVmIkUAbmmyehd0Ie7i6Za8BZpbgSejZ4qAuyHZBrwZ 4/UG+A2gwZcRsS0tGNlOtOJ9WIKoS3v1XYQTzEc4ejMeTmdMq5iE9WsXY34v+vB1PoUNt4P+HZ0J +HyHsxt5BMsnA7cRjmO+9IQ0RNjOWLwB+jHgAPAC4Pdxtxv45+Dkg76PtVEtqs4lsGGA1yDrZ9la 6xOEd9PYSsMfY0x2ngOegVWvGfQh4G8BDwD/GLgP+N8g+Tbwo8AvAH8ad78NeiNorOaWH3KLTLyP tTMWb3DPSI+BEwBegBNxAPh9yHQD/xxPIfJBC5yjhfl96PxfoNHblklCuoVnccM4qY18ipcBzKfd 3+HuBexDOrW7c7nUEL7no2E8z2TfI3wIpyQ+Ny3HHvJfrTRS5jLGpvcYW2YzVj4EjmBsfRX0C4xt /4+9747L4tj6n2dnZ54HWBAFUREUFRuCPAhIsSs2BFSKvVEFRVDArlGxxqjx2hJrSGLBXmNi19gS SzTGEsUusaCxG7u+M9/dPNd731ve+8f7/v75xU++e/bMmTNnzsw5O7uzzwIOBUdZBYQ8B80uo3Qv 0Ae16qB0Luj+kDkDTk1wssC5A4496EjQU1Cqy+j6m6GtPGi+D6smwR5YxdEWmwG6F2odB6cBaHfw 08EJAR0H/grgfPBVaIaF6m7QhaAzgDuA3rBhJDAanCKgFTpdoOc86gZDBtqUE0DYpj4ERgArQnI1 8DU4scBFQCfo1EfkFfo7CPr9UdoO9EqUHgXnJfAAsAJ0whKWAI4dOK6gD0p0wPjaxQMx+naYCRa0 YkapeT80wLfKO9BXgLpPKPiwUG0OSyCv9gZCksJC5Sbo7ai7E5LwOX0ASWimmBXvr8uZ+f6AvguA ukky0sVc7Qd0lplZrHTEvJVP+VgnieoNiTxMIvUEh0g0TwedK9ECDgVHWQWEPActoiATMz8TsZCJ +Z+JOS85l1F3L9AHOuug7lzQ/aHhDDg1wckC5w449qAjQU9BqS6jt94MluRB833YPAnWwmaOttgM 0L1Q6zg4DUC7g58OTgjoOPBXAOeDr0IzLFR3gy4EnQHcAfSGDSOB0eAUAa3Q6QI951E3GDLQppwA wjb1ITACWBGSq4GvwYkFLgI6Qac+Xq/Q30HQ74/SdqBXovQoOC+BB4AVoBOWsAR9TDFGQJGRMhH7 mchjmchOmchOmchgkm8HDa7QdlCiA0bZLl7SdphLdphXFlhl1ufSCinjANq8H61jXJR3oK8AdX9S 8NE7tTl6AXm1NxCSFL1TboLejro7IYnxog8gCc0UM8rUHuuEw1jbdML1+gbWSGFYL3mCg6eC5umg cyVawKHgKPqKCPIcNLuM0r1AH9Sqg9K5oPtD5gw4NcHJAucOOPagI0FPQakuo+tvhrbyoPk+rJoE e2AVR1tsBmjc56rHwWkA2h38dHBCQMeBvwI4H3wVmmGhuht0IegMIO6VVG/YMBIYDU4R0AqdLtBz HnWDIQNtygkgbFMfAiOAFSG5GvganFjgIqATdOoj8gr9HQT9/ihtB3olSo+C8xJYAdpgA0sAxw4c V9AHJTpgZO3igRh3O8wBC/SbUWreDw3wqvIO9BWg7g0K/g39vgw2QF7tDYQkhW0K1vx0O+ruhCS8 TR9AEpop5oNYGYq1yjs3+WRerAy3YGW4BSux51gNumM1eFuuTCSHNJQrQ1H6GGvCnVi5TZHPGcCx lyjWhCVYE5ZgTViCNWEJ1oQlWBOWYE1YgjVhCdaEJVgTSrqUvvLUW1Gj5JpZ7m0pSyRSN9AngZuA UyWaJqG0MTgXQM8A+oATDiwER5Oo1gXnEOq+kzvRShexcjeZSkBbJC1qSSwDTgRKfYG9JNI2Oh8Y AwwHWvV9bYk0CPRV8IvlnpryArjJnIzVlFXaI1HtBHuKJV/IJENGSk6VtGkScCbkfVC3MVABaih9 x04BR8tegH4K2leuck1Vgb7iXlb2ZbTsl5QROBo9lXQNA0fjSlpW3g3Bcg9wiOQog5i4/1Wj4EkF u4S+akepQbcQGpaAPiZpGgv6N9gzkxfBKilzEn28gFJfc4wcWXAiUHoftAfoQ5A5Cw1LwSk02hIr cOUJJA/BkqtGqU4Lm1mYtJa2kKtuFU9ZlRfSBhoEv7lBsgS922nwpYdjMRZluFyZRMA2D6lHCWNf YixkLVVGjWkSeqRKr5rKYy6VxwyJxMwJk54Rqwsho6xG3QQWC2+Plne7+tihX5sgfwz4FH7WLWdo dxnwBkZkKBd3qUoV9Z3kQGYNSl3UAWhF0h6Q3CElaSPIeEk0zQDtwe0ErfeoBiT3672TGlR93MtC 22HwF6NuJG8N++Uz1QTI+KB0G+gRUqeSBg+3hfdGwhuHoIcAo4BhkDFJ2vQNsBB4GpiAuRQEmZ6Q 9wOnDEo92D6BnpJjKg+sgR7VxDNtvS74NFmVu+T3oCEC/Aj0YgH0jDLskRpypf2m+cDKwCnABPa5 kBlm6JTyN4BVUesQfHgIOt+CXxuSZzEuMZAZinE0g78auz815RxgIcBgibRAzgdqYnsF/iFpdR/o kSjtJFHR0Mo9eHuVbIse1GNHzhy1LmZREGhnPZ9gPl+BzFiMxRVkEkfwx4K2YqZNBL1Tz4HgZIIT LneZaSzm7RBJK11kFCj3EfVeenZFu7MR4zPQbhqiLwaYhLaWGNpkvNSHniqSTxV9/qPdp+wLxLsV NsjdnHS0rkCPB9q16NkDPVLhjanwapL0hgWWmJdIGQ4bLIqU4TswM9dKtORKjrmBpNktYC307gbs 8YLmJLQVI1eGlql8knxqJPfKhU65T+oOT87FPN+J/PM9rFoJO4dAQwhmzhjMhweQ3AI0gT9Ixg5F ZqCRuDq48ZrIP8PgGfk84R7yLVG7IhYWIK4bYVUv35erIWmRbwUq/sBh4BzCVeYcWjkDTi/MQA/g JalN+Q7eLmGfinajsDMbhlrvJEfk0k/xNEO2Pgatl0g977crFzDKwkI1TyLLB/0TcDs4q4AP0Yud EultlH4k0ZyE0t1AV/CjgIuAzuC3Ak6DfCHoLJReh7Y2cgVCE5mrvOpJWvUG3wv8y3qLoCdIGQUt 0jegm0DbRZTuAMYC9wIfA2dIVC4A28paKkcrdSVyFTJvwAkFvQb0LF5VekAi2w2cLZE7SDQvh/2N JC3ysMQ0yGQAr4GzWN7zChskDpaonFSHy8wpUXUGf4VEYY/E7sBcZJLDsGE6OAS7hzdU+ZQyVxUZ 0vyZ/qaQXEGpqWjLH/fXIbDZBPo96EZoJYcHCM45SM5GaTXYWUqiMgd0J3h1LzR/jd49gvwNyLcC 3Vk+4+JzsULoL3M1OyPtZGEo/QLWJrAKQqYlOOelPCuWWU5YLu3vixa/lftrgiNmL8N1U+S9t6Jf b+FhFTYHyjypyneaTXwC+vID2prD5LW+ktTGrjOTvK/BLqo98Bn4OVKGv5DXR/UVi5McVaxseaBE 9oVuDzLwKZolr4m6hyXH7CxrcQ/k8HtSm1IZkp4SeWm5clb1awr6RSMwIuMg/0DXTPej1/aC/6Ps hfBSeaxVomD5PvkEGz6vj1G+CT1erA1GQdJdZS2eDp3VQBfKdtlh/c0EjA7GS52FUQuVvaCr0ZcI 2ZYaIW2gqeBUQru5THBUBslYoBtwDzBOorIKMyoDkmlSg4onxqo3dI6WtOkJk7ux0ZIWGea5vFND HOl1rRLZOVVkRTZB6hSelzsd0yWfTkfvQnVa6qRTgcFoK4LK6+N8aO4vbVBWAdvI0VRm6Bx1vuwR WmkJPUXQ0Ake9oSdBDMkwmhRjALNA4bCkteQfyvbYqnyaq4uQosJqJWLXjjBEnd2QtaSdfkN9PEV ELHJ/DF27TC+8aqYY3yIHFn1JfgHgFnwfF3spHeAbaGIkTw9byDjXcacr40Z3lHGi/oLMkwSZshF yH+J0rKgnRFBF0Cn8mMy9pkcuyWITRMkxyNm96OVN5DsiPzzA2S6gr7BF4rSLVh17JGRqB6Uo2C/ Rdayi5cyFj+Jdphp5m8w37ZKtDss0RIhkV9D6WpYmyPl7bdAJl56QGgQaEa2Zz6sN3wi/EwdMTem So64agik6xCDuI6Le5Y/kMfkdbaDXDWxe9JXIh7dcbWS8TVKIv2GReD6sh/rZKknGJ4nVJ8t7eWz DnnHysviehEtaQXXWdVV0upDcE5Aw2rQWGeairHOzEYcTZdvuPEYuROh1lKdBOdTyVF6o8UHaDEd tuHq/P463td6gbe/lmBf1e39LZn/wdkEnGrw5Xtfk4AvwWmM0gugZwB9UPc++EmgC8HXwME7ZqZ3 4HeRaCoBHQE6HTJlsAOOPVOTr0RyCpwu0NMGMjH6Ljl2wZpCcik0zIS2cGAM5IMgXwMy32MXuxM4 c8Ap0d9AQ92qhqSsGyaReoH2QFsE9CDIhGGHOgoyQeAXQ9sxtBhrWPIIFg6ElyTnHfbFNqHFEugs hP0zoW0O9BzFOwBjUHenrg0yKvSX1/1vvP8JL0FnhO4H0Kv19/Rgmw80c3BcgIGohf5ShlaWod0b 4AwFXQXoAkkP8HcAG6EVjLIJbxXS/UYtSUNShWdoWdQ9DP2D3os7NWUx6CHQkIDS1cBt0DACpWng HILMIdgADysmeO8bYCHwNPg9gX6oVQZ8T9imjzVGjdYE6t5oA0n4kCaj7j2972jxMNAX2B+SFliF 90PIc/CdgZ+gLab3BTLDoKc8kIBTVZ9v0OMoPWDCjq1SG6VnIWnGbDwFvI43H4KlJC2AhSZY/ge8 ug/0SPRCn72IJtM90KtQeht6nMG5gtKraHEJcCysfQf6PrAGsBj8s7oM6nYx5E8TuSMscaI+G435 JjknQVuBm4CZaPEpLHED+ugZA28URAC7oO5OvI3ga7yNgCiG/hegX6B0lGGnTktcYMTLadg8EPbL yFLQa673Ts9gkLHAwypGaipojJcFs9eMLMfTQFtlKUeUUcSRKJUc5Bz2ESIoFX3xMnLaI3lHhrpD wMe7MYo3bFgAP0QC48EPAX8M7H8A3AJ7VmOnHm96mAZhZCN11P3wfjny7SLkiq+QRfGeIezZAc3+ es40Yl/iN3rsALsDzwAvQf47WBtlzISvkHkkPkfpGCMbS7qPWixaGaLKO9A++gzErsE+PK3dp++6 EmLsBtuTJaZVhCXmJCYRr+ThOZkkvm9Oan/SKz01KYf0y0zMyyLD5G8gE2IjvOQbW+/fy79USeyI AylNXIijPBM8i3xeSzRSipQhrsRJnMvfvcgSYqNM8ktBBq0QTqjUGxXfxkt+UQjlqlHGiDMpm5w8 YCAZC5wEnAacB1wCLEzJzOhLNqVlZCWS74C7M7Iy8sgB4JGM3OxMchJ4VggmkovA65nZyZnkNvD+ gNSUDPIU+CpHFJsIEO+PkL8i3m+Rv/tEH9jfcP5KmYgj0O4DdPgALR+g0wdoBup67D9AzcDSxJv4 kiDSkESQKBJPepAUkknyyCh882MOWUSWEi5fryVTiP57ozL6EX+PRBwt8svk4g7G4k3k+xcmuyP6 ub1VojgWwF6T/Xbj+IN+dHbVjy4zhbw4lvPW65WP1M/Ly19VC/3lNxn8Q0Yvyoj/q6LtUvgCQhSJ JgR/81X5v/+qGusnZ5SpqhJEW6ldiAcJJ81JJIkl3UgS6UdyyAiSLzw3k3xOCkgh2UC2kt3kEPmJ nCWXSTG5R56SN2KRqJm3EmpeY15r/hbHdebvcFxv3objBvN2cVwrqB04rjXvxHGdeReO6827cdxg 3kMUcdwrztYJ6X04rjV/j+M6834c15sP4LjBfFBIrzMLzwreGvNhHNeaf8BxnflHHNebj+C4wXxU SK83HxNnG4T0cRzXmn/CcZ35BI7rRRaQxw3mn4X0hr/ziPy+/jAy9n/kkVPo+RrzL4ZnThueOWN4 5qzhmXOinTXmXw3/nDf8csHwS5Hhl4uGRy4ZHrlseOSK4ZGrhkeuwSPXDY/cMDxSbHjkN8MjNw2P 3IJHbhseuWN4pMTwyF3DI/cMj/z+bzwyjywhy8m6f+qR+4ZHHhgeeWh45JHhkceGR57AI08Njzwz ZswfhmeeG555YXjmJWbMK8M/rw3/vDH88tbwyzvDI+91j4hEA49YTLpHLIruEQuVHrGoukcsTPeI hesesZh1j1gsukcsdv+BRw6QY+Q0uYjvCjwmr8QC0N5ir3vE4qB7xKLpHrE46h6xOOkesZSSHrE4 6x6xlNY9Yimje8TionvE4qp7xFJWesTipnvEUk73iKW8PmMsFXTPWNx1z1gqyhlj8dD9Y/E0/FPJ 8E9lwy/VZU8tXoZfqhh+qWr4pZrhF2/dL/+xR+7ZPFLD8EhNwyO1DI/UNjziY3ikDjzia3jEz/BI XcMj/oZHrIZHAuCReoZHAg2PBBkeCTY8Ut/wSAg8Emp4JMzwSLjhkQbGjGloeKYRZkxjwzNNDM80 NTzTTPeM/EKstBtXoFniSqCRLHEJsIirgQepQazCXxEkhnTRTolM38LSUZ2l/WJQs7XToGIF74xB zdbOCqol5M4Z1GztV1BS7rxBzcZXgrxJXRIqxiOKdCJ9RFbPIx+RKdoFW0tFtpYu2lq6ZGvpsq2l K7aWrtpauvZnS1qJoFpbWgjeXYOard0D1VLwfjeof2XRdZtFN2wWFdss+s1m0U2bRbdsFt22WXTH ZtF9m0UPbBY9tFn0yGaRiH1TXVNdsYBxV+Tz6WpKNVyLxcrNMRCrgDwxamNJhf9uM1kg1hfryHfk lJjHL0zyyyRuJi+TjynI1NjUxjRErtwcvicKvrShOuy3UQf+pJTjgvoc1E826oSNOmmjfgYlV4ea ckrSyg2B81D2i03qtI06A4qKXjgRV+UsakhLpivSirmQOfeBjJv8fbwyTzlIqJCcp/xq03TeRl2w UUU26qKNumSjLtuoKzbqKigmxt9VzPmqpJYirs/KYtGWuD4rS8TxsJBYrPwgcIlyzVbvutFvszJD mSnGqEBZLuQLlTXEXlmnrCOllA3KRuKsbFa2kDLKVmW70E+xGnUlcg3XFGstZ+NbnF+KgtXKaqFz i5Cnyi5ll1ifidFW5uC7APJLi3LsRabHWtZefgVOWaAsIJ7KImURqSR07CGV8Tv/Jvidv9SfJUbl w0gWdtPWQudzUG1sVFsbFWmj2oFi+MpneXEf4Y2aj1HrCWo8hfQzSP4hM4nyWHmOHorrBZ/MJyny zoBSdJvaU/mcVaMa+iEk6B3uSeUsN/HKvIqsZ+pGVtES6kVrUV9al9aj9Wk+nUAn0Sl0Kp1BZ9I5 dB5dQJfQr+hyuoquoevoBrqJbqXb6W76PT1Ej9Cf6Cl6ll6gl+l1elPoukfv04f0MavFfFkj1oQ1 Yy1YS9aatWXtWHsWxzqz7qw3S2Z9WX+WzXLZUDaSjWHj2Hg2kU1mH7NP2HT2KfsLm83mss/YfLaQ LZZ7BGwZW8nWso3sG/Yt2852sr3sAPuBHWMn2Sl2mp1jF9lVVsxus3vsIXvKXrA3nHCVW7jGnXkZ 7srLc3deiVfj1XlNXpvX4X7cnwfwQB7Mw3gD3oQ34y14T57IU3muwyaHLQ5bNUXjmr3mpJXR3DR3 rZJWVauh1dJ8NF/NqgVpoVpDrakWobXRorQOWrzWReuh9dFStHStn5YpfLySWqhcXFSmleVzGlqT KLQOrSNGwY/6idEOoAGE0WAaTDgdR8cRMx1PxxMLnUgnEjs6mU4m9vRj+jFxoNPpdKLRT+mnxJHO FuPnROfSuaQUnU/nE2e6mC4mpemX9EtShi6jy4gLXUlXEle6mq4mZelaupa40fV0PSlHN9KNpDx+ iViBbqPbiDvdRXeRinQf3Uc86EF6kHjSH+mPpBI9To+TyvRn+jPxomfoGVKFnqfnSVV6iV4i1eg1 ek3Mzd/ob6Q6vUPvkBr0Lr1LatLf6e+kFn1AH5Da9BF9RHzEHKhF6oh54Et8WUPWkPixxqwxqcua sqbEnzVnzYmVRbAIEsBasVakHmvD2pBAFskiSRCLYTEkmMWyWFKfdWKdSAjrxrqRUNaL9SJh8os1 JJylsTTSgPUT9y4NWRbLIo1YDsshjdkQNoQ0YSPYCNKUfcQ+Is3YWDaWNGf5LJ+0YBPYBBLBJrFJ pCWbwqaQVmwqm0pas2lsGmnDZrAZpC2byWaSSDaLzSLt2Bw2h0SxeWweiZZf2yExbAFbQNqzRWwR 6cCWsCWkIytgBSRWfp2HxLFCVkji2Rq2hiTIr+qQTmwL20I6s61sK+ki5u4O0pXtYXtId7af7Sc9 2GF2mPRkR9lR0oudYCdIb/Yz+5n0Yb+wX0iimNnnSBIrYkUkmV1hV0gKu8FukFR2i90iaewuu0v6 sgfsAUlnT9gTksGes+ekH3vNXpP+7D17TzI55ZQM4GZuJlncgTuQbF6KlyIDeWlemgziLtyF5PBy vBzJ5RV4BZLHPbknGcyr8qpkCPfm3mSo/PoSGcZr8VpkOPfhPmQE9+W+ZCSvy+uSUdzKrWQ0r8fr kY94EA8iY3goDyVjeTgPJ+N4Y96Y5POmvCkZz5vz5mQC78F7kIm8D+9DJvEUnkIm8xyeQ6Y4bHTY SD522OywmUx1+NbhW/KJJi6iZJrGNEama3aaHZmhOWqO5FOttFaazNTKamXJX7QKWgUyS/PUPMls rYpWhczRqmvVyVytplaTzNNqa7XJZ1odrQ75XPPX/Ml8LVALJAu0EC2ELNQaaA3IIq2J1oQs1lpo LcgSrbXWmnyhtdPakQKtvdaefKnFaXHkK62z1pl8rXXXupOlWm+tN1mmJWvJZLnWV+tLVmgZWgYp 1Ppr/clKEfk3yUBalfpQKw2iT+k0Oot+ThfRArqUFtIt9Du6k+6lB+gP9Bg9SU/TX+lFepUW09vy K0KsNn3KarM69BMWzTqyBNaV9WSJLJVlsAFsEBvMhrPR7Gu2gq1m69lmto3VYbvZ9+wQO8J+oqfF 8Sy7wC6z6+wmK2H32WP2B3vF3nGFc27PnehtFs3daFXuwTN5fVqF9+bJvK/Dd5qqWTRNc9ZctfKa h+aleWt1tXpafS1ca6w111ppkVqMFqt10rppvbQkLU3LEr3MRmYjyGwm5DQFOY0ip6nIXQxZiyNf mZGvLMhXdshX9shXDshLGvKSI/KSE/JSKeQlZ+Sl0shLZZCXXJCXXJGXyiIvuSEvlUNeKo+8VAF5 yR15qSIykgcykicyUiVkpMrINl7INlWQbaoi21RDtvFGtqmObFMD2aYmsk0tZJvayDY+yDZ1kG18 kW38kAfqIg/4Iw9YkQcCkAfqIQMEIgMEIQPURwYIQQYIRQYIQwYIRwZogAzQEBmgETJAY2SAJsgA TZEBmiEDNEcGaIEMEIEM0BIZoBUyQGtkgDbIAG2RASKRAdohA0QhA0QjA8QgA7QXq4PKpANiuSPi NxYxG4eYjUfMJiBCOyFCOyNCuyBCuyJCuyFCuyNCeyBCeyJCeyFCeyMe+yAeExGPSYjHZMRjCuIx FfGYhnjsi3hMRzxmIB77IR77Ix4zEY8DEI9ZiMFsfMcvl1ahtak/DaRP6Cf0L/QzupB+Qb+mK+hm +i3dQfeI+XWQHqUn6C/0HC2iV+gNekvOGBGDT0QM+ogYjGIdWDzrwnqwPiyFpbNMNpDlsWFsFPuK LWer2Dq2SeT275gP28X2sYPsR3ac/iKOZ9h5doldY7+xO+x39og9Yy/ZW27ijNtxR3qLRfGyIvoq 8v68PosXVC+exNPYNYdvxGLNrDlopTQXrZxWUausVdP8tAAtWAvTGmnNtJZaWy1a66glaF21nlqi lqoNEH3N+f+R+B9HorwiByIegxCPwYjHEMRjKOIxDPEYjnhsgHhsiHhshHhsjHhsgnhsinhshnhs jnhsgXiMQDy2RDy2Qjy2Rjy2QTy2RTxGIh7bIR6jEI/RiMcYxGN7xGMHxGNHxGMsrqpxiMp4RGUC orITorIzrqRdEJtdEZvdEJvdEZs9EJs9EZu9EJu9EZt9EJuJiM0kxGYyYjMFsZmK2ExDbPZFbKYj NjMQm/0Qm/0Rm5mIzQGIzSzEZjZicyBicxBiM0fcP3P8FdA+5Cuyhmwle8kRcppcJrfJY/IGz0Fw 70N8xB1UfdKQPhOzOZ8+FziBvhQ4hb4WOINPIQprxIcJbMJHCGzGRwls8Q80/AENL6DhFTS8gYaP oWE4NIyEhtHQIO7F+EdSAtQYGzXWRo2zUfk2aryNmmCjJv5Jyb99alBPQIm7d5FxrhLC3rJ3RBG5 QdyVivwgblpEjrAnFhHbafiuZhmifz1OVW6Ju7418imEInciIvHsqAYJwpMAZ4djItKFRlryJyXm jHy+cFycPRH3cpcg50THiLwgyvQjLcH9orzDILhXMImaV/68XyRnHEo5OP23vQnZttx9qkp8hX+b Gk8ijuLO+ZjtiUKx/LImqN9s1M0/KT5USv/LO3F9782EXTcN+0vCWcpDWlHtq6arGcbunEmXIsT9 sDi6gkvc91jz3XdwO59JbSY9dzSZlYJ89zWCVaiYTAEOVjvO6jhRxZ0RayK3r8NNqik/RDGpBXHW jlbfDzgeX1Ua60Ea4l97kkRyxaUlk6SSPPF/Y/nPWuUDZarrwmemjX2T5tFfcyY+u7jretzoplmn CvLL5lvz1f3WfLq6gComRXEJFCZGfXk7+tiWvJENYHCU1dFmrYkJu4bCTJqgchclIS7AxVpanlhc 7Dsn5qZnZPXNy84KcLY6SabZxRybmjIgOysloJLVQ3LsXcpGZyTnZOdmp+V5tcjOGZidk5iXIWpU sVaW5dSl/F/L4zMGpPrF5SUOGOjVoUUza6VyjgGBAeK/evUCBNFNnAZb69lOreM2/69Y5mh1kOUO Lmp0+w6xATWt1fXTSlktMgamp+Z4RcS19GoZFxPewtoqyC/QGlrfL6Jlq9CA6tZqeo88/mGP4lJz hmQkp1rzTVU/9LCJEZpvKkUE317JN5nIxl9fVeR1hhYWz+k5qtTNEctn3Z8a77n05YTBEz87drTH vJPnBvudt7zufuq+X/VDIY2frf7IPe63zrv7395zZJ79xVaPulVqrJzadLXGDJIycnfD2S+61Bs+ +ZR7z2o7F3U8UMr5ldrlG7chWfd2Hvpt95u1a/Y1K1r10/BnHpvmN1sxonqd96uHOXYJ39irw+WU qKtHyvpcWX7n3dI0/+7OdnY1qpxu4ug/4NSLoTNp5mXXMsum3apf+enkZRualcu+EZ2X9v3brwa1 Cu54rH+5jsmvys6ZtaB3u1rbb7q1bHvH95t3n0xe/2bZgBYXl1tf1a71YKGjb4/xl8tM77elaNCD Hq7dfKrVej9uYOdH08wLXH71iVPk57C/zjfZCY8wq6dwqaeT6qa6bnNcuzn66YUv3DfVrJHg6BXx 6+fXn2IOeVZTy1vdxrpWC3pxPrbVQPvfm74e8npznQ37gzeXssZLgcpqtLWdtW1B64KWk1qk5+UN DPf3T87JrDvgz3Gqm5w9wH9g/wzJ9R+Yk50yODkv1982jHIUMYhiVtYVItYu3CICkzGzyaRGWSOt bf48tyqTGhoNDB069B81kJrzLzTnWV2kvdVVzWr/p0pq+buApHKW2E2N4etv/55/wtP80TmfFd4O fusXdPceM2eQljDF2z22bPL1mdEs8vPIRa+vrRiQnpC/rXZJxspNZ25oF34+O6J6yLC+Htrrotrd 3D8L9Qnr1Op18LhtxY1adZtR/GZwSJeubT+JKWpYdnFubLu7I7Xw7/32bV4Y63c1+OC2fZ033270 ZcOIx9XcKtmv6hpS8+Tc2F6FY5rEPxx37eKCXalnhv3xPCpsx6WrZ0Oc/rJg8rTcW4NSYp83pr8e Op7zXVDQ592n/fLMsvzusEMdCxydsp/2b9jUvY+b70oeu9jDZeZP2UqlkpGLNv/x4rM+j1N//rny 5PB9gx82nz7i92k5m0a+9p265S+t46/XzTjmFu/eVaSxeyKNnf4gjW0ovd7+k5MNvtA/zbPh79PY 8P+VZFHNWkUPevcPy1NSveIy+mYJrX9NZNaAekH16gUGBobJRBZkDbKdWseN/79IZIY4/Sfi/zYx 3V7f4ysvxxe1Ru1kI8esvX93yJpacU3Ci5qO3jwj8GbnJss6lg2KX3ZiyycrmxSGXPPr8HuwW8yD 6BFFLkOmbPB92LXHyrvXztUeXFxxYs2FT174LWlWv45D09e7G2zf1mPwbLfYdkcCD4ZseHL3o8Jn zcr2sKR6Vgl56Lu9qoPzRufFQ6tOnDCq/baKMzc8+/rdJ0+1BTEFz360r3J91Q1T/dZv/fP7jaPP VgZfnNN58et2p53yi0I/LfPuxtkReVNSriUdqF7XZ93i8pWdKm39fr33FqcOOy97zO7Rdvnwb7YW /fRy4Mhapgnf+dQ+sWclY9eulhoU/XZtj2rja989fDDyh9s1J/zy0aEWDnMJ29g+ddDBPxNTH+GR Hv8oUOkH2arroOXdAqMvfG4e+35Cpd2TX+bUa/bY2lEWl1ZFvljayhrx9+MjZog8ZS4+gQHBYcF1 gtIS06xJIQF+iSmBIX5BiYmBfon1xWlI/aRka3C9wKCgxJS/SYBHS98+cmqLWxfTjyF1A93ctkUt sK9s7aQnwPZWkQILRAqc1PI/SoBiLouZLCZxb2uoX2CAXz1rgBUpsNsHKTDGKpLgBymw8f8sBf4T 3Xn/KN8FnMvyKdM5cNyZxYfuvgw/HRFtWXK/15V+3b8dfkJZtHNI+pKZXy5y2D/mq2mPorfPDXvt ePXawqc9vUtVnD6lbPioorU/bf4xc3uYb8vR3qXja1gdHd+3LqHm34rTevqOXOy50vmVx4a8x+0z +i9Z6T3hwu/zCq7kLn3Qz31Nu6Qlj0btdR3T5nj0poiXDxvOHtD819ujbpYrWJieblfrpfLZg9J0 e9/YtfvubM5dfir5eOT1xsVPYt6+//LqDsWlQU+vywlNvl43s2lA6OBavdSVrQbcfDZieNNdlY/f bnlm3fWejZ8NPnwzLbnPsTMLJkye7m19/iDoZLLnxuZ9I53a7Ql3erB1bviK0OLqsyzLp6SJZRvb KfLdUj3f2ScG1nDHai3g79Ncb2QPe7tZNT6e/dg3xVTBjQrHB1Swlvsbpp1tXAL8rHX0vOD917wQ m50tkoMYqIy0jOTEvFSvZoPz0rNzMvKGI5lZraGBchkWFlhPJLN6xmk9efr/Ms/+uwy2KadrjwrW lD2eC/p4eTWfPyQus3HFs9nHjj4q6f/uMzfnq1fC88a7f+tfUO/e+8vfN4+pdiaHFAV3tv/4yDqv tk8fpq+Jbjd92a7h7QYtbG2+8Lb6lcWDp5xYlRsx5ty4oie7Htdf+mOPlhfXr210tVb6Z+4rluXk dnpUbk7x2+A5OQVnh/SuNLTl+ImhbidzuzMxZaYv25Thf6GCw7tZebWvD/GPv+Rq7fri1PSkt0d/ 7N0qoMO2mi7F/1XNmcdDtf5x/MzYtzFMljAYXCTDGRHFlC1bDBqNigpZStZJGC2YsmQtkWVsQ5Zb MyHUlKTNDdmXcuuqjGUsJaFkiTvqVu69/X6/+/vj9+r1++uc7/c5z3PO6zmf532+3+/zeh1DsI24 Dq6q8FAXh83Xwp5toepxRznjCGRVNS6t69uf2B5gdaLd3m7Dsmi8wHszam6HU4IyfiTsktWUWZuu gV5uVYhzkURu4iORZILBXRrffo6uLwTbx56RPaDwChkQEMgyJxfIwT6sotd3SbICK6QwJydbgdGg KDffH6mJ2MrPBFcGZoe/X33QlVE+dmBwXcpxaf0ZLvqlGP9ig1u9aHDt14vWQDkFZfkBPHCUnc6Y AEZ/YhmMRnYxJKikD/2EWFTr58en7R68CNp9ZpklaA5uyzfJN4re+s9Z9rWZyJb2CoI+UcxhFcUs QDaUV1FM778J5FYWjMnnUf/OLygE2L1pS7iyWdm4v2GFVrX3OEzTr9Rydnz/0dfW+ugnJnSBpUej aEyhYvNxu4wI1F4aVtP6ZkEpIXsgoIZR9YFUbUmc3TJmFN7ULyhx6FFRtjx6XsDuAaEFPWDVeSuA VSpUwFFEeMmI2+44lWac/Xb6zcRAtJy2AYOQNYlXjFK7SJY5z0zlQU4xcR8SqE0jiKJzuAbpzmRi mlqgL0Xqg8wk/rFXs8KyM7KlIKFW5SrpAMG0wL5lbrRwF6GPAt1mqrl/5umVbrKW3+LFNMTg+CHW zwXqtxvWw2EeSZnP3hXMiyrzeeilvg2Ts6rp6CeMtIdekHRu1BHf33ceaZmEvk3XNpWZgItJAXv7 dJxQrRkP+SaiYAm2vjAEDnt8nUU2sWPap+nuq4BCxxTHE6mJ+dIWHHtm2wq9+IOKNr5Ga0o0DBN1 RWf8Kwy8yHM7riZuEPeQhcX1wZ+7z/i3mnV3SYySHnBWdS2ov5CLy6XxLyBUDOmDc/0/h5vV8LiY e7gY4sqNX+FeVwaTevm1+XxlIjByTJhD3xB1YcgcTnfPWLYT1zhex4UKY6YZqRy6fz45rTGxl4K6 IuScPVlwJfrgKUFvdE3wYQB5gT4lfuy9+CmlG7Ft3qXmGM2s3wYCsU+Ak27mHa2xjQzJeRgx8W4h tgxq6L18iHKBCS+FV+na8T6+jwXJ3Dxsfr/5wm/xg9qf+C3zI/gN6oLaIJvYOhvAlWBUC/PJ3ACu mD8u3f9P9M6j+lS8eGaRonb8sMba/lrmQH2mvaIdvbVPEqckPNFR0mFNDwLlRcZ5ehzSxCxTpY1T rmQ4g8pPgcMjx2pfneERnoVxZkyeaZZ7tEEpJmdqxktGffEYKxY5xsIVUu8q4psS57e18bXvK2sv N+YsmCv2Oe/1RPU3M3x5dPuQqpmGCi3aducOwUEO9QXvs2dBv5jp3WDO/MnH6ZUjqPSTHzoR07zX 8b47qradzbMArMw9RVTWeZamD3ZxR1oVzJ0uETFfw0fOO/16Z+gSJAtpxxsFwEGz19efK5rVPEA7 5JXJhhphQpopL/RPnae6QquRQhWLs5SrkFaF7Q7Lc1z378kLfKH3ZfaMlPw7en83Ef4TveGr6c32 AGBkxmf4Rp4FIxO/j1/qgYuu/3N5kuEkujjVKr+Ibn1k1wwPQsPj/4b6/yh1Z881PD3uvjOH6ca+ 0Sp6yLNWkr0NpEIjKNDJVxBxufX2sWSGRrdoQYKvG8MR+ggnj7DL7AszZDrWlO3KkulHQqJpNaFT 8e2v9CETzNvJ/FwNiRbMSbxYn+3llEFWondPxN3h1CluzSiO0XNqSgoBC+8XB0MzNYRmeZgBtyRx OUmH+YlpDOqmbC90vT1szM15q3hGvPxWJo+U1lwzxioYg11PFGgYC8AuR/EjXtzjd02afMKQGMfF h9frrN9XWDd+64SA8bFuPBE1ATbVhHo4O0Ek+NfAOp+uyXhncMNzVyVakzUXFd1sTxjJCUj1oW2y 7n5PqrskGea27k0BZZ02d4iUWyNW1leOPCnwUL2mzaRyaO7VieqBi6VBOgxcfaCiqHKwgMGOhMA9 ZiZrblVWltt4NeQZL0eQUBG5YqDniLHoPqmGXAVUu8no+tGaGYtm9e5erQhrZTULpf17xghvip9n 5jRt9q+NVAniFpkIRtVRyHdVHK5VeGPPUINdq/yoiOK6S+aTov4f47R8ri69sG9IUGz0rM1Bxoi6 Q7Host3JjEHUUHV504GqUAeubiMNO1pqeVHo5cr8C0elfk2JQRxV0NQq5fXLd0r4qS7/zekm1ONx WdvGrAnLl7MQD/8zAicaDjUM+42VpLdi1i3D6p2ce22kqb3zmrlbNXaKH25EFH7EkDnZS5izBAqB gOzl9uPi5e+XTb4VkfMjH6yEa3/ol48DI7i6Qs1+gG+WAAYGrm4VWwkGv3TkxLChZGuY0uaxVcY5 G6N/rUi6njuQMK0Auq/qIoghgA75ahGqgA1wCDgAEAH/T0VuTyAIkAccABIQwLa82H5X9tlBgERV jlD6l4s1iBTg70V0DThI0vzLR4WTDAFsT9CnsDGBUNmXN60o2Mp3PfHmGUfid0PVLplA7DeFLowr bIF4C6NOC9w6+MsN5Zeb3zISrWpFi5PS7xHJW0KvHhFvPt9Lk9AI0/V4U72zS6pzwfWdsKA67UDt EHf8uCddbdNad5drg5fu+Ile9gnxKB6Che81EF5qpJ1r9p1i3Wkgsyx5up0mWsAtLrpgOepsc2bQ 7oqY+KLnFGVe0+HMGXu/UIPTOjp2lBK3etQGSlwYcr9bjALLvVGnrWMSb8OKriK3OsJHEkQN5uRL DvO9xHpY7OI1oemd2yzlvWNwNEs/idrsAC1e5EXcrKtN5+qWKe+Fi+iNtS67n6hlYLLe1VLJUFWQ DFX69o64MWSoGNsl8kmVST8sCvj+jsQqTe4FJVdLUuDbzgqEffOvLVwY4c9VNoweRm8DCGL2/E2R p6J97izxEhKJsTxNuEG8NX+FxOhfeL2iFfG96+fCK+69DVq47chUvZl39QrT55HlL9xOnnHdOSKR 9PZXTVPXHmuVLXYV4jqN+7vUwquo59AkllBGz3CPkX7y/Qzhlr2SPTHIUapQgojD8KZruZLJxvO6 kxyvg6041JcmqoXk2gxQLdZ7Lo/FRiAp4dNeheWmuh+PYt03DoqrhtX72Q9sJh8v4GRUzEuLhvPC yHiHWe2YpfK1A6o2ZHNjKW5n2TlMHjy2yOXXmNDWkXf8tVnrsTunLW3y+LxLYpP6DjYuDV1MEQBq QpTdtDsxWB1/15I+Kk56PMRlOBhieKzMNp9AL6bzHNXXMet5WpjzcJt3wLDWh5x9b12uaQA5wO8a 40KjDQplbmRzdHJlYW0NCmVuZG9iag0KMjA5IDAgb2JqDQpbIDBbIDc3OF0gIDNbIDI1MF0gIDEx WyAzMzMgMzMzXSAgMTVbIDI1MCAzMzNdICAxOFsgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMF0gIDI3WyA1MDBdICAyOVsgMzMzXSAgMzZbIDcyMl0gIDM4WyA3MjIgNzIyIDY2NyA2MTEg Nzc4XSAgNDRbIDM4OSA1MDBdICA0N1sgNjY3IDk0NCA3MjIgNzc4IDYxMSA3NzggNzIyIDU1NiA2 NjcgNzIyXSAgNjFbIDY2N10gIDY4WyA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3 OF0gIDc5WyAyNzggODMzIDU1NiA1MDAgNTU2XSAgODVbIDQ0NCAzODkgMzMzIDU1NiA1MDBdICA5 MlsgNTAwXSAgMTc3WyA1MDBdIF0gDQplbmRvYmoNCjIxMCAwIG9iag0KWyAyNTAgMCAwIDAgMCAw IDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCAwIDUwMCAwIDMzMyAwIDAgMCAwIDAgMCA3MjIgMCA3MjIgNzIyIDY2NyA2MTEgNzc4IDAgMzg5 IDUwMCAwIDY2NyA5NDQgNzIyIDc3OCA2MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiAwIDEwMDAgMCAw IDY2NyAwIDAgMCAwIDAgMCA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDAg Mjc4IDgzMyA1NTYgNTAwIDU1NiAwIDQ0NCAzODkgMzMzIDU1NiA1MDAgMCAwIDUwMF0gDQplbmRv YmoNCjIxMSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjQ+Pg0Kc3RyZWFt DQp4nF2QwWrDMAyG734KHdtDcdJdQ2BrGeSwbizbAzi2khkW2SjOIW8/2QsdTGCD/P+f+C196a4d +QT6jYPtMcHoyTEuYWWLMODkSdUVOG/T3pXbziYqLXC/LQnnjsagmgb0u4hL4g0Ojy4MeFT6lR2y pwkOn5de+n6N8RtnpASValtwOMqgFxNvZkbQBTt1TnSftpMwf46PLSKcS1//hrHB4RKNRTY0oWoq qRaaZ6lWIbl/+k4No/0ynN1PtbjPVf1Q3Pt75vL37qHsyix5yg5KkBzBE97XFEPMVD4/CUlvKw0K ZW5kc3RyZWFtDQplbmRvYmoNCjIxMiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA3MDQyMC9MZW5ndGgxIDIxODc0ND4+DQpzdHJlYW0NCnic7J0JfFTV2f9/997Z9yWTmWSSzJbJ HhISdgaYrASCsiRKQlESkgguSGrAqkXBVq1GLVaprbUVqpVa0TKZqA1qK7WLCyqgVtFaQAEVbSvV 6tu6cN/nngkR+pr/m7STfz6vOd+b8zv7vc89c+fJfWYmEwgAPCQqbKhumDO7/fL0tyBN/yGQ/trs 6pradueK0yF2rQHEO2YvmN9w1vG+70G8OAX42fuzG86ofMS0IBWSXwd4L5rb0Fi7quBcDc1fR3vN mtfYUPeX2R+vAsqjgPns+Q0lZc7GS6hPpPFoWVA1r7H5hSsP0f4jVJ90ZvVpTaeHVn4DiG4B7Jva VrV2XrS2sQXCza/RnG+0XbzGf7x0/zEI91Jd++o5nStW/WZrpgDhuy2AZvyK1q5OeKCn/RXR/mwr Lrj0nPfvv6EEQrwPuC1lZfuqS375j7cvAxZNgBC9Z2VHa/vhTz/9LSDcoBx/JTU43kuZRHVqQ/bK VWsuWfq83UzHXgmUvnR+x0UXfvLIZxqI51xFbaoLVre19jz/7bsg1j9D6/XQqtZLOp1HrXto/ts0 339h66qO8ox399L0awHDVZ2ru9bI2Wgn+0xKf+dFHZ1T33zSDOH2TYC1BspjoS4vT/9r0+PLrJEP dWnKMgF3Hsp8XMl3r22d/Mmaz26wQWehqp6NV6BcGzheg8U2fLLm4wM2DPT0Y7QrLeYlWAKJNYiw oQRn0qqF6bgKkjRRuAlq6NQ/UJfTDsKJXNqCc0SHoBZFjaRWqUVJdRAF8k5cUsEsIBpPq/IjCr/f qb7heK1Qrg0Ij0QhyLJMszep5ylnCpVmqpCROHB/uheHpWpcjS+A+hopjVPKqm8iTOMvpHoD5d8R p0JSAXMpHaNURKmBkp/SckpNlOZRWkdpIY2N/eu+pRuxVHs2WtVP0Aooy30m5lI5pDqEAlUXAlSu U+p0vPITc6gvX5uJoPoJ+YjST+OCbNyZNK8LG6h/JtWNyljtjfCy/T4BZ/+53NOf17N9QX6v3445 VP6E8lqytZryeTRmPpVnUDKT7RFxqtxGZTuVZ2imwk5lE6UamvdPZQ6NN0uZaKf+FJVyQdJYOq6Z cq8ylvaZL70sMHukl9HzRWvNGTq07n8dbRtORrlGRtsGDofD4XA4X16Ee+SHR9uGoaL2/t+xlcPh cEYTAfLDOko2cL/J4XA4HA6Hw+FwOBwOh8PhcDgcDofDGXmUz8GOtg0cDofzPzEv0QqCsGIlq2g0 0LnP0s3IGmC20vxMeQ0sUc/y2TM7gA5PNNocLZy6KIoXEYWMj6BD2dmz6uoPtzdOjy+f/UHj2Wef XRIsb2xd2vZEhx3aZJusG8KY6ck+KOfLgvC/D/k3hnL+F8jLjLYJHA6Hw+EMCv8txUkmEiRBQS1J gkj3QB71n4078Q+dTHGMTj4OPQykBqZGGOXPYIKJ1MzUAjOplfRT2GAltTN1wEbqJP0EKbCTuuAg TUUKqZv0Y3jgIk2DmzSdqRce+Z/IQDppJtMseEl9yCD1k/4DAWSSBuEjDcFPmk36XwgjQJqDIGku 0zxkyx8hH2HSAuSQFiKXtAh58ocoRj7pOBSQljAtRaH8d4xHEWkZiknLmU5AifwBJqKUdBLTyRhP OgVl8vuYinLSaZhIOp1pBJNIZ5D+DTMxmXQWppBGMY20gvQYKjGdtAoR0mrMIK0hfQ+1mEU6G1HS OqZzUCH/FXNRSVqPKtJ5qCY9DTXyX3A6aknnYzbpAqYLUSf/GYswl7SBaSPqSc/APPldnInTSBcz bcJ80mYsIF2ChfI7+ArTpVhEehYaSM9Go3wUy3AGaQvOJG3FYtLlpG+jDU2k7VhC2oGvkJ5D+hZW YCnpSpxFei7T87BMfhPno4X0ArSSrmJ6IZbLR7AabaSdaCf9KjpIL8I58mF0YQXpGqZrsZL0YpxL +jWcLx/CJUwvxQWkl2EV6ddxofwG1jG9HJ2kV+CrpOtJX8cGXER6JbpIv4E1pN/EWvkgrsLFpFfj a6TX4BLSb5EewLW4lPQ6fJ20m+n1WCfvxw24nPRGXEH6baYbsUH+E27ClaTfwTdIb2Z6C75JuglX ya/hu7ia9FZcQ/o9fItmfR/XUu9tTH+A60hvx/WkP8QNNOZHTO/AjaSb8W3SLaR/xI9xE+md+A7p XbiZ9Cekr+Ju3EK6FZtIf4pbSe8hfQU/w/dI78X3SbfhNmq/j+n9uJ1afo4fkm5nGsOPSHtwh7wP cWwm7cUW0gfwY9IHcaf8Mh7CXaS/YNqHn5DuwFb5JTzM9BH8lPRR3EP6S/xM/gN+xfQxbCPdiftI f4375RfxONPf4Oekv0WM9HekL+D36CF9Ar2kT+IB0qeYPo0H5eexCw+RPoNfkD6LPtLnsEPei914 mHQP0714hPR5PCrvwQv4FemLTMkK0pewU96Nl/Fr0n1MX8FvSF/Fb+Xn8Eemr+F3pH/C70n34wn5 WRzAk6QH8RTp63ia9A3skp/BIaaH8QzpETxH+ibTt7Bb3oW3sYf0KPaSvsP0XbwgP40/40XSv+AP pH9l+h5eIj2Gl0n/hn2k7+MV0g/wqvwU/o4/kn7I9CO8Rvpf2C8/iX/gAOk/mX6Mg6Sf4HX5CXzK 9DMcIj2Ow6Qyjsi/5z59jPv0d5lPf5f59HeYT3+H+fR3mE9/h/n0o8ynH2U+/Sjz6UeZTz/KfPpR 5tOPMp9+lPn0t5lPf5v59LeZT3+b+fS3mE9/i/n0t5hPf4v59DeZT3+T+fQ3mU9/k/n0N5lPP8J8 +hHm048wn36E+fTDzKcfZj79MPPph5lPP8R8+iHm0w8xn36I+fQ3mE9/g/n0N5hPf4P59NeZT3+d +fTXmU9/nfn0g8ynH2Q+/SDz6QeZTz/AfPoB5tMPMJ9+gPn0A8yn72c+fT/z6ftH0ad/v9+nv/Jv +fR9zKfvYz59H/Pp+5hP38d8+j7m0/cxn/4y8+kvM5/+MvPpLzOf/jLz6S8xn/4S8+kvMZ/+EvPp f2A+/UXm019kPv1F5tNfZD79BebTX2A+/QXm019gPv155tOfZz79eebTn2c+fS/z6XuZT9/LfPrz zKfvZT59L/Ppe5lP38t8+h7m0/cwn76H+fQ9zKfvZj59N/Ppu5lP3818+nPMpz/HfPpzzKc/x3z6 c8ynP8t8+rPMpz/LfPozzKfvYj59F/Ppu5hP38V8+i7m03cxn76L+fRnmE/fxXz6LubTdzGfvov5 9KeZT3+a+fSnmU9/mvn0p5hPf4r59KeYT3+K+fQnx5BPL+Q+nfv0MePTb/uPfPrLI+TTt3Of/v/B p4M8LsxLjal6SJJKzV6lUamgkVSSpBmAfdOg2qCDVqfVaHUqQGvQ6aii1unoF4AOKto0UCuo1Bqa KulpmlqlopqWCmqok/1akmZIrzdxOF+IOPShSf/QxhhGMKaOtgkcDofD4QwKv3PkJAmT59TYSvtF sZVRD51eq9XrldjKpNdr9TqNTn9ybKWh7fPYSqtRqVUajV5N0dWQQqFhwWMrzn/AMGKroXx+nTM0 RJNntE3gcDgcDmdQ+J0jJ0mY0w1KbJWIV/pjK9W/xFYak4HFVrqTYiuqwNwfW2lB0RTFU1oti620 hEqpUWylHoHYaijvJvBnCGcQhnFp8NgqeYjm9NE2gcPhcDicQVGNtgGcLwvWLBOFVOrE+1aU6SS1 SqUdgN2Iai1GGIx6ncFIw/Rmo1FvNOj0RlhghPKZPx3YWLUSW2klIysrsRWVNNrR+TYcHltxBmEY l4Zh5KwYc4jWrNE2gcPhcDicQeGxFSdJ2PynxlZ6lUal0g2QiK2sRlBApTey2MpiMulNBqrB+nls pfwJlvK+lUpHsRXNOym2SvqL/zy24vwH8NhqVBBt/tE2gcPhcDicQeGxFSdJ2IPmz2MrjQYGiq3U +gFYO4utKJwymahqsJpMBhNFWibY+mMrPZRwSqehkEqtU5t1eipr1TqtUfnWi+THVvohjEn6F2hw viwMw3kaR86KMYdoD462CRwOh8PhDAq/c+QkCWeOFWq1JhEAUWxlVGvUJ8VW7EZUZzfDbDYaLWYN 3W/azBYqGU1mOGCG8vdUBugMeoNOQ8NVepVFbzAYNDraiVmv1+mHFAoNi6G8m5D0P/LifFkYRmxl GjkrxhyiM2e0TeBwOBwOZ1B4bMVJEq4C2+exlVYLk/L9E8YBWIxicFpgsZpNVitVTQ6r1WS1GE1W OGGF8vdURugpttJrKaTSGDQ2g9Fg0Oo0RoPVoNcbkv/BqqG8m8BjK84gDCO2Mo+cFWMOyVUw2iZw OBwOhzMo/M6RkyQ8pU5oNLpEAKTTwaLRabSmARKxVaodNrvVbLdTCGZ12e0Wu81kscENu/JvD2GC 0USbzmjSaEwahzJPp6ed2JVPDyb/xf+h7JA/QziDMIwXpqwjZ8WYQ/KUjrYJHA6Hw+EMCv+flpwk 4Z3kglbbH1vp9bBq9VqdZQAWo5jSnHA47Vank2Irm8fptDodVpsTaXBC+cyfBSYLbTqTRas161KU eXqDzmJyms0mc/Jf/LcMYQx/hnAGYRhht33krBhzSN5Jo20Ch8PhcDiDwv/vCidJZE5zfx5bGQyw nRpbsSvN5E2B0+WwpaTQMHu6K8WW4rQ5XPDCxWIrK4utzHqzRaez6FJZbGWknaRYzGbLkEKhYTGU dxP4M4QzCMOIrZwjZ8WYQ5U5bbRN4HA4HA5nUPidIydJ+KNp0OmMiTeXjEY4dAad3jYA+yIKS2Yq XO4Uh9ttpPvNDLfb4XY5nKnIhBtG2myw2GgzWK16vU3vttI8o1FvtbqtVos1+R+ssg1hTNK/QIPz ZWEYb2mmjJwVYw6VPzraJnA4HA6HMyj8zpGTJAKV6afEVk4ltrIPwK40a5YbqZ4Uh8dDsVVKpsfj 8KQ6XG744GGxlR1WFltRKKa369OUmMxo0tttbhs1DykUGhZD+aQWf4ZwBmEYsZVr5KwYc6gClaNt AofD4XA4g8LvHDlJIjw3E3q9MfHmkskEl96oNzgHYFeaLZiGNK/bme6l2Co14PW6vGkpbi+C8EL5 rgonbA7aTA6nXu/QZzodDqfJYnA6vA67zQFHsk0eyie1+DOEMwjDeNPfM3JWjDnU4bmjbQKHw+Fw OIOS9K+15oxVChoDMBotifeCLBZ4jBajyTUA+04+R24WMrLS3VmZFiAtnJXlzvK60zORiywof0/l gjPF4XKYXakmo8sUSE1xuaw2kysl0+V0piT/g1VDeTeB/2ciziAMI+z2jpwVYw51QeNom8DhcDgc zqDwO0dOkhi3NBsmkyXx5pLVinST1WR2D8CutJQCP3yBjPRAwApk5AcC6QFfeqYfhfBD+Xsqt/LX WKlOa2qqyZRqCqamulNtDrM71e9OTUlFarJNdg9hDH+GcAZhGC9MZY6cFWMOzbilo20Ch8PhcDiD wv+nJSdJlLXnwmy2Jd5cstuRYbabLWkDsC/5cxWHEMj2ebOz7UBWUXZ2RnYgw5eNcciGnbY0pHpS 01KtaR6TKc0U9qSnpdmdVMv2uFM9yf9gVdoQxvDYijMIw4it/CNmxNhDU9Y+2iZwOBwOhzMoSf9a a85YZdIFBbBY7Ik3lxwOZFkcFqt3APZ3WJ6yHGTnBrJycym28pfm5mblZmcGclGOXCh/T+WFx0ub I91rtaZb85V5DpfVm57r9XrSkZ5sk4fySS3+X185g2Ac+tDgyFkx5tBOumC0TeBwOBwOZ1D4nSMn SUxbUwyr1Z74nJ3TiYDVabVlDsCutLSJ+cgtCPkK8p10vzmhoMBfkOsPFWAyCuCkLRPpmbQ5MjJo qrUwg+Y53baMjIKMjPQMZCTb5KF8Uos/QziDMIy3NMMjZ8WYQzttzWibwOFwOBzOoNhG2wDOl4Wq aybAbk9JvBeUmooce6rdGRyA/R1W5swSFJfmZ5eUpgC5kdLScGlxOK8UM1EKN21BZAWzgpmpgaDT GXRMCAaCwdR0ZzBQEvBn+pP/waqhvJvA/+srZxCG8aZ/4chZMebQVV0z2iZwOBwOhzMo/M6RkyTq b50Gp9OTxSppaShwpjldOQOw7+QL1ExE2aRxBRMnpQHFVZMmFU4qKyiehFpMgvKZvxwEcmjzhHNc rrBrqjIvLdOVE54Yzg5kIzvZJucMYQz/z0ScQbANfWjpSNkwBtHX3zraJnA4HA6HMyj8zpGTJBq2 VsDl8oZYJSMDJS6vy10wAPusYM686ZgcKR8XiWQAZXMjkZLI5HETIpiPCJTP/BUgXECbNz/f7cl3 z8qneRl+d37+tPy8cB7ykm1ywRDGDOW7BDljkqH86+l+Jo6cFWMOQ8PW0TaBw+FwOJxB4XeOnCSx tK8ObndW4r0gnw8T3Jnu9HEDsC+iyG+sxIzKKeWVlZnAlEWVleWVM8qnVmIxKuGjbRzyx9HmKx6X 7i1Or1Xm+bLTxxVXjivOK0JRsk0eN4QxSf8CDc6XhWG86T995KwYc5iW9o22CRwOh8PhDAq/c+Qk ifYnT0daWiDx5lIggClpgbSMsgHYF1GMW1qHqroZk+vqfHS/2VxXN6WuasqMOixDHYK0laGojLbA +LKMjLKM05V5gVzaSV15SXFp8j9YVTaEMUn/Ag3Ol4VhvOkfHTEjxh7m9idH2wQOh8PhcAaF3zly kofUnzIgsPozVKOS8DxUiFE9D34q6SiIysc0VGAOzsBiNOMrOIvCq6/jcmzB/cJ4cbIm6nfKMpT/ C5SHQsxCFeadNLL1X0fKhwbd2mj7iW7fp7GDd/RbNSQEDQaGC6IIiP86gE5VpWZFowkWq83ucKa4 Ut2etHRvBvsCwmAoGzm5efkFhUVASen4svIJEydNnkJnHsFMutuuRHVN7ey6OXPr5512+vwFCxc1 NJ5x5uKm5iVfWXrW2Wj59x+G/4nEtGcoQ/9wUvn/3KMWrTyjMTpr5ozI9GlTp0yeNHFCedn40pJx xUWFBfl5uTnh7FAw4PdlZWZ409M87tQUp8Nus1rMJqNBr9Nq1CpJFFBUE6pt8cdyWmKqnFBdXbFS D7VSQ+tJDS0xPzXVnjom5m9hw/ynjozSyHP+ZWQ0MTI6MFKw+SOIFBf5a0L+2LPVIX+fsGRhE5Vv rA41+2N/YeXTWPkmVjZTORCgCf4az8pqf0xo8dfEai9e2V3TUk276zEaqkJVHYbiIvQYjFQ0Uinm DnX2CO6ZAiuI7pppPSJ0ZjIqlh6qromlhaoVC2JSuKa1PbZgYVNNtTcQaC4uiglVbaHlMYQqY9ZC NgRV7DAxTVVMyw7jP1c5G1zv7yna2X1Dnw3LWwpN7aH21qVNMam1WTmGvZCOWx1zX3bY83mVdu6o avrWyb1eqbvGc65fqXZ3f8sf27Kw6eTegKLNzbSPmBiubemupQPfQEtY3+CnY4lXNzfFhKvpgH7l PJRzSpxdR6hGaWk5zx/ThypDK7vPa6EHJr07hkWXBuLp6dEd8kGk1/i7G5tCgdgsb6i5tTqjJwXd iy7tTYv6007tKS7qsdkTy9pjsfYXTOaTCx0DfazEhiul+kUD6yooFoXm0OUQ87f5yZKmEJ3TFEU6 pqC7bQoNI5oFmhVrp8fj3Ji+qqXbNo3abcr8mDpsC/m7PwQ9/qG//PnUltb+Fk3Y9iGUonKVDFxo 1H+iHCssjBUUKBeItooeUbJxJqtPLC66uE+MhTptfspo+bCA1ra1eVoJLX4goDy81/dFsZwqsQ0L mxJ1P5Z744iWFDbHxBalZ+eJHtcZSs+GEz0D01tCdB0/wJ7nrpguZ+DHakt11qycFhNS/x/dHYn+ +oZQ/cIlTf6a7pb+ta1vPKWW6J8y0NdfEhIdtOAxVZhWak6ILr1FS5qUBvpRh2tDNee21NFTjWyM OauaJK/YnCiJXontiq7fpQN7VipNJmVfqrCGXf/tfVodXcCsRfDXxmwtdQltNgQCQ5zUJx9TZrHs 82n95xSbVnhqffop9VPMM3VLZLAqR6xvXNLdbTilr5acVXd3bchf293S3donb1ge8ttC3TukJqmp u7Om5cTD3yc/fL03VntDM53ESmEaXdoiKntCwrULe6LCtQ1LmnbY6FfAtY1NcVEQq1oqm3uyqa9p h5/8M2sVlValUan4lQrqBXpWxEUdG+/dEQU2sF4Va2D1tj4BrE13ok1AW5+YaLOdaBOpTZVoi7I2 BcVTVDU2nXwNsCdWczFdUzvQKP25VyrwzapwSYfRIh3FZukIDlBSwUYtNirNotRJZZmSWt4pvd5b U1MW7aO8cBzL43n5ZTuUjnh6RtkvpdfF+5ALHzUciKd6Wc/+eGVlf2HSlESht6C47ECFQdqP9yiJ 0n7pAP3mZLN688aVHaswU4MgXQGrIMCHLdKfEKMkIiq92pudU7b5MekZ6n9aegrtbNpTcbO9jHb4 hPQLOOCTHpIe7O95sNdiL0NFl3QjLdtO0j2UDlI6RkmF1dJPsZ7SRkrbKalgJfVRKqE0X2mRtknb yM67ab6VtITSakobKaloCe+l9vMVle6RzqN7BZ90g7QJLsqvl25h+U8oT6f8TmrPovzHVFfyzf31 2ylX+n/Q334b1VMp/35//j1q91J+K9WV/Lv99YultWzemv58i9QVz/LZKrKo30+plJJEpU1U2kRL t0m5HSIVpG9KF7Aj9VBeRvmqRE7LdXk8EGKP0eW97rSyLbSkl9PSX04rdzmt3OVQUde6E2PWJcYU S+tozDoas47GrKNVKZW66Hhdyr0jqY2Sn5JE695F6660x0h3UtrD2q8ivYnSFqUmfY3WMZ+suk46 L57no4tsRe/UaNmsR6RzaKmj0jm9aZllGz+v6Q3KhUi5pT+3KmM7WG9Hr96ktHb0pmcmchp1foVF asPXKYlIIc2mNIFSNSWV1BbPLvE9LJ2OVTpELb714nppvWq9WlVaLTgek8qwQAe6JB1SMSI0IN+3 LCJMbtF36jfoJZvery/VR/UL9OrV0nppoyT5pBJpljRfWiap++Sdce20csqiszXTym8ybjHGjDuN e4zqmGanZo/moOaYRu3XlGqimgWaFk2nZoPmJs0Wjf4mzU1ascXYadxglGxGv7HUGDUuMKp9WmFL xdXScnY/vpzWeDk9T5fTKi6n9T8mLaN2v3Q2pWX0aCyjpTib2kEKqtko7aHyQcrVVLPSOCuNs1Kr lVqt1ApSpWcBpRZKnf29moGeE3OU8ceUHkq51GuhVgut7UHSY0qJ0lyqmalmppqZRu0RPyULbaR+ SgsoSaztICUl6Ph0oK+0v7+Fkob1H2NjTvRFlbnip9HW3J35Qixf2JIv3JQvRCOzKsqiQRKHw7Es tCy8LG/Z3arVodXh1Xmr71bND80Pz8+bf7dqVmhWeFberLtVJaGScEleyd0qX8gX9uX57lZtnLd9 3mPzds9TLZu3et76edJkeuh644WlZSwPhpX8wXhaetlka8V0cTudzjLSzZQOUJLgIy2hNIvSakoq cTupT7yfWu+n1vsxn9IySmqacb/iXkh9/X1K+2bWp5SUfvGUfolO/L74tPL5FXPJ5S6jtJmSRPu+ j/rvY6MTpe2sPUZ6kLXP7x+/hbX7SE/MkcjBLWFubgk9/ZaQ81+CZZQ6KamxW1pMvxwWK3sm9VHq pLSdkkpaQttiabF4P233ifdJRVHzeJdP+WZHwGHX2SpsoomuAbNwD9PvM72O6Sym2VHLXPNHc82/ mmu+Zq45lwpiHoVcZmET00DUWGF+oMI8v8KcX2GmvbkRgFl0MdUoKrzL9HSmRdGUgPmfAfMHAfPf AuYfBcxfDZhnBJR5GfTcNYspTI2KCrcyncs0J2r0mX/vMy/2mSf7zBVm4Q6Bjo5KpllMvYoK7z9g rbZC/4jwPqppT0I8ku+jX8ksE+R4pIKy4/HIbMo+i0fuoOzjeOQW36PCPwX2K034KJ592FfhEv4u zFEp9Q/6878Jc7CN8mOUr6B8KyJCmPKfxCNXKuPvovk/oPqdCOqU8T/GAjZvszCHtf+of94P40XL 6ai3x4supaP+AEXsqN+LFx2m1lviRddRdnO86ALKNsbDioHnxSMFvgq7sALZojK2DWFRsWRe/xHr aM8XUD47MbkmXqTMqlYO0CdUxUPjKctVrHxUCGEBO5wvHmInmYkQ20UGQsxoL8IstwhWZrwZQZbr 4qEraS+aB8KHff8VeUQ5cXwoWON3+A49Sud3JlXfEObEt/n27lCWK+7bXdQnhB/yPRd6xPe77D7h zLhvZ1GfjjoeK+oThQd9PbTIMRorCg/5thet8N0fYr13h6iXHurNkWLf7aElvtvCVI/7rix6VDED q+iMz6Tu5qKZvnmRbb7acJ9A3dEIHSxq8E0LXeSbSs1T+oQ5vdt847P7FFNKaR/bHvIV0BFzQsyU MyY/LE6EVlgbLdKu0S7XnqldqJ2uLdcWa/3aTG2GNkXn0Nl0Fp1JZ9DpdBqdSifqoEvpkw9GC5WX WVI0NiXTqBRVsbJNVFR5RYa8vijoRHruxJxSvVjfUCnEHPWob6yMTS6s79PKi2JTCutjugVfaeoR hG83Uy0mXkt3ko1NdIEqTVd7lfhzBwSh5OobvUq+7uobm5uF+tjONtQv98c+aqDzMNB9tDpU6UHq xbM8sxwz7VNrq79AWvq18HM8hSfjyYzdWt/QFLs3szlWphTkzOb62Gwlct0hflVcXVO9Q+xUsuam HcJl4ldrFintwmXVzQPDEBQ7aRgiSqYM60VQGYag0MuGzWPD6DIN1lT3BIOJQY8Lc5RBdPk8zgat SOwrmw5B+1qgZDRMzEI221e2mKUMo+shsTPryTszQbCynVlNYDvLUAb1hMM0pCisDOmZHKYBPeHJ rHvb592hcMKcZoTZccJCMzuOIHw+Ji8xhq6C/jGijsYUJpOOymEMFnpbX2tvU14/aAnVdFBqiV1/ 8UpPbMNyv7+n/bX+FxZyWpa3rVTy1o7Ya6GO6lh7qNrf09r2Bd1tSndrqLoHbTWNTT1t0Y7qeGu0 tSbUWt3cu3V9Vf0px7pu4FhV679gZ+uVnVUpx9pa/wXd9Ur3VuVY9cqx6pVjbY1uZceqX1Qp1C9o 6tGhspkCUJb3ikYDPR9avIHmylRb50z25Jge8FzhfVgF+rVlpODdFKqMmSkpXcUVxRVKFz07lS6L 8gpRf5fniukB78PCPf1dNmq2hypRCE/NudUDP11dXWuUtHZtIematR7WtoaetIGG+litEs9GYpGa WLSlullQHo61/VQ1RW2PRXZHxNWR9ZGNkc2R7RH12rXN1Ox4LLg7KC4Lrg6uD24Mbg5uD2qUjqVN D0Ujm4PvBaW1dDUJa4iaanbMtZTTj1Jds7ZLAXSALkqJwxWuLaxqqgiije52BbozL4aTUohSOaUG Smr8hvQFSocofUBJhW+S3kLpLkq9SotULBXXeM6tVo7YXKg4HY9U1ls6sWxKH+Wt5yTyhiWJvOb0 RB6pKPNQHp9Vbqiw0o23gIdJn6b0KqV3KH1MSS2VSWVs52sTV21zF7oKBTIfVFmjSFfhGqGQCoKy 3Gu6CguhJOUCp0eAhhYKp173ELrWgpaCHhDKaBBr7VKmrVXyEygd5IrV36Y0Dz5KGSxCg/w6pcOU 3j4+V/5UfT5Cx8+TD0rKx/3v70/Kf1C5FZuRjWPCeDyOneTJt9KtzgJswmzsxnZYcKmwi1YzRHcY 95C/8JHfr4VbUOM2vIKluAhHcJCi5nrsFxy0nxp0UrQ4VT5KWo9r5R00yoAq/BwPCxcIDSihcp1Y RCsRxkZ5J9zIk5+V91HtRzgiZMs9qKPSm7DT3fl6fIfC6PPwtPwpWZqN5fipsE44SvdWLbheNUHV LZ+P6XgQfxDqqXQaLlXv0z9IdwffwV2CW9gpH5Dfwq/od2kH7ekbuJYsjmOnOE6qUm+BHzmYgdPR Sr1fxyuCUxgvReVcuVK+jVp/ivfFQvH3kpbsKMQcLMON+DGtxks4TLcCRmEi3eFso22v8Ff1PrKt HmtxGTaQ5Vtp7n3YIYwXxotuuj8U6QzzcQb1bcTddPxe7BHqhWZhp/Br6W516fFZcorskt+SZRSg iSzcjF/TMf4ulNIYOoIUlNaoslRr1GWfXUln2I4fYg/2kh37ad0/xD+EAtpeF68Q18uL5XvkI2SL ju4dpmAhlmA1LsbXcCc9qo/jt/ib8Imop5G7Vb9TX6Y+Jt9Ma5uDSrJ9Po1uoH1fT49SHH20vURn aRf8dBZThNOFRcIKYaNwq9AnvCK8ImrEAP2qfEeKSbuk11ST1Gp5Gu0pVYnk6SpZjJX0CFxBq30z ne89+B2eElxCjlBMZ/QSzf9InC5W03aXuFvcL10tbVR9qr7m+MHj7x7/RO6Glq6y2bQOa3EvrcJ7 QirZkC+cJ3QJh8jym8QHJItkk0LSRKlCapSapWulTdKT0nOqi1TbVK+q56hb1du0rccvPL5Xrpev YvcnGrIrF0WY8N90fAl8FFW2/j23tt67uju9r9Wd7k7SSboh3YHESCrsqwmrgEZCREBASSIiILxE XCKLgo4iCkJ8ihs4sgg04IKOOuIyOuM+Mz6iDxFG4vPNIOJAOu9UdVTmP79/LnXvTfV263znfOc7 tyuQQeg/c9GbFuL6WrC1kZXkNrKW3Iv+cj/pQr2bJa+QY+Rj8gU5gwgQkHDN1+On34Bedyfci+1h 2AWvwhtwDL6Ec0qjYWxFtJLW0mF0JJ1H78T2AP2AfkJPMT7mWqy/O7BtYw4wnyNLs2wfNxDbaG4d 9xT/jlAkjBaaNe9e7Okt6Z3R+185kvPkrsptyr2a+6ZvWt9yXH+UlJFyXGknrvJh9MEd2J5FTzxA 3iTvkk/Vtf4dKHDo8S6IoDeUImq1MAqlxhiYABOxTcV2JczENhuaYT62duiA1XA73AH3wINq24zX tgOegQPYDsJhbB/DcTgJf4O/U3RiyqA3R2mcJmkVXukwOorW00nY5tHF2FpoG12KCD1F99FD9BPG xkSRbWczrczDzG+Z15iPmJ9YypaySbaGncbOY29n32f/yH7GXuCC3AhuPreNe4338ml+Kr+A38w/ z5/iLwq80IBydaXwkdCniSJb/R6ve/+/fN2U5N+Hm7gCdhk9jnHhYlq4TpiKFuPpFGYRcy/zJ24u fM+E4M+wlrmeWdj3ODOSnmcWwzT6CoSZIFfNzCXrSR/spF/Ss/Qb1g5T6GkoYu+Dg3QxMwwrOoVX P2Tt7O3cKVS6n5JqugqO0jeY25nb+14i1dw2OM5to38kIbab2shxjOpO+hC+6A/0erqOTGfT3AVy Pdr9GW4Z2nsIvRtKmI/YbeRrJkL/gdXVJmSN92AsW0ivoVWwExm3FwKkB1pJCzxIZDgCX0AWNfHT zFMwnhoQrd3UCINQdr/HSPARoyMzlDVCjNqhgX5PpzIv8h8wGSx7PiB/IiuAgRT6zs8/OXIjRsAD NI6cNgLZ5EMYSFzkIeT7s7kXFcbmPuPWoZ89xpSSSSRFGuk7pBpj42ts08ldZCA5jD54N0nRzWRl XwfMQd6fgPxJCdZtJAl6ZEsnrq0d84WDhpELZ+Gnnkf+fxtZfxx8R26BEEbWUVLEKo+sZ0cgMzUh /67DNoc04m9byf38fu5DUg9OQthQbht6+V/JNZhz/hs/30NqcH0zyWNsKa46hMzciq/YmhtNZGx3 kXeAklW45iEY5w3saGTeTX0L8Aqvxxw1HnPiMXJ930NkGGI3qe/2vnVkVt9jfVdjpTq572nk36V9 e0kl6eRm0Glcgk0jxx6D1zEf/QXWIW+PJn9GPoqCi/wN229x/UO4I2Qt+ylyZ23f+r6PiR3tEUYL NWMWPUFuIN+h3UYzR0lF7gq6p28k04IZ6jiZ2PdUXxB0ZH7fImTeF8kOgUPu6SABbgf67jp2Lk3h eouJA5J49mpuO1GKLB96ok/ZDkOOnLCHwhH6MnKbQF/ZSzg2S19+gSE6QZnsB+LW8Nwr+DglDBQT LSyEa4grIZ6r6a25QjxbM6G3htTiXLyI3YCUZJEsUezAx5KLIeboRZkjF9Cjj+LrT/SdgDdRORjQ T+Yfoc8SN9H2HZW1lYPTRJbr0hplH7EgIKV1nvOmeZVELsmknyIHcb1ZZsxBo8AYZZse5xnZSIiO FWVHWiez593iuZ6zPRZrVbKH1PbUiicHpKBV1TwJGDkcIkwsk66sGOiwFwiM0vORsHIG5sem88OS yTr2xvK6unI8YB5TkvHUjh8/zpW4mKorU06X1Sl3C9yJEfYirtyIPrP1YNb9lvtHA2PI9p3fF4mm 1bEslYZs36l9uGSS7XtL9uPE7cLOMxi7Hw0gGJwGqvPdiRdmRA+fsk9gPCYc9xYwBC/pBaNRx5qU a3N4PE6L7gb2d84biAUsd3p9D0gLVmDlea6x91z+MvuvtbemVjF5Alob+4ubNmDil1ytdOmlU7nS QQeXJ6psVbnmQY5MWWm1p5KJQOFyt7u2unrA1Gtzf4GiFaVy9WUD4vfmPlfy3ZTcWLoStaCNVMuR TZanLPQuwxoL1W3WWshmVDkIg/ZpU7iBB76jYMo1ils09vTW1Ig1ChI9AzDqoRHssXiMZkQyyM7z 1F7gDFC68qHrNm6Fgedu3XaF5Bm7Krc4On7ufbD2I6iEvhtLhp/JbXrjk+fXPvUIrqEc1zBNXUOV XFjMlmhGcwx+uAUXYUMy0+pwAfktZobvsE9/4t8XAY22jMPpsNpFImQqK62ZdLyclm++bsPW3Ps/ 3rp9guQet5KbUzJu7v25Wz7OvZ2DG6MjvoWFb3y8e+2Tj6hZ8x72KvZ3RE+2y54kTTIhTUjLJkmI C/FJ/WKyWM83oQVQ0E8kAhMnOhz1WFnEMdFNVDQUzrTMxAN6PWnigHsJTyrb1tgz8YPQpAHNEV6f ZeKyh2vCjzsSoikqYxb8gHIhCvRqw/S8ZVvPNmKMnWgkyZ4T4olGsUY826P+6z3RmDd11CJlJEuF RbJLFurMmeDvDXA2Z7gH/jEJ/jdnnpQzKqjemNsJm8lbqCUny/EZdIbzdQejdTa5P3AzWiACy5o1 VnLAKhv0bLXZHrR32Bl7FkpkfdA8y0zNbtdWNDLGfuOE3kYl5E5Yq8BidVYploZWG5oYLRyLhIX+ SFMdkL9xXqtWEPRRa8GA6nGVQ+dtyO0sDW9osBm1BdrqigEjb5o1b4+yusnQQaej1mVIrRyiXId/ TmU7B6B+v8IQKkIDNMFG6IIPgEcRmd5POtgpMxUD9TYqmCd7sFeWkrChGSZTrvcCdT6kvPN9yD+L MSvoSUL2EZnXM7JWrs5o5drMLC1s1z6vpdo7DUqsieda2xIJ5doGpKKXcgZJyipVvKb25UlZeV+m 7wQdgh7KkEmylnDvBJG7ABRAjZQpoBSXjRymx6gPygUhJsU0MS1MF9PN8MwReI6+w2Zh8Z7jyqf2 nFUMWlNb08mVJ1aJryvBjTKMDsnZG+Bb7t5/TuOeVfhobN8p5iA3n4hYxxzeO1sTygK/l+PsymA0 erJglq1aD4nJMSrHmmJdse4YG7Mop02zUMi3Y/nQhWWuO3oYAmjafjR7rhAbW89N6OkPm2HL5fFQ GCkMF6JKx+RPeSHq8/q9AS/D22LmqD7mcjvdlJdYSzMJ8p5mKDDhzGHAWSGEmsGrwc4q2puJW4ed ylBKV6IeJSW32dLWQegdToelgKKF47FBotNRMbByUKUFHSjvQnTs+iUzm7au3HL3h82v3XbD6yOq WiuXBMpThVXF1cMzo9N02ymon1S3/Y3c82dyBx78+tUfc6f2PDi7bRdUndpyU0q6fHJuK2L0PQYc jxZzkIfkAtnV5OpydbtY4pJddCmmemqqs6E6r8P81oVZl1HnGpxHEODzxAzXYwbFVAB/l01gNmPp A5xWY6AMFqI/4tPHyFaTySxbMilzu3mjucvMmt3Ow7QQTvQbN1EzQcSorVHRtSgBU0V+6LkIPyQS aui2NtqiFZYCh8NplzJDaEYxgHL938NYyVZzdY42DXbohKgnOpT9/WMXOtsGB2g0Sv0DVtC/PlAS CgQVPyzFa9yJ1xiA+fJqwaWvcrp8l6ddMnZupTMHHI5ioUYYIzwj8HLoKnam5irnTNdCzRLLEutW /aOmhy279LtMx7hjzrdcnzs/d3WHfmJ/ctrt4GfdnNfudridfpegdepden/aPcq9xrkhJLjclDo9 boObNzJuyvEup5JubKwxi8vQauUCQ22HFrRZpkI2iJxngxu2u593U/dhpgINd88+oIZAFu7BnM5/ VW+bZVtsa7extiwIsk25K8BDQnKoI8Q0hbpCNOQ+Aj9hnBlBlgtmYanQTjfQV7D4O07/h2qoO3gY y6pf/PlETd6jGydgWIlKYPX0NrZi0mzdwyu3EBzcoIVXtO9rKWlsnZE4oVCYioy1qoqK+ae8sMp9 jxsfn2Gq6RS5Va+bXlfERVsjIpYXGIyUISSTRqh4IVLZn2t5gQrSwMrKQczOWRe7sU4KbbtxzvZY 1P3+lh1fpMY++dMQaF505UgPcLkLURgKm5+57cmbWw+9+dHGefP+c3/u+8HiAGVvajJG+TTEcyCM P0R0fd17DVVaRSLVGKrqtCN0I/Xjwuz7WiguHlwsp5vS76e70z/qBJKGOm17ZEX5s4WHCg+XHys/ Hjke/Uv538Kno4YxmuIsrN9XVCSSLD2x74MUpLJMej/DiQ5wZGH7fr+cSKb9WRi2TzQWFx2B+aSA aOl/y/oGxIBuVDFAJPftNoAhCxvxfFlHGd1Y1lVGy/D8/llCO157ln4t6+Q0dKWPpinqIRhyULa9 YqM2d4VCOKd+AUhFp0dJbNidQDWJ1JPoaavtaexRJI7KQZXlyUBMZ2b5sBSRCqWoxPJc1BSL6ZBc kmxZMwTMOJP08WbQacv5VDMEjX6FbcSa/k2wktvwR42xNoLC0Fapcg7i5FDBkvqTlBODT2GfjMo9 sUhEiUMFWWF+9Z47Hr9y6OFVHS33575dc21Scnssy5zRkrkPRTzBxKYrQvXbR9/WtGU+O3bNgwvq Zz6wbcCBW3ff9vTwuL9Uw9Xy+m2L6scN9hfVBXTX3FE/r/1JhcNDGK2HEF0dqspP5SKHEcxkhFE2 M7IZSgxgF5BwgdFyPLAGvZGwBiPLG4wYVT7ZKmgKBEGjYViBN2hI0AjGI7AVFbwetstGDnithuc1 HGswsEdgDMaLBubKeq3WzMB25nmGMln4UXZBrRpeZmhCvuo2M2ZeFkBwmy6JodYaFaEaDCCcnhQV rV9blUTlUSP2iL1tNZYqixowneUJFvOVMjWbzchobahGWtvAHrFEUJNABQ7AHDqwo/c1evONO3KF cPbe3CMwt4NZfXE9fax3lsJfzejvy7nxRIKAPOwJFqwzAtcH2rl2vt2/nr3HL2RoRprKTA1dKS30 LeWW+zrpWs9a3+PM09quSHfETCKg3rhrdzg1BZh5GcVUlpCEKZcNSR6vjxFcLIdnt+8LhSTbYWQS F2OT0abwFaFfSRKqssMwhHhh1P4OoUvxY/gB/TgCcqQpQiMYID8dEGmXBJLyJrI2JItdIhXd4cPw IJxWLXaiEWlebFSso7r2CSQdnGM+VR0aWV9hmU5NeYJDcxHllzzRyMY2aKNtodWwmq4O8cg4CtEg zwy7erqsX8guts4JtHAtfq5xBoosQRJYxYN5/hKN1e+86LtxYJZfkZs/A7Rb7rzyjok3LV+xuDzi iSfHTbh5z7Z1N7wILDf+2QPxbXdnFx7oiA+aPNCXEKX0nvZbP64uE6hZ8c7piMUe9E4XVqEX5ZKb tUt1t5hWaz+Pno7yPAOrmBXsCsedTrZGU8RzTMRd5OaZ0CyUssgdB0IxiMXMKM7u2ecinCJO9pmN gMaVFYxkq95DSuQSKpc0lXSVdJewJe683fEhYhNtIVvKJts22rpsgs1d/KtEuYiC80S/RlGpAgkd rdrY04ZmhF9t+YKe9/JUNSHyR6kvqrX6fQEf5S1RYyyqjSBDiN5mIplwVqiLNYPPGmomYQN25GeN opCGShlgNzHCz7yuaBRL2lpYWQG8veAXiyP5M5vueOrxhYUb71v37ryV766b/fL9YD6/sPdd66iR FWOuXHP3qtiV3Pyosf4/f7/m2u7dz65/9up94D8Ao3PTe4d3Tm76cmjyic07/xnCKBjfd4LZgVGg J68eImxf9z6bdwinfoGKE7cGOKZEO5TIxiZjl/FtOEY/g89otxFNCnogRtnIUI5FRfkb2cPQAoah LGPk5FEZ7ivgceC/AnTzLDx8oEsPereBO0xPEYZ+IxsIK7Iy28B2sRz7Ij1JDP12V6qpEypdn1Uy aELsSeT1aadp1ev9zqtdwi3h7+Du4Nl+x8UM2YZ2RAWO8lVCGSfE/0A/zdW0wIO5da2pKRV+bnzs ny+zb3jLm/TKPsRK9Le16G9uEiMVsEI+PANLu4pgRUl8ccWKcIe+w9Dh6fCujnbE1lY849rheSq6 z/CC52DsSPwN3Rv6T40OgeiAN1KPNu4wOj1RY9Q0DtbD7cY7Tc8Q02WkGsaRcTCmaBZcFb+6YgFZ ANfTebEF8fkVt8LK+NLSlRUb2A1ch9ChWW1Zbd1QsMGxmd2kecCyybrF8WTsufhzFVn2gOa0/m+G 06bT8dMDiwWjNl5NqmDwQG64hhg8cVbtRKeqxXmuTBlsRn+dFnldi56vHCmci8jFIsnIGSpnmjJd me4Mm4m8iA8wGAMlGAO6lFN2bnQyTnf6MHzXTyyKPD+rkkrPibN5ha44PChVFzr5wEQyELY4WI09 KnERlOOCvxlKC0qaSbkVM2KYxRQZUOR4wlHWTJKWsryr9/u6kh8VsmlVUIv9WrIJDme+9lE3FaKV /b6ueL6NV4b+bAlrHmt895kn3lq0c3fV+D/veXXRtOUwYJm8dO7cjsyAyskN99ywaHVsFN15R9e0 O17Z2zZ+28K7r5jbuuGd5bNvmrnnk0Wr6q+/ZWl9en4y983IHU23bVlx5eiqBchBEzESnkafcJI4 GOSKW+Ofc5+GP4+z89nl3CrNCu0thmXG5bZbQus0t9t0Ws2GYnqZhou7pLiLYwJRlgjcYbiWuEB+ Id6AmQ2ZSdYmo4ujqJxJQIHHxCFHrX/B6SRGl8JAHjAfJFbRGrIy1ixch2xULBd3FDNycVNxV3F3 MVsMCodJ+DRZ94qO6txF/6JnevKCpjfP+rX95CSqm1OWPEdV5fEq8RZqLIaYGPXFIrGgUWomfrNS NmlwFtIHsHayYBfWRi+lJAUoNSc4lV2MQXnmH9QvZiiyEygA5RFSqWnR6u4/Fj/avuHdube++dQt 9//Xm4+9TCusQ5dPmHHXjLpZ5f/hi9KbofD56744uHfdM2t3Xvgqt/y2BfTQ6itmf7msa9uHt0wr VapurJo3MruRj5xk6B7Grdww4jfOq9zo7sLiTyaCAQndLNuxmE5vtHfZqf1FiGLe+BOQPHucVbV3 /05MAi4pp22XltZS/y5cabJuqDIyu/M1dnldr21ofjZUyUxX933NXMYtxCqtnJzar9WYU5Qq9Dg4 lUknU7Wp+tSs1ErtOu0Oww7P415tTGMwmhjRwXBSkAWzyaZT/jREFKiyO1babgMsNQ7s1410MwRL 9kmyNyIX61H3klipsOe4H8x+8HfGxBscJ0tTWbjhYEwOlaZKaekRaiRJDOhB+6StM/O7cyfVzZjW 1l/2587VYN5vhHxh4awiCvwW58+bJegGHqdPY/BG9S6jn2g9gh8MTp0fND7sSB51RBxt1gpYWwy6 JP5+MVsefJQBvHCpMd8sFgZMqCnsbL5yTk25VDLitSf/MHt03VX31dn7rQvyf+z4TevyIe2bJqWi i3yFAyaPbf3tsukLxzwy/4k1Z+uS6u6Guvc5OzdSKOXuJUPJFPhCXvAkebLuTB2DRO0T3XZfg3uq b6lDAJEUnSJ/q+uedm4EO73hSfuTjg+msaGG0MTQpFkuViIhwMqhnp1PrqPz/J2EXU7Wkgt1zB5N nfL/HZL6SQOG1lHC6llPSX1dBWWHeUmWGSprxSEwZD4ZBsPwt4NDzSNjZKjgO8IMxc/3MqP2j7+t MjDSmWUmypXCyPJ0pW7SPHbwgAFTp+lHltR6ngt5U17Zy3g906oGm8d0jKFjnrZVh8KpsBxuCLNh 99RpWfgcAbzGlYVBdyYSVyhB3NuIZeM5lW8VIHu/JrVnexFZxPfr2toe8YfG3sav1XDORzU+STzW KZpqVEgvGz5u0OVcatTokaNHjGb4y6prqilfGtNG7bFQ1BItjBWhCBl++ZglZNygMX7CJ1k/0ZTp l4AjiJ548z7i8ntwPAg+r9sjRpVzsp+Y4viM0dXDlsDYweP9hEsJfqJLCEtIgeRUX+X25UdrxIzj fjAUm5cA+eWuF6UawnroX35KSvK0r/wMHow1MDA/k7o1k6aFkTBL7QVWtiJEbBWUSOFCmhGtpGIg a7Wr+zUK+/D5Ud3HcTgHCUqq73+TSuVvtmJcx811vkRozHv378h9eOCb3JJv3oGWj0CAZ5ZUz8zF cn/8Ljf/q/PwyoX3YcJvH7+4ZvwE6wN7h4+68aWtN101bIYovTZuQmvDZaNKqzvWhwaPYV7OtXYv KwyV3g+j9+6E8JYfcunzJ3N3vwrI3bnvcru+hEfPgwaOAezMHTx0MPfwE6PrBl+1b0H7gvtgfuvk ESNutNUveWPj9Nr66Qev3j5n6BXo4SIh3G5kFB8JUtceqioaKwQDNOAnqBuJPwioHgteZr4iTjwE PHTMV7JTQ30BxqzxOfwk2AIdQAE0ZqohyVqF+N/74L1kUvEPsafnuzOQzP+Iqzpff13EY4DimRqT 2WwUdQFtsEHi7Wab6LF4vF6fy89Lyq3V0Ywy7EtNT6tjolwd9xbnT4di+dOeQP60Uz29164O8kOi LW006/HNq8xjzSPFMYF6aYb5SnFqwfTAAvM8cX5gqdjBdprWmjvFTuuawN3BLeYt4sOWLYFD5kPi S55DgXfMb4tv+d8O/MX8mfit+ZR4KvCT+bz4k/+nQKnWPM5Lg6gP0UjEHwj4tCadV+vwOb0ODRW8 GrulwGtfFjCLITHg84UtYoGlxQLKn+eZsvSYbKGBAkoDQf8OQvKGy8J+2aARzYzd4dBotBpfFv4p a834GrrDJFuyNLWvPgCBLD0jm0KyqcH0vYkxPRVauFbNMG4PxqzLoxRdyi6P4urYn8UyrLem05Sv tTobTeWuRCe36vWEi4g9IB79975TXPV6jVCD/9Ti69ebxtqw6pJUv1a259CxB0EF5Pfq1M1uPWWe 6f3H1eHLmnNTp7orhsAXEfisqnFy7+mJVUU3njwDb35SHw8mhWjU7Er9hr36wua7J3LRKFsulc4C Iy3s/atS/47t+5Izox8WApWHagNJUL5rSAY3mR8OPG5+3HrAfNCq1wTA4cTy61b7Msc9zFrHo8wm zy7mCKM1MCaW+kczMxguqREthcifwO2nXoDDyKTjDoQe4Yp8DGTp8f2WxG4RxCxTt3+DcbuRGrNM Uk4WaOkuAgADxV3PWyBoqbVQi0fGQk5bE3KB2RV0UReWynSqa0x0zrWq4Ek0tql7xufaWpEsW5WM 13q28ezJ2p4zZ9Gcil49pnJiyO7lDULUE9PHHFHeqy0jBjt2GjdXBjqnsYyQXyROXuG0Yd1li6hS RqEgdU/YybORkCJErYVK0qsYiCiwfwwGh5x8rPPPq5b2bL7j7eXBubnvj+SeP7T2ANS+9JsNJVZv gUfPLcxVvH9gTe6j49nc3ze2Pl2w/+l/Hr74Dkw5Mtph86aUHBdBBlB2Hhyo7Rh5ht6r998lPih+ LHJLxaUFneJm28P2Y95j/o9EjctiLfAHGMEOnZ67A7RIwwe9yI1C0GuUIk7JHSwymYzUXeRwEI2v pt4KeUGZsspWzprt+68Dig2tYyJKjA6pzcgRCEWgJaLsYDARycnbbHSq02A2K73yVCcyqkEU6VRe Pcl7lJP8tvDsfgwSiZoJvWqP2rMtcU4FJa8/8bBUVSkbzIiBzxMw28VoQSxg9k0Djx07vyU4Dbw2 97Sfza+UvK3o7K0VGcW86iZ0JJKRQsj4osBLcbQ6sYgkEhYiFdMKHb74hApaBCm4/NVdr+Zu/kv7 tFMwMPeH72feFB0k3cQsag+VRtfmXv4w9/XLHzX7YCQ4wQ3D/YqvlxDCvoAWr4BKuVbOzPPd4tuS esa1K3Uk1Z3RTHO38C1Cu6Zd28F3CBs0G7TawqDXL4WjQW9CimhkxSAayWQKar0aQTGlpJwRJEqD vFfwiV4KEeRWfwXZkSgnZaKyPUk/lKXS0gQ61A6/95TP59dod2k0/K5aZc+SCKJQLzD4XiflBvW9 lpbvKk0Ey5L40kWeXSFk6+OoJCY3ZFqwaGMyRFShElVURBUqMRwtVKEqVE8WqlAVbkt3H4JOVQor MKlYYcw09pxtPNGLcDX21Kh70+IZZCscciptYQap6a1RCgax5wwRf0hA/9j/fQGqSkmJgApLRN2s lJTvDirU704GVTCSit+vACqxhDPYBSVL4mk+GjWZrJOm5j4RiwafvGl+akhd0c0Xvk2lEiGnp3BK irWb4/aKgUXXcbT3VKR8Sa7oWl+kKFc3M+4MJYesyu2KOkX5Wqb1tkBRNPfpwga7WUFUQkSV+wXL oGRPUTILAXlQdE6lltXqdieZzYnDiTcTnzMfJk6zp3UX2As6bQvXwrcjxh1cB78BMdYIOm0JFSSD IQsx2ajxCv6g1ymFeQRVOVPMeXlT0OuQIoGgNyZFEqVFOo2B5ShCjeZ3lpFIjBSJRbRIQToaj8eo w6mJJ4p2kWIgxSks5VqwgtvI80EB6gV4RS0J98vlxKQiaVJBM6lImsIBv4qkXz3pV5H0byv/t6A7 izFXo3w1q9Z8iN53jb+ApxZ9as2X6Eev9+cRIWxVNkgTYFEgQxDLaSRiwaoNia3CLv0afj/jh4/D 4z9OrTdGoxAfMfxHow7LkAG9h1NTYi6jLohOwfyvMeIZcd0CBO3bcYtzmfqx0dy0eZLb6opGB4RW MIvy89wns2YUKXiNxmzzLGabNDTKU3TsyHLqjnuKqOgS3TRUKVc2VS7TtLha3MtKNro2une7drv1 Zcml+k4946os9zRUtlSuZ59juytZA3OX/mglM1qDuLj+EbYqqEXSav7Zp+Yf2EcIM04eNuCRUqfL FeaLShlTUVgLiWDAoFg+oBo5wCtGDoQtlgbrRis1W+utVOHOdmuflbWyChpWJNATL6gEmqXnZb2u piEG5lgwRmPZvu9lUXmbmKg8HhuTmbO2HyskRIyzZEKFSkXthFqOKiiJP2eqfpZMhxKCqIkWxYvj JXGGN8QKo2bJchmEgqJFSOjKiDGCnRgyXUa0cb4M9FFTGfkXgV2ST2EJNUbbMJMpiQxRDCnyIZ/J LEqRnpHsytebdgsqaDWtYeD+sos7iD2NsE9Z/nKut7N10z86xq2vC9ZNokb3Ff6Cm7rX5G559+Fp c/c++M7Y5YsH22xeBlPclK6JN7/33P+8ljv6YCwKd8+tlWKxdPSG3Owh1Rdf+nHfE7+7/kpXsT1S gcgr2e5RjNQRcEte7R4cJStGI9Fs37n9CiLRdLbvomxVpmnV99MqRGkbPkG2KadtEFaxC6vxEs72 nZLVgAmrTwx76kRUyX48SvFI4lFODNhr8ajFowb1s/5yUlhYfjkt9+koqU2qqvk9FMtnzqgdJJWU dPS9hDJ+kTg6IJXwyq0to7pGfTCqexRrG7XNJ1c24JSix+mlcDjo9UnhdNBbLoVHBL1DpDANenVS xBb0eqUIJo4yKZIJei+XImiBSGGhd8jll+v1OlpeVubzeTVWW5jKYTgeBqU+bAl3hT8Id4f5cJaG ZI84qmnU0VFMaBSMGhENZxrSTWma3jZy9l9diQni2TblJiixtU0lA/V2qH4Fii1PBT8LyfwOiCIm f41t1Q3QD/7f4Jf+/3TQ/xLYQZciDyRSKTpcJW8kgtJUqvfF1OSYu3et+tCA3iP9FIGP0BFoRBRy n8Id8/PE4BTr5lx88FeWgEdz117CGQsveZrCGRUolpYp94WTV+XFkpqFJdV1JLko45ZmW+ZUaoJe KoVdQa9VCruDXpAi2qDXIkWsFiRqjctNFa9xaxQvcbPKS91hbYumQ9OtYfo0kNI0aJo0zKz/4+tL wNuo7n3PmZFm0ToabSONltEyWixLGtmSYzkOGsjuJNgQkzgJJqZACFtjm5Am0DSGJJgELkmhLOG1 JOxheS8hqwO0mJalLPmacnt7A5SSvi+lFOo2vTflQsHyO+dITkJv75M/nXNm1Zlz/vv/d8bcKHeM ozkDPo0jFMiNTHxxAF+LGlU9SAyAy5X+yFDkRITWIl2Rvgg9GjkWofCkXIhmgohpxPQDg3VZTQR0 bRZwqf4P4zo5E9Tafxg6NKhkSNVvyFPc/voHpI1HKI204GE0QgrYq8sCEKACFKhHF1NXU9+htio7 lKeVI4oFRkfg3Xqz7cqWS6hLQxQaIToS9UyRHdOiprAsRGJKWAEa0AEN/hBwCFQgRtEceA5eT41Q r+p5zz8zE3neRDjQRPaayKCZHo5c3ntWZdWk3+nTJBWO6PNkLzYPMVUOIqqEXjryTbvPnagTJrEs Wgz3R1Z/9XHzItVNDL8V1y9WBEvTxit++L2V8Dtsdbvaqqymr8NGnwob9HVfP7cw7HblbkKjEgWA +Q80Khp8U//ELkEb4Lw2nzVlT9sbDBorToPT8kukVXCldEN+nfQAfCj/tvS+9An8TLJaJeQiMNos jW6RWrTZEu3RklJCoxnJqHm9dAak0dZU0OYtSyVfSas0dTatBDeDNdI632ptK9gibdZ2gAe0p8GT 2q6mvU3veN+URpt+431POtY05v1U+tR3oulz8Hfvf2nqHDjXOyu/FC7xLspf613re116Tfu19Gvt 99LvNZs9LPORqBKW/ZFoLiyniHThIjGBWCSRsJxE1j9SbgC6gOQD0CdJ2NM9T8u7NMmr5SXkzaG+ e/0+n5fiOQ4ATUumOG0Z4ihfPhdVlMiuyN4IpuATESbysN4EmyCFb2EV7IrdQV1if7hASBvNJZY3 C7ANiRvtjnK+iiaUiJtJsYODjGfSjKiWSEM6K4UQXwwMICMEpxflvOCyVGCtEMqS5ChLglgGnFT2 jkwcO+gtezVXuQZ4IN8lsBf0RiCmjG+KJ6zWIDyHj845DOlZ46dltUurpjTkO7hs8xYi1/9P8CQc yi9GvoTalR8f1RbHPON/M9z09Zr14QZVLSqD9JqlqWBS/eoDA9n8euuZA1u/uhNx3MTvJz5Fdsx8 kISv6PO2ilDcBpH/3FnaRkExSMEklXW2Otc6H6Q+oiYo1hmNigLWC9EI1gtRGs9rzIXnNSaKDkhR UTHqEsUo4tBHdXvyOWjieUjJfk7kaTIfFnGhw6EImqALtDAyceKAA00Oapw+QDwB1CAunvBwGvsl AnLx0lDBS7hPpKm004Vv4Y5EtCgcjSIdSnQmMVyi2IQxEW3qS13+6CTX9g5gvj3j3aEdqP0xScTX 5npsbLieTUbGZplMMYsBcKB3cHqPnuJFn5iGFVAWO0GHuBwsFVeBa8Wbxf8Fn4YvwoPi2/DvUPwL BbG9sgQgi3RgOl5LSE3s3h8SKxQOMHmsFWR4fXIIEZUeKOPmvnolk+qQr4wkO24e1+1iWfSIZUpw o6+vjAyG4/vMZXSbY7Xqi4OuMqU7ypOhycnMBqYq0Esjoip+QxbH/pHKiCMjw356GqYYeBzTUvzr 2+REJyIsTEhTp00NTjXO/5qlbZOk8tUWw4yvf3yGcPbMbHTyyOvHFvBagkeWwfN64QFxN/u06WnB 8B24jh2Gd7CG6Zw1BWh3iuGldvzWAwrQAo0BfDptpOcG8fz6KyUlqAepoKMdvymBsvNhnuLnBuoh EuyMLxAGMp/XvPJJXF0TlDF+zp9wJmwWRxbIUMpCF4taHiNqCSZrFvooVIicOwu8BncWnDtYmVsR AyPNglzxCC6ntOAogYOA50SHgDyfMcjBjdWbq59VP6lu/M3L/3Xo21vuvmH/y19u+TYyFVdVf1V9 u7oS3g3b4fR3np87vLv6UvXA/jtgAzwfXvrsHTgigiS2IUM0fSNcewTk0KPe21bK526SVsurA99N 9efuC7DrpMPxF1IfyB8E3o8zvqSQSyXKajk5NaXlliavSfbnhnLm1wH0B9KBeYF/930gG3en4Fvx 97zvx99LHk99FmcCeiyY4mxYlEZhWGYjMSRo3ZEYCCqNDcFUJdYZQ44R625IeTxuimM5EfgFv+bX /f1+o39urh5FATmo5/bmqJ250dyxHJ1rhERBQqIKIVGQMGq3EW6r+3lEP9oezuZG4Hf2R7Bjl7nw v0dTehfglX0JOvtHmVRjS2puHskMYJBSWaxpUBxhiae9AUlNJdLeRDOMB1CR9DU0Q1VGVvfZCMvc 7nW6EELiJzbVEA0pU9EUhgEk3gPI1NKwg8hx6MWW4n+XsJg1mjz1TE/SUwcgYJASfDyQWFAcfxHp Z5eM9DP866F3t3/w88Lg+aWLgysfmLOpu7mLuqV601AY6efW8Gr6etyat+/mJ4/ZZptMjwz1PDDP ibmiusq4DnGFGyTAuJ6eCXvY+yDN2OBi1FoB18Db4XZwP/eG/feAN9h1cAGkF3H0A4YR6pie5zwp gQah5zgO2y/9YAgYwMUcZ6Uz0fawM++kzuI7jM65qUkOSunIbfe3C1bFStmtYStlnZv8Zxx0EifW ehEftVcw8pkMu84nFDWQMFtMFoqR1HhMjVFM2B3NwiDvR8xjR0XCgTYjrlAWPZVsQRXP+WyeLIyJ qCBIsUmwWANGp9aT4UYc4U3E48k6fh3zmgvAM6xWg6km6NtXjD2wtfp69Q8rtnffPAy3QmSywM2I 924+tOquu7998KUbhzvKP7bvfdKiGK/af1Xb+ZdD+RWowXuqN1SPflm9w/DpbY9V91YP79uy5VHY /p9PDq2bjEmuRByYAkWK0vfFJUy2KiHe4SgUNydei72WpefGn8pSUtibWxGnecirCXU26IGrqFXx W+At1I3hG5U10bXqVjisPJh9Fj6rHk68lJ2IuxllE7wrvin5UPwJ+Dj1ZHxP9uXsce0v2YmsVQQe 6KfEFOKyQluuTVsRvyZvauCoQAC6w7I9EgVqSgbIzLdFYh7sc8V0qlGNx6MUdCETP/4cpVBsQ/oJ Epbz4u6yAtvF9rH0dgKqAvJzgeII/L5ub0oFgwHKbrNBCDiRJC96asmLmZ0lENkToTqRUURFDgot UG/pbznWQrcUOcLZHBkHjnA2F/W4CWe7yU434Wz3w6XLj0Af+Id4jdCLvbQMWa+br3F1vs7VdeNp bExAbN07mM8gn67d5xfGhnHiAIPbxLIfSQmSKcgQNGhBkzDfZwuhWFjNxvLNsBBCRS7a2AxicU1p aoZgkrJuvRUO1iLbRL+qBM4Jkc7f5yojPjhxyEUUJmqeOiiUNcGOVCSsaUZkbmUykQgkLP//Ewks zknApjOoJNa4snp/tdSsWENCIDG/RIQDMd7hn48f3fbYs1Dq27rq62nOAP/T13ZubLuCupmCsLrm myKi8vRN60cS1Vtu77FQP4C7b9uw04k9naGJ3xmMSE60Uot1n3hfI7RDO2Wmgd2QAmljphN2Uryj bQTO0o+1tLb4admwXFruW+5fLjNGq9EGGkbbDKvNq62rbWvs/aH+cH++X9vC3W4etg7bNtmHM7sN u5sF0dpsLVpLweZgMVjCCZGsQQkp4XQ623wePI+qGDSfFtLCWmRacVppjnVOQ7d5kXWxsCi9KBMM wzAlN4dLcku31O3r9i9purT50uKlpUtblk6x0WZz2mmW0zGz0jY1rbUNioPOLfEH2QfzO7Td+dHU Kw2vZ0bbTrW5LuRaZbCKkvfAX0AKboD1fIpuLT1UCMjBVWE5FHohiPcUfQ+5kPBot9hcFostY2mw GRI8qZgYHEceUKpAx1I4zwL1ULQIYTgBEyMwpgt5x8sO6iMHVBx7HB85aMcINXw4/FwoI2DcNDoh vDMHX879JTeBVJs+u6TnfoE2aJBTchpSeIbcS3AWKMNZUKoDUXozA0hYDp7GcOfB8cFyPlOzPYje quMPcF7Mhn0CcCYGRlq9UBgYq4vWlrjGOlMJcyPfDNJ2rNScqGA1tGnKWpqB2dKYSQpIxdlt6QZV RGqOyzOY5mvBMFJMIoyQyzDYiwxS/grzCuvVwhUZQ++SXoh0LBiogRwtZsleNmj2crNmJ+bhEkjC ojU0izdE1ZFINai1ozlETcId44lJJAQOndHPqmLvc5euvCNz3h9/cue8v7w0tRj+md8XZFXV33Pw +vXfn9KWrD5+7/wT//v6da1ef8SELKLM8K7LNlx0XvO89Stu+MFFD33EGyuhPPzlPd/v27S0aUVj 6Ger7+q+519LvnAeU/55yDbaS2yjv+ptS+FSamlwaeg6eB11XfC6EJePVCKdkQeND8i7jU/KLAWD IQ/26aM8lp4xVoqBMCXYucgINao7eZgButdWEe3odl1gDwbnUSndz/FEzvFEpPFEzvFRryecCWH5 aMNXgJAQWh7aFTKEXqBSwDPxJ92MpaCHyD8Puvt+5creWtrhdC8WeCEkYM0lfIN9ZnsRDXDmpNBe D2PjmQG6uYS+k4c+JqYODl5B4U2cycNeXy2amagFq8+RQyQixcachkfsCbMzfHX3y8giz4+/gs3z x5anih1sQjDOr/60O9425avTk6a4wWJzXn8pPA+PqnnihPF5NKo5uPEI0JDb0ZAvaiTPHSe13u0J FFNMGzOfWWc3qDE12RRrSs6MzUw+kWTTyXKS6tJWm2+xP5R8OflFgmm31SJR4bDsi0QbSCTKGZal SAy55khPUWrKyjcgH+2vB/CoocbHxIEjDTyCaeypCTzP6ZYypyMjhdM4ikPune5wubDuIXqIIYEo 7PTVQlWkpzMqJUGD/douba92QjNoYYVMpkImUyGTqURFcYMTrnJCJ9FdThs+5gzhY05f/vRZ/693 Mm6Dka/EA8z0ng3mEBTsJLajoM27aN3zUzjEuolIyuTAiHmKsatJNW5TskBwJCzpLDSbIoKaBSmz ir0KWDN+COAV9iJeBAOYZeHZaBiBeCQTSNd8I0hG+K+ugehfwhPNXRn3RWPv/PZjTZm5oJnqKHbH fcH521ZufncB0jjGpKpODw+Mv//O7x556LYlf6PE9Reqaik+OP585zuDHasPHqfUDUojogN54nfs ekQHZTpUi04f4mFrOuFyjND/F7uXVJIK8JpsMIuUmQM4bOwtVyrC+DH0GYV5jKvw8YyVtXAmnjWZ NKbMijbJWbagr4zpieOLqB7CdQDV+ieo0cKX8h38EkMP/xTPJJgM12hOWVLOlD8tN6SShRam7C9q s5kZ7DzzHLmb6WF7uCWmHkuPv0frLlzDXMleb17pXylf17zGsIZZw64xrTXfYrnFv1ZeH1ir3JTf bLiL2xq4I3+HtqVwD7vDfK/zXmmH/0H5B6n78j/QdnPP8M+Yn/Hvlp8OPBN8Kr+f3c8dNo34D2hv aF9yX5q/Dn6pdKzMX6WtLGzhDa3y9aFV4W9nDVexV3EreXoePz88JzUvb1giL85fpNFdbBe31Ewb WGBCSi7gyTcE0uECWzbzdbBuEIhT22SNDxjMjtrIyiLHmqGZKydFCkeSKjgF+Rr+nEEtynojHwhw PG8KIK0XCnGAgTJw+l2yM5VPyynRgu6SDCXkZLnQKpdHJvr3y2aTMjKxSndpHKtYzOaojM6W/YFA iDeZSBhEDqAdgXyQ46I4TqblCwzL4iMBrYA2C04xmUohFwtQZpOJ41h+6sPMEwU0Z/v0UgGLsTZS 6YmsVtQKQ4XtBbqzsLzQV+gnGycKpwpc4RPuD/zFZvmg3/wCpQA//Ltu1i1dlmMW2vJU29QR6tr9 EQwjyWCYs084KQnjp4mJmBn/+IxVWI+tTaKeUS2d0+DqDaxOM/8zuuTckhVs7Rz6Y4X2JSQcV/sg 7sOOImJArBFdqZTHWgnhQtFQEZZEc6XmSS7BSQQ3UoTI5ovhJYKJ5GROCatL6Exip4XEtc/uhDV1 GSux60sXhFyZ6u2p6tvVo/HqDVmLa+ZU+LlUam2E5t+lFGRDO30+Z5oS4q3FLDRAqjHoSUwzzlcT xdimr16kr/j6R4YV3/MmVFXVorHvjbPU8OCypoTTKnIM2pVu3jAepj77ruZFzr2KpTsyGY1PE+n+ bweMAIpETu6ulHTtMukyX5dmaPTe4l2XWJe807slyfiMPoYCmpt1pxStSzMajehJU26KAAnjbCoZ T6k5TZsFde0i5JUuDfWkurQbmRvZG1M3NvRrQ3CI2cRuSg01DGk7Gx6Dj1G7tFeD/xY8oSmbmWF2 OEVDlpJhTS2HE4ocBqmcDGoKOiQF5VA8IXm9yNhwoXFkOQ7TZDSZQlspKeHNp1iNS7HJhGQMCxD/ X+cQVuhez8jE30mKwjMZDcQN3U70cVTneIooc7TvMNHnzylJPAqitaQktaSe7Er2J4eS25NscoR6 cH8eU6UPLx30I0nf7pfOJjEwLZ7hTPwdNtSMOVTXyBD5KnU6zJxDdbV2fZFEW6ItWVskQaLB2AyD gzBDvBPjxAndhigOpjDF4ULC4T5Lma1VqN+fPG8pT0KT8ZIUQmWIGv8x6pv4JzSIFMYx+J7ff+XF 7dUjgcTFjeOj2E6o3nVBvsOVoGaE8p3ToAxN7cGWFkRzuUWXj49Xn5s0GuD5VOuVTTGTqjY2xi+r zoOPXpYLNPowle2uXkv1IZ+EBbfqko4XM/O0wZigKYFlEojqeK/XT2PBoZfomvygsQaITSnhuF4/ PUQbhujtNLWLhvSwkdkLYRfVR1GUj0N2eGF/5N2lJExUC8nidB96+AtnXjUDS4oF48RaqmO88YiQ ZdgRqq86B45Ufwuj1WtZ2PklXo06r3oNRZN+btLjOr+Lp/p4iHrKsAkIBKMhQdFiBRn/qLsQUnsZ Y62zuNJDqLNGxdhvHDIahozbjdQuIzQOa8h0pADq50uwACKgm4CvCZ611k3ytgbc095zulrr6UCv M0LWjUfmoX7OQf38rfG6L6qdzJUATvylOssgVh/C79w9Aii8pBnYadBipODVhtlzkHX5t/basj10 I3QPg/jVh4ZYdVY3jmDMnRijt9B7QBOYRs+t4yqVCskXVnTMJ26Zzamc2YzjGnivCizNOApuFkXq kmYPPgVt/5YYaM2YldyYgZrJuc1lltRslgQBFR5dkmsGIUO6UStadB7d1KIHg7h0oEOWkYlf6SF8 ksVi2CBBieyVyBmSoIbY9kYDyCMfCUnwXrFMcs9H8+N4Mn+VOQrzaIM4MqOjH2Yyrwq/OoqTiLK+ yhzY2kyJC1ugqITLQ5Xd/CETLWbE9WB98+3gTvOdJSYoetqEylDFwAfmG+czM5WZ0fltemVLkDPZ WAVE58J5prnmuaV5U6a3zZ222Hy1eTO/ybTJbO/2bPRQ4cryCtXHNYNiey6dLb6IlK4FWCZGD/Fl S8pctpAIWltJQBqNwmqtz0IrpFpjMVjaJRyST5vLndJyaZVE56UNEiV9Dwkt/MRau95Oocfux0s4 syU0biP0LN1hMOdGszDbp4Jmq8VSLKKB/xrNAHNJ84v4PZpAxb9oKwM1rA6p21WDrp5SqSEVqgI+ SX2Rmo7I2o3oNVx2j8Cr9ZCcLxdY3VZW2C52iKUFFp5iIV6QMf286d+uOawDg4MZjLfOIKMWkyvy SuoqV/i8tx3jr0/2CmMDlbFB5NFmHOUa5+VrkmwfbYFIjtUWWdTXV8wuTQ3EjM4prS2tFMNzJo5i IlElSjElc1kBjqAzAESnPWwNwGhsqrEcAK1cUYGlolkMCAFoi6KijWkPABIzwk5s3UpuqIGmByGS l8h5RZ5rz76KiJVxbwYMItl5oICeFFHkiX0CqQ7ZylMU9Ow1uanghQpmc1lSzGUv+gYwtfvNZROa yikpXJtQbUI1j2r+TJZk8rMEPac6ueZvSkvLlFqYh3F7z10P4PW4CRoM48PctaARXiBAUNnU7H+J t0xbfkso/fafFi+sqAkqn1Dze3fefOHUgGjy2gWLu71/RaENPtDYOWNR6/xNNzh8t107vTBj7aL4 lhXRaGNbrqmYXbQ9Hb4gs7n65sapLtba3nr/jHthb7uvsa88Zzni/ImvJk7SR4x3Aw+Iw3drnP98 yIg5WMC8bHRZgERSXZIFu1uY0S2YzPAu0sB8bsHnW/H5FovkBQaKd2IXwOHSeXSayw1klTdHllAs iW1UPszUghuETz/MjAqvI6ZF3kDd6kUKHdDoFug6fA2+NmQ0JlSAUa3MJRKFqRd354sDeBs1/nwY 77JYEqqDCATE+KO4dbT+e0dryzhkfZ2QgI8zh5iD7KdhpG2mW3tblMRN9BrD7fSw4Un6WY6dzcI2 zpW0nu8MuWZIXgswyB4gROCZnhTCWJL3IZm+x0gbP7N4kPiOWyyCtcvab91uNQyhYq+VBlYcItdQ c9R6zMpaEfcfbi9Z+9SfzqsjcjHaQcCRS2G8d7AW9RmsOLxl8q4Bwhopn0Kb2YRChxToN0kB4JPM lgCHtsKGiAJ9ZjkAgoys1Bce1X3LW29FBE9QTYNLlsCz6yERbdXSD0m12eHwnA09MnDq5of+5d1H 73y264lFdkUKNNigM9t8Q3nZj350ZamUoj4/8tdfnr5vqK2NPvjDOX4h1j+eGv9NU/PPX977Y9mF dOQsREMdSHtE4N/2cQY4qT8o/zfgsEQHMB7VzrN9kf4IhcPHBMIUCSKJf8CJPHXUeOsQ1ijBAo1E PBLfmd7Kq2OEUI5iHP7zIkHj3tiQLYIYnj2vdbGRCji7DQuNC5lutkfuCbBXG9cYh8BQ5ID8mnJM OQF+b+SnwNlwkXRJYHmsT+oLrJEGA1vFu53bHdulJ+Hj1J7YfvgKfIN9w/dH7mTgU+U0lBiqQ1ws 3hm+UxmKnYqxDgW+NHECKOgbRgIDBAEWwBqii77IUIQCESGiEGBLf2T7OeiAUxFrZEXwIzu0v+FR eTaIU6yuMq70VrGMHtIceSdsgZ2WbRbKkhcIjqQP9IPtYC8YBScAj3dQ4Jkb/Rv9VJcf7vRD/wi0 6OIpBgJGYGov0zEy06PTj1Dfr4UUMcK7d3BgfKD35AAhq0ymMjY2QET3SbHOYqaFwSuCNwbpe4MQ v1EB8UZraytsJUvWMBSOeDUHgCBhP/zUIWfZKAg4BD6KZCWSjKPPC+V6mhOR2ADEcQeqVATNTZOL EOuvBCGCDMk2ukM9vvGHn0B4YPj/FBqnhhzmWOy8K6dd9MiWb104pQgvPfgzyHx0HNq2LUjkE+41 4VDHtx55/KvpuXXo6WdMnDQYkYQKgyw1r05biTxBNKUZiRAVVyMwQmxACXqIwPKYFRICwvSkkBCQ Qs5Ge7/Qa/EdCV+hBF7AADisqDGMNCxi0SU4dd5GXeJ0ARVNXGMjTSwOLLny6AvrFsaHyL4YJcSJ IW/1sb1YRFcBxUzT+NJAfxDqwb4gFQyb0W3MHiLDPAYssFAPXbhWDHY7Kil8RFHyuTQ5hzwccwnD 5HNEqh3N1IQbBtplsLj4sLf3aGUMx1Q+xNLzCMhPjO6fPbuYxyxyQSZX7Mt/1/Bd41bDUH5PfjTP 6vmhPAXyngZ35hLjJVx35n6WncNCJT/FNNu0yPSg4amGXXl2NH8qQykKUCIvIGo3Iy04s13pVC5T VpiuV25WdoKdyjPsEfb1BnOCcyYt54sh5wx3MOk5PxAKzgijy8yGRjcZtXAjbGwM0+YwMEcsCjYw RHefZ8izx0OHPds9lOezdBeDwzypXBHXh2eXmOm56Rvq8bQFY+OD+C1K+INRUIPokZF4FIh8BMJZ MelPZAxcUk1waQVkDKhIsaoCG4yNCjizNA/0tmIKx8lCnNxB+hlp5/qCKKSIS2clY00de42xkgOH tOs0TL0xfajj/hNf/GxdJ5KQ/owVOrL2iEfOmqunckz7Ffmemcv2Xr/s6lnTvnrtNTh7wdM/IoLy qw8fmR1wxAbehMdn9Jc7V/78rX9HFI3XjS+k9wIXCNLr6xSd4jxI31nsiASBjVR1fLNb0wHEKVoK AAG/cm9ilMhK3NAdGNECgFlWHSzGxVM4lXcAX80S6YrOYw0jE78mV6DGW4cxNxgKZjMRDNiCJuha HLzsJWSN1HH+6OhZZRx0D4FdSBzRkyg30onaL9bw/HFMwgKrsHtZGrB9LH4hg4G9x/CoYZ+Bxj/F okfDnJjA5OxyhUPoOXETPS0ie/y0qEI+LNpls4VD31ThmaPHsBbvfbW3N9NUW6eLyJ6EDsXlUq+v D/S5fk0bfUoAmWmBskcPlMO4V6bpHUUujFVEmJBYqkh2L2zIFWXGx/c4L/Ms9y6VlvlZSPMMy3MW o3sus4W6ixm2bBU2Bx+jnpUOOn9FvWd/XzhN/SftFPvYPq4fPd0W/hX25/ZTLNJ0rHUTRfOYTxjE Jx0t/CxqNt8Z7qa6+W9Rg9QW5xbfDufj/OOmEe4gv9f0BvUH6oTltMnFHWORw3uMpQZwjccOJ1z3 sgy73uACmseNu+oUy+Jy9wb3TvdHboPbLf+rARowOMdVNmAT1Ymr4/ocsYzH+FIZ4hlh3+E8Kbls 98BVng2ebR7ac9rlGsJgze0cpXHbuI84WuB0Dj0Jt5c7wTHcMza3AWzBdEU36qJmwyu2aGATbIqN PmWDNtwTHo2lbXpoet1yQS7AgvEBbLYM4HeNjCE7nywbHsQklRl0oClCtvYqN7K1sTOLs1wDg8TR Bq2tGE0/vecAg/+738AS4hyQ1OkgiWaw6NfMsbJFz5at6ItfM7gvhUMZuMIyYp9c25Jrx+pbptqW qbbFky3dxpfdgq/sUxxlq0JgTOQ1zOeY6EuWOBlvfcVSTYOJWIOpkUQtd/U+vPLK4aWbs2H3Ww8+ 8dlfDz30+vgw3G0UfFe0LNxITX1n9eor1rq2/A7C9z6D7NvPtPXEW/VbkT3UCQB9s/EukKG4Oner WaKvsjpWO1niV8sZKNgYyNnSkCOoFxGN9ae6iBnUJhLWr8FfmBdqaGzdxMXVkBcAe9o+AuV9IoPX L46NCqOVo2PCWE0pjWJz+lXhdfz3KkHP1hn5CLCTawC6VA+mmTi6E5eGhBEhgzkQEruadOO4bibc SPaj7feJfW2zZRsnVdCHuEA/f/RoDSkl6+fdqexw70jQM+gZljm+zfRmi/EhA8xnN0Twv5DZye3k HxYeduzN8gKD5NTyhuUZKsDZDoS4e6LwQIgdoTk9HAvtDL0cokKOuOqFmS7k/GoNadHBcKxJQAQ+ Ai/evw05vCPU5/tgQ2YECro1lYai3SHcY7fDOCbW/X19RVK3tdXqSqVWxwuk1j2BSHG7DWISX27r t43ajtkYm6/xBZqh2XpStkaUC8ZwvAQb1e2o+rj35CCJ6LW3jw+2V8aRZ5uvo4lENenyJFR3QvWk AiDpigfgP+AIkJF0TrANp2JipWbkAk6uCUd6iBhMyPNzN7vhkwH1vIXjH6ZTF/j27es5OHBNT1sx 5G3uCIcTOT3wJ3r++JND0cZ4PDXjW9TSOe1bfnLTjGxrqBS5weksXP3rC+bgt3RMq86iP0A2+VQw FyyhH9BvEz1dDyR2tNAgKyyj1jSsWUiBBibHXHynYqhM6Vy2aspNif5l+M0aG72bpG2lredtnLlt 3u2d93nvk3Z0jhiOGA94D0hvFt+cN7rs2LITy04tk/2Ku1kouVrCy4xPcR0tFRl46JZIhwx808/+ f0fe6XTx3JAKRRXHh0Skh1Q8HS5LBde6WTRXdqp71JdVWh2BDx/syQwhZwudqlvxueLOyJ7IyxE6 Ur+G1OiSCDpXl7Z3wA781rIOHe3qaMSs09Hlgq4RyOnOVRzcwKGGA6cAS8wOsjK9oFt8Haa8D3b5 hnyU78fUu4BBzLUAtKNDJob1XQQvamy0L/gJrSF9F0JlGSygNT0saHCVtk3bqdGahPWrZsEsoZXK OXqoG3bjZ7MibkWNtw4ILtL4LYnFdNfAooiRutVwChIglcfrL25Lwc5Uf2o0dSxlSNnwmanJWDRq /FkXscBI3aQs05bpy3ahMTcuw5cGzJbiMtu2+2fBWSSKM6ugeKDd0+/5BRL2IxP/oTtIZtmCDQMP 6aNnhPqx7txRgZWCRnfRVBcNMTiSwmHV/b5gkdTorjT+eWwm48Zh/Iz0NUuXvQDXIr/O9PwWnHep wfQHxwbHSWMsM3hSyAwQqOtAZhBL/8yAcJIs5BkTxupKYfxjrCIqAn69Bl5DNyjg89HJSEsc+EXk owiF9MTg6TG8iBfvUT9S0Z7Bych5PXBOgrWTMaOb5y1umxkvBYJeCRoTalOhufD/GPsWMLmpK01d qZ4qVUmqp6R6qbpKpVLXq7urqrur3VBq/La7cQN+tUnjBpwHj4zbZoHwMO5kJhhmMrgT8hggm/Zm NoFNvgRjjLFhCA3Tw5IvMXh2CBPyLRk26yUw2ImHJWwy2OW950rVbjMz35e2pXvrSrollc495z+P e269l3GN5DfkK1p3frO2MYESy1IJan1jTKUuQy2VusTZSlDj5bEEdWVxo4pWSKsSaJO+JYE2b0kO xfHp8WXUaO86Fa1f1+g36eWQ3+dSx3ACXV69IkFdZVyhUitjyxNWLpZOxIS9uziDfzdJ0gKDHyLT 0C4i2ky2ImAabQhBsDWdeSJox0104iHIdCLQ013ZrK1Duay8RfBvMaORNfdogFyFFpOHkMQurqWf 8OfGxm3HD/zp1IvFAONyMnzx9sGF76xYXUpnehLTr1wyufPGb370whfX+8SGe3u92ESRdTtW1MdH r1tZa/++2jO047nD36/VH/5f6HLjwYn7FkynyxtTWKdrzfTMkXC+GRZVt4Nxev3TV+66/itb+vol SbvMe326N529ht53253f2nLZ7jvntl129vO1rVpP7tK9a+rRqAMLfcqPmdP/xdpcP73flo3JQRMG rsCKLBGErJSDzxIJjpDAygNjQgJ7HNHwpAAQqZQHaZmGhnym3tDLKOPgOHpThvSRKUvQRxncPNCK Kx8Sk1W5M8Zw5ZTJE6FM+isjrIWNsFjUBvGm4a2AN52qgyu7QexYjX5KF5MlB1ixqlXQBcnsJ0yU tj5IQKuw8FKfsFC0Wo5jBXFhiW64tR6EIdkge/yNeh13Cl2KOkvEL0tELkvEMmtbukiTbfuSBgdQ hjRnSHOGNGfw05wh3AZX3j8MB3Dl7NNwrFweHLClNhHadv04gC78FJZ1jHgXwEpeHTS7G+zgFMbN vMbnZwZnBx0HB+cHTwwyRRcaH5wanIYmcxCpHslIiUcZ3hS7ykZKX9fFGilhXTZjpPJHmYBZyTb0 ykg91ViBVL2fIk+JYZUoCqws5byzLDrIIp6dZufYV1kHC0xKK1OZXCVdHi9PlafLjpnybJk+WEYw KXi+fKLsKE8NfHcvSSNgTd8CBLp0Gtfp1rDYbNq5Om3hHFYSTo9Li+cTTjmB3B7FnQTxbFvKiGEY ZneCHUPst2b12fNoLFlNIvesSCaiGuJWe76urTGisZ1fGLl8Oh4KsD1m+9KI2ccy6RU9vTeuizRX tYcuyYYlPq1EqgEUdD5w7ro7V27+hPm99t9sUaUExKsKl6MVX7+mWt/QTlxTSedyIXZwM3OJpT2C Z2YY79x4vPioLtr2zByjclgQJMnkSj8hd3+GWDIyJPA0E5IYL5YghJd7YdoDcWGCFmg7NV85Amd7 /VKH4+PKrw7bw+2tznB7/Sky2lQwh8Q2ZHZm9mIx3LUTj2FIoUyQLNHaoQNXlyuE0eDrmKkfnxTe nLQtJJYn5jgeEphnFiEh5+JI8KtkDGTIHvo5vH69XRkZsSqmPDDg2mSCqeuAi4YvpSg10+UOweN9 aCbgSq83l/WT8eCngez9ZDzAk1njQYKBT8YPbnnaGkK57JIxYOmY+N7fPN46bjkr7KEgz+bQVG46 N5s7kDuTc6q58Rxtwi4HArOvr07KwSGrLPdYZVYjpVmRlToeIKF1XX4jFcTDQpdH1FRmBSdzoVn8 KE2K6uLcoSA760XeJnFxLieeTpNvNZibOM4v+3OSWWxKxG/UP1SfldC4hKakaWlWOiCdkZzSoeyh v7bSTUMKZBgDWPSetmAqlrwwI30xca0lojCpW2bhpamdFum6v38xmS2ma6N72bLu7uFl98i9I+3l yytxrzulJAoBFHY+AAeGu7uXtTPn1M1NTMjK8CZ07ddKqsznpin6/PXtVWi/cz+mWgMt2HzeVwgR JSiUhvf3wWFg0KRik+dbHfL8uRmy6NOibRaa/Vh7b5NLcOUUuQRX/ie5JA2XeOGSNOUydKBXrmCC Ma9gROOvCFT19HGw2gmvH7fJsljsEGbxJay7HPmmglwyKsIv3Rpo+IuHMPszi+PF2eJjgceSB4ou FX+YKTICbjlRZBRPQVdH9FRhhQyP5NoUUrzdclw1OHf0KAqYfoGiODf+Zn6OJK36tDncbb1mc3WD qRRjMQW/X4tqiekPnhTvc+n0rIp4FUEG3TMqo6rEOnj0/O+wxgi2wUPdxb/PwDsnEyBsD4IVcAYO 47EP8NsXSNR9q2WNs4Ou4/HDhN5O756ARBN2FtBg0U5qTJikkEgF+KSW4NMJlArEAeWgjv6CxQRW YD5GMEtcWNHax+imUBweLmLymHn5wNVbezNKXLw2I1WiF6hnPzncXRxuq2c/9d7Jy7LZPr97i7bl y/SXvlHMEApClEhRDg7zvQHmeZt+igoR/zLZW6F5ojVfxArT4/xAAVHYY2zwDqERqJhFCyT065U0 suEBma2acRHAUCHyvxIF4qp0cEKlgxMqwEmhgwpMZiXTvyoCEtOOPBtTtAL5IoDsz2K0kKcamPaC /QQt9A9QeZnjLD8Z86sjXs5PyJv51ROsiyTPLdog4lxxfn7+gkPMltMvYa4JQUq9PZbRgvCkY3wz 3aSDLgHh/w96v8bO+ma5R/iHxUeCD6fnmk+ybFNuKtuF7eL29M3CTnFn+hHa+17qdJqe8X4+8BLz Ev8u/S5/Wvxt0NMSW1IrPai2mqv43eytvKdKdwuqpuarzUE0KLgjwiZ0pbBRdWSFLWgL/7bwO8G5 VlyTftH7Ivu/WWfMGxXSyXR6JX0Z7/KJfMivcEk+FUi7rmI2Oa5yTggbxY0hl8wnk6n0VbTDZvvV fonQNBIYVm/g3+huDnF34bHBumSd4/BX2+iGGAUzFfA5wmcAzYSP48q/Ej5eqTQHL+AaAmsAzxzH AmjR4YfFjblJ4BEtBkMhQU4rKbmCoYrexdLeFAtIRc/269WRRqp/BVWlfJjv5NR0WEW0msbYsAfR YYRomBicDiGHTvOsIEjsAEXFjqJT5qjE/dTnY12Y8mVZYn093AxHn+HQCe4tjp7m5sGnE4vNSUhS 0k3UxNCGylWrVEWoHCSTn5zjFTRTma3QlanB5lH0uScz3/0TK2hlN0SSYnR5ubAbZo6CBW1y15LZ 6pCmdliGRwalCBOOMDxM5j4EOnNIA1bO2qZkS4AlQUX74NiC2w3hRLt37wKXz247rI3aRVlzCgU8 bMJYX0kXsOaFt6SJCa/Aw7TA+UO+pg8KsclbhdcqIMDhCbFpz4SwvUPgbxcHrPxieiMTcbnc7hDR aWqdjEyok0u9b+AC2gJGsuHddZwnk0cPXPnZkffeu66rJydf2l6ejxfav5YrY+3KqmzExwdUJdIt IsH5wNldr60Iclw4SasqXVn2Rvsf78pUA2wuhyKhWA19un1iYlBCuZzoi2WuYC6bWx0Xs8BpLsEI i8ecJoK+3MFXMQwvCL4Kcy7ktu1zhGcgwjMQBzDb9oX/M9EwuA6E4gBoEVf40fO/fIp4x53PYebg gXxkVAiyKYQW/eJuAB7FvkXznYVJFsCCt0Rr0EMEJYWJswjc4hTlti13ls2OCBG4KQv0cBbzIhUL 9HBcLHoR8G8RnxHwlKdnY/OxMzEmRoxlq+pQmkPNZXUUO+Tf0T8eQ2ZsPDYVm47Nxg7gE92ckXKv 60JGyqVnO45yfEtuF0uhnJ+zu7HCXRrL6rMcGufQFDfNzXIHuDOckzsUXQJbLPjeGr4AVLDKTOxn BKdcjE06lHGXXF/dbrUqSiAtKQURic4HPhrZPJgkOIQxH1ltoWciRVw9zOPUFuYfbCkSmyDa5gSx wcZE8mrFTaM9HX7fAy8UXl8PCQiEd9xTJGcVewdWdc5a1TkLWswMnLVqZPUIOW+EEMoIIZSR0TB8 22jnutGOfBntdIAr/2rKcO4oC92MFsnlRXJ5cYDEWEHDAEmWMgCxUWTuwEACOh4gSjCcOkCT4yRn w4BI+hBJHyIEtFh9qD22//NFqw+1m/hGj57/hemDU1XaPn4W0yj4S6NytW/lGgBU6uqNm0w4p7oJ bdi0c9PeTcymza7VvZJW8rmHS04rsqMKEm1yEgOrc/Pw1xFoi4jroqpN6mBPWRCKpHyJaAmLRmtz GHePe/e5ne6Nmza7pd7VIqF4USUOVLVIlOAiaSsOjJBPI+TTyCh+jn9+2nKpbh0AMwI0D1j2BFJ5 nxwdGNg6CjIeGkc7IwhXfk+Ojo5ObLUHjri4F/Cdkw0/AkWe+XirBUwZU+9B//qNW5+nVp1/h1qJ tyrees6/85QiyRJW3q2/ibiZqLtPTPw2ysxgEp8AbbvoR7MTWKlWjZR0lD57uGvASPXiiunrGjVS q9d1iUYqhvXqw9mikeo5yvgPZ0eM1CpcMS/NbtLHRjamNq3wGANjZtMoeCi3tnrzFngxWoljfW6X w+levaq3R4qxExh9CmIu06OiafUgLBKAGiY/YFSKucGeATQ9cHCAHoC26NiWkdzoaHpsfIyeGZsd o6kxYYwew+P6SDhaH5vaOnGU3oZl1l7pKNpBMnJeiGn5APTyk1Yx3Am7hL8W+T9GBFgnLpZa1Ng7 OntXjuP9Wjaf4zIJFOC7AtpSnR2r7LCQEgS3DFgq+7+juNuyhFjV3e7YBT6y2OxeotFfhGBraHxH sPyZ2ua7I59+YP3aXZmon+2/pD0cWpaJsY64vrlx0yhNR4ZWtXtHmz5nprShv3FVWe5d317W6lMI ztV5FC7Sp3bw+e4d2z+3fv2mobvbt21Wo1jBjwlZcRz9+XTFbKzxFdvridaPpdKVuK3XTJYG2pFt /fFcLr5sE7rmG6UOHuYoivl/mJPV6EVO1iCcrIfg4V5rwrSHj2aBJVTgUzaZMzyEJdnZWQg/8ESJ ec2ee8R9PAjaCuGMggU6D6dHqSS5OEk6SpIukgaxrhkEOBsdgGxYEI1UPrTn5WDexsIVBpWgcz3A SLy9RDPr7fNDkk5IPdRl2dtMb47P9bmVkhUlVq1a+YVIrFjzYmi8hH8IwEAEy8h2gW1cU40S6zyx f/eSOrmBXqt/Puch0tNDOIWHcA1PlIRfRElT1ANN0WijTiXJmUnSkCQHk+RBSYRGh10YwEzgDMNo 1P9YYxvGpkMNs7vhacD472mMN6Ya043ZhrPsQCapz+BPBxuug40TDfpgA03hhvkGk/REjRRvGd4M I5Vb1+UxUoF12aSRylqGt169e6Qn1bsiQWX7auSJc9kszwfYWDTnnvWggx7Ee6Y9c55XPQ4PGN7i Ri2Z604b48YUZF6bMWaNgwZDGYJBk9QYXjzgjam6ZXwr/vHGt6AkMy6HJjOxBHK6JKfSGcZkAhOZ w4R2E9vbf2h5wyNyaeMFEFBD6//LV9bfrEYDvt7L2stCZo11jIzdfpsvAAMxvKqXT3fG4ekX128e vrt9x5a0TGxu/AZ0+55dX2gnJ6NJPNJW70Abv7NGIZYLzLRPMsfwOOOpJM3ZIy2BYaAV3EjgnKXT CRAMzSkOGDtwECpmCBod5DRHTPP4BI2yJKMVwmZZHS4EV3jhOJynwMVxoCnFESYUF+YEguAEAt8c BAdA1eFIcZwVJEFEERAXlkVUxw27MjgTQY9Gj0T/Dv3Yu5B8w+sK/ppFa7wro1siX0Rf8t7PvxF3 p82+hoMER8yl0UuRHyu0mUZrPZ27CTrgpRcx/t+ASdGBTsB+3DHlmHbMOg46XI5TkEi8ZXJzWMVZ jAuAuGAwzBbXHyxctf7g+BXbnuBSa59IO9ZeuW3rcxAJTTnwlj4/DyJw+da/oRSmj3JQYabvXeHd +JKPWDpMXMjA0Y+SQS2Qp7VEntVceZEPq1QSKSqKenFNcuNayC+oKM7gXcQXUynZiXe2ztz5I5HA mNYw1aHlW03xVvpW153snYE7g5+L3irdmvBMTthLeHgTgtiM4y0Cjhqf5agBk5m1jIedYr8/Bt7a cNB2uNDUiXtuuu3Vva/e+ek9P72qcdNlc1+49p4bVjOPf2vf43ednfnOX/zgnj/cPtL61t0vt395 4G8/+NIUxN7+ob2OeQbTmk416S6b1oxlJN6+j+2GAtwB4BEJyZTKGCHCg0MqCbdXwbfRwWuE76qL UbgqUygGHQGX8oyVCNn0YfhR0QL9Ey43sY95KcKFKYSpE3NYjNxOE4Z7UVjuvPASZqzVi6LbjlF9 588+BYTYxwJNkhA1ll02hO+O0G2I8MiQaskAYr36jRknYE3FZxVcAZ1CcgDfjA/uBm6AxOgKFmdE i9E/J+zwnyJQ9T3sMqDWprBWuFq4X3TcW0LLSq1l60tXl24Ubyzd4rlDvKP0Z57vuN/1/MHr71m2 tTZRv7nuMJehqocpGMEQhlXyvV0hDK70LKVnNugpagUdLBYYR0XoR3AntBvuSZYCfb1pdpalp9gZ 9nGWYd9TaWLCi6vqOIStzmQQhHtaIZ7OzNQQBPQSZQaSgdqxvMAOwQIbW7TAMgEB8I+VZLfacPs9 Wj3P5Xu0hrtPRVU/3tW8/Srq9VXUjyXZJX5ETIKMVossLohE6FDvAJhadIlPwmkxTJjUYwMdGin5 1fs3/Pkndt03/b11/YW+WHN9W5UH9FBEyKYkDdW9gc9etePSKz5hbu2p5pjm7tfvuPbmP3vt9CN7 I3y5/e41tZSmoaivdwdz3USPFNjb/t7O7NDWyz917H/sulwKgp9iRXudg8K0nKSK6DWblpU8YZX5 SJTkecCqdMrWpQOgk5DITDu7C8EhATACExwD2YdI8IvzGUt1NgV30sWngllNchkTQZ87YNENJpnW UuV5nlCsRTTz8W5gofFuoMN4N9CgwiupzQKDygRyq5I+XqbN8kz5vxYOlB09Sk+m1T1Y3CCYipnZ 0L2muJUfVyZS45lt3duLO4XrlOsyO7vvFnYpe1O7MnuLX1T+svhN/uvKN1Nfz/xV97eKj0W/q3w/ 8YPiseiP8B38oniq+FGxWy3fot1S2B/6Rugb4fmy+6oQ6vIEsAat2xp0XOJTaSarGAgeK6slJbfb FYjHqXQ6AGRXpdJoFtFTaAY9jhjkIfr+e/leITIeoZ+PvBr5bYSJkEiAyPJSJ3YScgqcK07utlKb VomCfbp1Dugx2MkyLOUKoVgullepQgjvtGhWRXoYQig7tl+IBd61e7AI4cDFC6q4na/Wjp6kCP4e YMTOchZgD2Zukmrr2n2hwWRYuvq+tV/8exT+2+ZUfqjxp/qO1vSBv75l2SeYxz/61Na+hKYJviaG vjdveP8n7yJNVRO5c1X0Qyyvf/TCsfkaZXmM6acxZRXQU51YyW7CI13pmKgTcKpLaWSr8ks133QH 16Y7iDQN3IhESKSJYp4mEDZNNF5yIhIYKSqDMVei8pjsAhv0nfpendELboljMLM6Dhruaazf/htU Cl4u4WJ3bxa6y+Nrd3r3emkv7kBy4TsljFIkGizc478SRpkGiwDQK1RIvFU63W0ssXAKCyTeanIR Q8bNnVh94/voPt6kTf4LDrfZjbZ3ozRwOaIv3pvVdXUkn9JXUKyvWwyrAnJIsMRfU+AQN8EwlBtr hNtdyHQhVyXdjbopMZdOp1U0o86qNKUKWEOcV0+oTnXK+O7iDCBLx9t9ctduO8XS7tOToj3HkVri ctqN8R0WnJH+Tlx4R+uKLTpSLzL4jd5yx8Caei67JRKMlHtC/ssubRdXdcms059V0jqLIszjr7yy vKT3rwwb17TXjuoYvOWiRJ+6/sAlCQBwmF52nD9J/wzTS6+jbtOLXiP0UjMBndGI+EoR8ZUiPq54 dA7a9QzfYT88CNI+OM73uj06n3EEi050hxPd7EROrYoQ6nbLt6fQ9SmU0lQFTSnTCq0EfVRrYXIS Y6AqLnExCaHZQCIY9x1/7bjwmiVJF6mjL8PrHkd3NBWsOOnuXrfVjRxc70Q3Oe9y0k6t270ihXak /lOKTmlBH4I7fN9UgFp4vtaneAJEi9GDUOh6rc+WmAtWuQBxs5OwCQsLky1hgcy6smfCGN6SXKKD wYrpa5YKvqYUnuC25R8Rvppzsm62wBpTtenaTM3F144i1dyH2eVP/D8JLOQWtH/Mvp57o/S24+3s 27l3S75gqzRZ+pPyntJ+tJ/ez8xEYPWnmcT95f0VP+SZYRkv50qwpZe7fpz1JJhoOJiIJmUjXnrI +xD7iPpg9sGcL1j0F0rrShtq22ufMz5XujfwWPbx2jvM2wnO8PSmqOfoFEqjKll8oHiIeq5yFCmm 2C2l5OfiKSWtIEFR8S8HB+XnonCwKxjMZf0+B6+TwplC/52qVLt7KQp+VOUeWZZgAkc4WoUflv5p EKEghCL9FiLNmLDpm4a19qb5WZ7hj6J+U9YVuZL2IE9pTkdTZPIvAzOBaf0ZpFJ9SH1ifWdwQDYX ohydgyjY8xk0OdGsYlx56DzCVbII7wdkySFQm04uSfOCUSmL9bSc3xf2+32dpC8TVtaXyd0X5X3B VXtucEX1+utU0VpALVEw0qogutxpMZNALsOToGBZB8pdcCZQh7GD7gU5RD5yfyh8KH5UcExOoN0k tctWU55Dc/QcM+d72D8bmVVm47OJh7q+kZ0rcxgeFyGWCWK0TF81W839RemR3CMl5+QEgGaxoMpN b0FuIpNt0niLWwG5CvHjs80KbiqRzdvkhFSwFVBhB0mV4k1SyM2cFdactQoO0hWGmiU7F8ShoNUX H8RfEcRfEWyW1CBcc8bkeXwa32QEP/4eP3Rwxgz68ff48Tl4k0SyfXyK3sV/yJqzB6lsFhdmii0u qgV59MVaZ9JUTl+axoaezeRv/8SqzWp6+1d+8tytG2/ORGL+TCbxretWbrm2/cty+ZG7+sdqohDk mMfbLz9447ryYMGorL7+23seSrEKWv2lB65orrxmdqi5ZddfxfiAhHlY+Py/0MOOF6g4OteJIE6a QczDksSF7uOIAYaLhJAzRKohIshCnWipUMevHoLfwkpb4vOU+GjYAaHDFHJhSXbuxPHq6QVbhr3Z mYV3gT/JMSt+kOwjS+px8HoSONWpyIDniHti2od8fBxFbgijtWFEvs7EpIi/2xdHTqIcOIkxxUmk oDNkmY9c5E6J/At1PHyhUDKxxJhC5gG0zp2YnJwXjgsLk52YBvxa48coP76BEa65HW2n6VbyIfEh +fnI89Gj8juyey6J7lfQBm6Dfzu33f87yemSIpIuMdGIJCsMgl04fgAxkR77bpkemkYurgE3HX01 8k8EY30yHP8p5QO/X0nFwrNSTR5M0kkKIYfDmQuPh9BMCEHKvIOh+dCJ0FshV2gq8f37O6rBOWuK 7CRZ3hbWO6Fa505anjx86CQSYc0pQGdWvnmyKh+JSapFsiLBVAM1grjyEDvcT9Y1Wff667VC5lJR z86sqGzt/vLALeWY4Xih/Q+rzv1w4lKjcN31te3X05/JRG9Yk/8kSEb6/EnmHPNVSqN7bKqK6sSG 6LFhuU8t2B4BGw+pKVvDPGnFZKgKOVEJEu9DsENuwY4uiisfkLChYK6jegYkzeVTA5IrWQr43BCZ /xSonh6Wqr5ZhOhxC8Kf6oRmWLnE3ywuxVFb3NaUBcbD+lSfFMhpMdyr1aXPxsSs5QMjXjFVIR4x hUAshSV2laDHk1cJ5akuyyuQD4IXD04JdqKEoEJoLxjU80vt/ngnEHsj7OZJgAUmQgLEMB4k81Ea SAetQtVBPhzUHXXfQHpIXZNeozoVT2gDaJ6ZDSlNz3p0NOJOeVaoPi3pOYpWmiGW0jQskuB5AqyP 9fkyZLpUgDqIEI+m0Rx6FTkQCZELykouGBwPzYboGbw7GGKsPI0W2WGiy7+492KcBgspn4O8KJ2l RkgqWrjzRaQGISDxBC8meCVBCWJcSCYoYqgjK2tOFjuOOGteVIcOMW5zNzI2dYrg32Wu5zPRtB5o /6Z8290rx3aVEgNr0MhEq/jZ9c1tzFfP/WyOzIZ6ceayiS/NoIdG+uJIO/fIzHj/KO2+fIDWwGOH afQ0plGVfqGTU8hLKUEXWdNJxJuKN5r51RMUBFGcPnWqVcUSoXrBptYrsd64x+vtyuDrfGFi/A2H XCLR/8SgiyYteHyrpKJCP8eLF/5bocbVN48LZFad6Q1exW6VrpYZmSTIbXSBFLo20gjLYSXr7WIz ohrMSaqsKkPeJjsUhOTWQ8o6z1rvCnaltFJeq9zg+abnIe9/Vh6Oz3X9N+oxz3e835a/rTwW/5Hn Ke8R9oj0tPyM8mx8vutn0ofsh9JHSnnOi7pIjNlUnZTFXqtMGVa5erVV6rpVZrNWKYqkNE05Uee7 7qZgndpp593q551fFPd3eYc8dbYuNeMvueYzP1fc97H3S/tkZiC4RqJDUjgVouJqigqyYgqPgnvN kleRVUmWe7xs2Otl44qS83pwzeN2OR0OD4ZkoSCGTZRLkX3SUYTF03YWCWyOnWOPsK+xTnaPNw5E LJiu6gHPMc8rePTu8cq3KpAYQaW8+H75YN1rB6GTGIK+BhRPcw3KO4/VpaPo+SNCF5rpsn4NfBaU R/hQPQOMVRaKRcjkD/xCOSe9DQlYpA+U01Dulk4vpl8RTgN33WenXVnM/vPvJP+x0vvs6iACQvpF BOHbT7Fq1N/CzOudp3HpzfkgLO8tjFJYCEtmQ02PimEK3uzoB2TNLurkUgmFiCmGZFexEwHBhA9d RI8ndCPys9djHl9XHRXr4Wyi/azRPhYtpMU+5qtaXs32tF20fzAZ8PI+TXOIqVVnf8M4+6uC1wO6 8fmTzsN4tJSY4/ZoyWdSYoAugZEvQHnzksdR0NIu3gVk3mpVq7Hm0vxbHaNeHkvPFSQ6MkFUCrKX iFnBY+2lvNdBFUjnd5RQibpVQ5rv1gIq+KzeS6VyJlMp23Zp+K7WZAtCQcmXWeE45FeNPxEkaUAS rUZUxwqmqOlqZXvlBu905V3t3cLvtd8XODjhUKhBzns5nq5nKhVjR39SltPxrFBxsPlkvpRv5jfF Ho09Kj2a9/i0gdyAvoEaRWPutZ7VuVX6WGHMuM89I8yIf6ndV7jPmKk8LHwVTtaeFY5pxwrPV17W Xi68ob1ROFFJU06H2xVxxLyaW/cWXEYjtlxYLo47r3Rvlq407vftF+6T7pfvz96n3ZefqcT2ee+N 7cszfu8Eul24XXTgMYHfpqaxyI1HhRATU4KazaRUyiilKJ4NpPi0nEphtf7eJyFw8Oj5PaYpaTnV 4/Z43TmjEDaMAqYGTe/xeMMejxejEzmSY7Uwy2rZXK5HksOSJBv5rIyVdTz+WPwenkWn8CBKoVNP phEvwieBCmBsgqWgIGAFXqVoaERUCZ+CB6n0LLqR0igP+q7JF0x8s7lcwaee5T/JYp3qicPz1CeN LMyaiZjx6riMDsjoOflV+Z8w1/tKroqHd/xpldeQgF+6PVtEexYJVJ6K4BHOmWx1ex6Z+RlY3QWd Ouzdo1c9z+Bh7sFwilWpApopnIHVfrDsx5cWDriJQXXcQDOw3o9gqIZpHDTmjROG25gqL6Km0+BR lpXT505ipWeXPbZxk4Ib8GHppIKhFGydpeQUKzIKIFYnKYlVP23pWZAVjHABiJXydNiBZ2nLH50V DHKCWQmZSLJFsJFhdgG8Ig/p+UExgQlLIeATScjOv1iEoThzKNbUoIiQT09EmovOCotzuCzGQVKD WWyjw0jszyjLWHzEj2awGF74u7qkR4fR4TWpsOfEC2G9iTJbjPYrxv9p/05r/yI5OIz5iSOVSJfO /Qv6wb7hWIDRNCYmZMORc++jj/rVUIrWNP8NZ9+j1557mqHX1vyAGeMUxfwac5hB5n0bM3J5Vqrn HWUKd1XFfOZwOSTQgxDiSJVTosVoqlXgMvNkZ/kUQJTuC65k0X7//sB+cV9+X/113+uxX+i/qHn5 Sp7VfDluN3ur7+0+d2Kowm/rd1RazpbQEgfzrUKz3jO01rdB2CCuSq3NjxbW182hzfJmbXzoVvde 315hr7g3ujf2NfecMCc+Kj2bTwWcvMCLfCktpMV0yWCNWHWIFYY2ebf1jw91YhFz+L7vGESD8CC3 VVG1kq9LrIOqwDOkKslks1IZanYYWrXaapElIoGjzVt7eKZv5/HYjEWjer3eYH0cV8Pww+2W8/VG vdbQgvujVRGJDQxLo1xyjzyeQqmqtjO7N0tn92dRVtYqlWat/L5h6LVx/GvvaaCG0+nWZLc719DC jYbGRXW9p8aFazUOv3nJy8Vquib7Bqt5iWW4urvBJ1Aijd9EtQKvAQtwUQSpXHGUUbmcSiVZDkPM p3ZGUbSiHUWBJ1UZycBXOaFhygflt+QzsgMaQBrLz9L9VI1yo08falR0zA+epGqo9iz9AtWkhuix JzPH77fS78Eaq8XJ4q7TH3SWcZzsSFuYsC8QvAnL6TaJYmMnsSV5+AJ2Qj4kBZt7qtIp4eQk/MYn yQ8dbE5WJ3GLQD4Kd5/CNbdHGA4M7wsIw3sWFqBY8Cy4ceHBrSSGcZIkO+mELvrwmGIhQvH3T3ub MbAy4Po7sEJCBJRUb0Js+c24QNKkPYk/QGmGYoGWE3yabkjc1w+1IYAiuDQKPPR25gjf1FQeBP7P D/Ew0fgtXPRB3iA/PuAnLWCdyKuwibhNhOtgTQUACYeCViFakCHubwr4BxDxFjODTUHgmyLeSmYE FmIArhC1iiBZKBRsH2fMUKTZ74k0Cz3hpoE30ROF2EvcWbRpmCLeIs0+2PA3x+Db8RZcEpT5b/8+ bhFBFx0gbKhjCCERnB384g4tRmxiXKNftNzmAOCcOHrcyGR90ZH1a7ryqL8317tpz8mNa5rt8bIc Mu99cEW53P5ZLp7fNv/DdVdcghlTIib1CV2f+cz1SiSJ2ZLUtfvR9tE7eplcLhyIxSYXFq4WJf3/ s/ft4U0dZ95zRhfLknzFd7ARYIixjTG2MWBcYhKHEGIcQgwBYywZJFvCtmwkGbBkQAJCKaUJTSll vZRk82VTwqaUuK7Lx6Y0pYRNE+BhQ0rZhKQJC1k2S1xKCSWUWPub9xzJgpDenn7f0z/seX4z75nz zjvzXmY0GutIPDtbk5S5OnirZYr4RMzALNU1rExF4f+dYneal6tia+6R7snEOwY6500SC1MCkeJr Sfs4kVyQRUQWHQy9mcj7JO8y0r0TTywNLVnKSpEVnccykxK4t0gqYolYHsZ4RR9xSUnFjJUUhzc9 7y09iveFtDbIR/QH4h+uWfQTNjx4g6UHr7AMLPT6eOUjYP8SLZ4IjM379ng+rKQgxVq6UfOElkdH axJ16bqM6LykjHHR2YnZGePypkqliZOHP5hoj7brHemNGcuH2/PX6Dr1nemrMzzD1+R/Tf+19F1s V/R3Mnbm/Ss7VXJROwZ7kry8/NxcvUQ79XSxvc8vUrb343Sm9IyMwlx9Ehjy8/JoY5+Xiya5GdFq vS4fZTp2GroxyhafvvwwFqO9Z+KYaZlxJampGelitzD8Kb30a/0V8c/Sdv1v9Cr92nujH4k2R6ui 1+rEgxCZeWfixAMNz5i46SlzvjQx/958np9eXPKi+NgYfemda+6FpSsvfH5tqfiWgM+Vj4rN/fxC nvKjXKHvwNZFvHKLb01MCH9t4h97cZZWiqUh78u24rQX10Y8zCDeyU6R5O/jNEr/kjxhwqhfn0iI 0o3Ok3LH5qRFpw98vfQHj06vmlI4alqOPuvB7JkDP44blR6fWowYvifzngcGiqSb43MSow0x2Kyn jYq995bziS2V+bnFKXEzFj/DfziyYIwx3ij/+pSqBdGbLL1YMTFRp05TP6N+JuaZ2BfVB9VRz6RK MakdMZNK57FFcfOSVcPVqbHD4urV8+N+rT4VF6VEZY6kSk1RxfFYjfFhjeTTSPM0Fg3XFBq1lXGS J04yx7XF8bhCrmf3fo5FkrLBXzqchre27Hp8/MzkLHGslV1RpNH06rMM6ti4uGyVOkmlUqsMXB0n GWNTY0Qv6nkaSVMYY9TGm+OkuEKJ6+P+lc9gsUzNZ1Tkq6SCZ6BWwbwYqTCmIqY9RhWTMTH13tRH UlWpxgLDZMYlnp6S+k/yS0j1tZVzr10QP0iLALi29EI8El5HxJP1IguNUXn2F+/dvrr2aJryu5pK QUs/c+XhTRqt+7HBUxXRWOVVhcjoAywxIOIqxFV2ivis+rm+lGnqnCRBnu1LmqZuTxTk9r7Eaeq0 ZEFe6ksGGUfky3G3L5r0W0qqUZOlUfRVrmOmjEqWRtFveKrqDLfOcsvA2w3lw4arc7Qq9nm3VO14 ODXeIKUP/Fe2Kjd9TNGcgbG33h6Tb2rCnkoajpXrIc2T2D5vqKhao2rP4UtUNYnNKmuidZgnUZtl sLfpJb3eoE+2JyUwuzQs6/sGfZd6anZ2WtTUUaNipw6fkTA17YfJEJWUZEouTK5InpfcnqxJPiSN xWa7+WUvbaDl1+NreLEup03w59fK5a8Zk38RZZry66TJ9DQxbSvpZ+txMYV2n/Q7BfRrBaBVD33v 3ws6m5s7C/79ex2tE3Z8a/t3JrQOOMakfvi12T+dPHtt7PjYrocmH35oy/mUMSPWV03/WaXtcMnk I7bKn02vWo/AeHlgFv816eyvmLM6URqrGx/Na1RLEm3cplrFO1Q3MqOy9HaTQTplkAyGJKidAPWh OgzRlfAF5ZMkxpKSkg9KY394z1vvCX3vVPcT8e0Nn4R+P3LpSllh7NaHTQ4plTqo56DuIXO8HKlw wbe/tX1XQaumeUzKh1tnH5YVXjt78k9nbzmfOiZz3dzpP7u/MUJhJgX7pdfUCTyWqVim/H2cesYy NKEv47xYHX+dTZwb+jLOBPFlnNJrD8FS9MSn6gcsRTKFjrSS6PP/yZSnJCWnRGl0ujRdJt6WR6Wl Ks8A8Ijzz8gnAa7f+SRAWuptjz+yicV5CcX3vnciXn4e4Ifb0yR65jC9qKikPe0HaVfSVKa0eWm8 ApklbXuaOk157jFNee4xTXnukVqNTc8oGXxCYM6Y5HtiZiZlJVfGRKWwKHpGIEbKpocD0sUzjfRw wHbjFSMXTwhwY0+q8myA+CDZJ/Kh5b3lidNuf45RPMYong+QvuTRRV/GnY8sqn5wtwcV4SVMGWmv dBpeSvsJvPRjJqnEb6AefFkjTRRrkuIgae9AotQvjd2vtNEM/9NtNMNvPqNpGGwjsS9rc3GwHzZw SJo12Eb3Z7TRsd8f0kW0if8z2sSz3xyKD7URT2uuQ8SNZNUVMSOyKjIrs6KYQcpUif1rxUh9Qokh QR2XeQ/LTk4eZRopPj0qPaIz69p0QZ1ah6klHjWd+AleuN87msfM9UvT7p37aQZ6Ghv+2gLl2y4H fwlF/gjnuur6V75SVFk4Oi0zecIk01eSDNHGYnJYXvK/dT6VPHzy6OKY6PH5j+ZvFw8HlpHT2HQl 7ZKSItJC6TtIQV7Nffx7/ANVp+p/1Kc1R7QPRyVEndQ9FP2YPkVfH0qGFONXY8R/tLfEzYzPTeAJ wWEjhn1fpKSpyY0pG1MT0mLT3soYPfyZEXMyqzOrR04bOc3UgvSq6dVRyUjFo4rHFGbPHxsY93HO O7kj8u0FbOKSwq6il4ufKVVPOTi1v6xmeqD8H2b8oWLczDX3xz1Q8eA3Zl9+6OM5VqT3/u7TZ3+b 9PCBoTSUhtJQ+ovSG/9P0oWhNJT+DtNAVVpV0VAaSkNpKA2loTSUhtJQGkpDaSgNpb84bR1KQ2ko DaW/p8TEnyQelEf+mORnWuZiKpYdfAr5lOC7yMsoLw/2siSWhDybqXA3G3czkZcF65CXByuRLw7a kdcSXYd8PIvD3fEsgfJs3J2Itr3IpwTF9xqWUU15sBh5HWQW091itMpEnkB5Njgng/8J5GXgmQx+ kdcF97Mp4H8XeRzkTGHx4JyCVoLODHYjz0a/U1gR8VQGVyKfRflsyquCB5HPJ3oB0QuJXkR0LdF1 yMuolzL0Uok8Hr2XoRdBZ2K0ZeglE3kl+iqDZJFXYWxlkCzoBUQvorwOWpSTjuUsbuAG8ni0LWcJ RGdCZjlJK4e0YuSzKa9Cj+WQJujHiKeGeBZRvhj1D7GHMMIFGOF+5PHBXyFPQKsFbA7qF6PehzwB eS3RtUTXEV1HNGNl/DATv88g/lZQrqLIyKIrQXMWKyUqtApR8oFCqyN4NCxNmq/QWjZaCtVHsVVh Hh0rZPsVOpptlrYpdAzv5okiFulvsvolhZZYnPpDheYsSjNZoVVsmmaEQqsjeDTMqFmg0FqWoGlQ 6Cg2PcyjY2kalUJHs/s1LoWOkeZqfgTJklqFvoxRnGgN6PioRKK1VD+a6CiqLyBaR/QMoqMVG8q0 bEOZlm0o07INZVodwSPbUKZlG8q0bEOZlm0o07INZVq2oaD1EeM30NiqiTZG1McSXU+0+PWk2Cgn 0cNAJ0Z1EZ0UwZ9McmQ6JaI+ndo+SfRw4pFlZkbwjIygs4l/N9G5RO8jegLRBwWtixi/LqIvY0S9 MaTLi8zEimCRSawEVA2zMxvKuayNOQEP62TtVHM/rlygRd6AegdxFODOTNaCZGLzUdeE9h7mpisb Shu4VyG3grMG91up1sSqUa4mrjbUNUCSCXfFnQbAQ31YwSPuuVgz6tpY4181vjs5y/7kOMTIm1gH dBJ9l7GFpIVbkWjC+lkAa00ClQPpDrYcd9twX4zQg7X6bvzCwoP9yr0O9jmPPQZJNXfRqiZMVZJe qyHDidGZ2CPorZF6F3cnAI+hnZDWgppOxUYusqqQmo+ahcTvoXoTqyL9hJWdqDNBo2l4zSjCatcG 7U00NiGng/wovGJXfNRIEj3kLXHdThq34q4HSXjbxJZRW4/irwewnlYhUuS2rog77WQ9K3pZThId ZLPV1Ndy5HfvV74WvMuhbwdpYSXeNuRWut9OHuykUTrpbjvZQ5awXJElay/i2PQFzdvImp3kaQc8 a6KIXBbu627jcn5B9p9vpUHp1rCfXRQxHhr58nBc3117ufcvjmt6hA2EJrIuHuovNGOEfFlXK2pW k+ZtNAvvrqls6YbbrGojz7YpuayVTHfgqp1yE412VThyZTmCswUcf9RHL5qKCieVmGrsNtPcNmeb p7PdZrq/zdXe5mrwONqcBaaZLS2m+Y4mu8dtmm9z21yrbNaCGkerzW2qtq02zW9rbXCaHG5Tg8nj arDaWhtczaa2xi+XF6osu1PGfFtTR0uDq2yhzeUGo2lywaRJppy5juWuNndbo2f8YH1RIbVFU2o5 77G5NeGuakRW6WpY7XA2mR5pbHQst5kmmB7zNDhbbJ0YkcvhbnPmmxY6lnvaXKaqBpfV5vSYJk0r Llrc1mFqbeg0dbhtJo8dGjW24U6D29Ruc7U6PB6b1bSsE3dspgcWVM3EXRddtLvarB3LPSaH07Ta 7lhuj2iL0uFc3tJhRVNPm8nqcLe3oIMGpxWtHGBYDi50X2AyhTpvc7Z0mnIc40221mWi1aAsZ4j7 rkMidqvQ2WVze1zQDqaK6B7Nw7Km0whyHOjFY2sVjnE50Ku1bbWzpa0hslMMukEeqs1lgr5t6Ap5 h6e9w2Oy2lYJ44LHbmtpv0MjrMZtNC8bEIFOzIA2MSulGETdClz/N63IofuhNdYqr52qbtXLqp+o fgr8X9Uh1UsRsgS3I3z9Icm23daX7TZpJE+dpZ6kflj9oPoryKeBuwEzRcxB+VXBLh2Q/gnbPbEy zAS/CzPKSTLkvScLjgLv3f9UTOyyEpgUDDLavc3lHxVhK7CDsfs0mipcm+QwD/0F8cfuDQ7UzK2e X1jI2Gbl3Y741lLpuPQ2pM3BpnIbk/g3+D8wFXZP3aD/kf8j6N18N+jv8j2gn+FXQP+W3wD9mQoj UCWqsM9SDVPNAv2g6mHQVap1oNer1jOu8quugf5UdQv052o39jYetYep1B3qTtBetRe0T/1N0E+r vwV6h3oH6G+rvw16pyafSZoJmiKm0hRrikGXaKaDLtdWMkn7gBZ9aau0c0FXax8HvUi7CPRi7RLQ dVoP6A5tB+hV2tWg12ifYFy7WftV0Fu0XwO9Nep5JkX9c9Q/M1XUC1E/At2nm8m47j4ddmS67+r6 seP6je4a6E+jITl6cfRqpopeY8BO1qA3xDCVIdaQA3q8Ae/XDCWG74HeazgA+mXDz0AfMRwF/Zrh TdDHDScYN5w0XAL934bLqP/EcBX07wyfgr5uuA7694bfg75h+Az0TQM8a2TGI9jd/dx4DPS/GX8L +qrxd4wbr8XEMSkmPiaNqWLSYxbDk2rFn5yNIgvLtpWtqtgTes2HRjU62Eq3SAeNdLU67E91Dbrl yBt17chX6TqRe3VduLteF0C+QbcBNRt1G0Fv0m0G/VXd10Bv1X0d9HbYSljpqmITDmvkgc434B2u odBQSPp+DPp/DP9DuhxF/prxNWh0DHoJLZKRp8SkQJfUmFTQaUIvRR892ym9wjQNroZlzLS809XC ZjS5bM2s2m5b5mL1LQ0eJ2a2nkkL5lea8L6cIc45rGFQKLwHItswminifVBMxLWE9xKx4WsJswqS qmpmm1iKwsHxriJOoVW4G88Smm0uJ7NT7qTcQ7lXvAQxP+VbKN9O+U7K91F+kvLzrc2tzew65QMi l7SUx1KeQnmWov/dci6+KSSilKCVeCenQRmF8eqhvRF6iV+CTWCJbBjskgyNUlkaS2cZbDgbwTLx PmskXpXv3u5udeKdhvq2Mg7yv6wcj91uHdavFqxoXWwT28Z2sN3sefYS62WvsKPsOHubnWMX2GV2 jd2S1JJRypBypFKpUqqSaqQ6ySXtlPZIL0j7pT7psHRMOimdgWQdk6St6F1iUkI1xohy+FQmfrVM ytwilyNb5Llgkv0ulWyWy8mL5LK0Ty6n7JDLB9bJ5axGuXxwjlxW72VqcRb0SBHTwuzSUjXTIoAk c4vcf8M4MRqUN+XrZeOUskIp++TSuof41I19jW80vt94Vb5qsjR5mrY07Zav7Hp7lr3IPku+cugc IxyFjkq5/QqtUl6Vy+bjxKVreaHlUMuplo9abrUmtua0zqDaOGe2c6qzymlxepxbnLudB5xHnWed l9tYW1JbTlu5POJ2ylEWyBLbS+VyZbxcumbJpfuQzNdRoJSlFHFSh5NJsYfIShb2BrzHyXM1UqPU JR3jjJfxNXwD30XpOb6XH0I6xftValUi8nLV06pdqmOqc+oU3q8uVM9SV6lPaio0czQezTrNWc37 2mztfKzWz2mPa88jXYoqiGqP2qcboSvSletW6LbpjunO6a5Gm6K90b36XP1R/ccGnSHRkGYYbagz bDb0Gt4wXDMWGWuM9cZNxueMrxtvxqhjSmMWxayL6Y25GmuMnRFbGVsd2xL7ZOxuxLY44RPne9PE 2RZQHuyVfht8SvoM+EPwKS4B0cF3uT7Yy+OCvfTdT72YGSpql8mmDdygsz9x8ifO/cSpnzjz68M9 FZ37iVM/ceYXRSde4sRvmjg1Q4048RPnfX1B4W1xV5z4ifM+cdqnodO+aeL0TJx8AeKsL5FO4cRJ nzjnE6d84owvS5xEglOc8YkTPnG+J073xNmeONkT53riVE+c6YkTPXGeFytLwvhJEspMSMsSZ5eg KzGK2UAVxjAf1wtQLgLqUKe0RCtxCijOAMUJYJY4E8VdcQIozv/E6Z84+xMnf+LcT5z6xclaUp+Z Sp+VaFmptCymsz5x0ifO+cQpnzjjEyd84nyP0/leH1sJ24gzPnHCJ8735lBtlVh7gj46x5PYj6CH sKkdej/FHhccoDV8QrCYlwJVwKMD63kN5EahnR7t9NINViV9NvBzeD6WSwM/5xmwlwaxsAc1JxAL exAH3YiDbqYStbhqxFUj1knEg5QffEmaEHyJa4Do4EiuH/gFjwNSgm4Ou/LsoJslg2sOuFKlgmCx NDG4UJoUHC4Vg/5s4AB6Yej3ACTM4TFAPEaZiAgcBqQBGcDwYD3PBEy4dw+ux0MDSYwLa7WKomnk nzUSjeAGx7vgcKP9fdDkPhaLtm60dWN8vRhfL8bXi/H1gtMNzhcwpl6eCqQDI4FxQB68qoW8N0XP d/ZK3hoJ+46EzWZBRwssif2iJKLVFBHPs5R43o2I2A1J72Ic72IcbozDLRUCk4BigPwUrIOsGsga Q1rEAPEYYwKQAi+lYVzwH2zVC50Pwl5u6H2Qj8V1DjAe17kY9wglJm9iBGKUHCOYhRHM+qs9lRKc 9Ee9xWGzw7DZYaaH7LWQvRay10L2WshZC8u+C/614FoL/rXgXIs2ochLEeNVxjbnbxtFsPF7LAEy +yCzDzL74KMVkNsHGX2QcQC69UHGAYyxD3K+Cjmvwbp9kCMioQ9y+jDePmaAlH5IOQ0ppyGhHxL6 ES+nwXmajwbG4Xo8yrxgP4uG7H6eBL3TUGYE/wty+yH3P/gY1OUAuYgS/RdiMhSLIg7FCEaTX3uJ 83RE76fBGdnzaaXn0yI2By5iJbrIXgyuZ/uCJ1gPIGEWdWP31Bes4jMx82fD9g8DVbieC1QH12P1 +AV/HPdqgxf5kuAubgZtR9mMsgW8rYAz2MPieRk4ZgR7eAXuPEDSrkLaVUi7CGkHIe1D/gjqH0WL GvAtDr7C63Ftw/1WjCYWEtZHSOhRWtZGtPoWWnVTq1bcawNWouUIzKx0xHR6pHaQNgrSoBkrhrRG Pgvcs1H/MMrFuK4FXYde6kGbg1a+DLQNdCPKJsCOtiswolbQHShXAWvQeydWQg1JncvS+eMozSgb mIj4maAeCF5kBsWeorcT0OM96PGfGP9l6nUJpJhhQ2HHVqwDOoxzI7S+iLYvgFNoK+zTE7IPbBOS NTf4K1jyBXBcRN/p5BczOBtQ2iFX9ksP5Dby1WipAbfwnOC6Co4TZGu51kxtqAZ27MGoyyBhBiB7 ANGAHuYGv8GrUT6CFe1R1C8OtmJcFzFD44IMVmfYZ1dhp13F9sEWZQM3IaEREg4q1mjks1EKSVUk 7QT6fg/S2iBpPST1hMexGu07MY7Y8DgeII0vgvtN6rtG6AIpwuLNQIscOxj9RbROx0jiguJ/icWI hG5EwpuKpPWkjRwBF9H/abKuHAHdZL9loK1k7W5EgIjxRu5A/QqgmezZjXjr5m6Khu6IaOhh4zC7 ejC7erCm9mBN7UHvsAZikeJwoBMjmISIEP5Np1lWjVenxykO0+Gb9RhFOl+KeKsf+BCj0XML6AZg GbAc/FaUNvA0omwC7KAdFJ9VGJ0eIyvm7aBdgBtYA3RiPkQrc6oq7IcqsqgV1lyP3oXUbhalROsu RFgPxlZFY7NT7GO/QTazw+MSb2Xivz991PYJ7JAEVRbcix5WwOPrIacHPe2HpfdHRH8j/NeKHocr On+L6dGihqJMjpH1NLZq1D+CUSwOfjMc+SIme5SIWkleDGnxSHAWzRPBaUGdjaLdxhJhmYuIjDcx +l2IjP2QKnhElFlI6gnY8TLN6zYAkc89qOvEvIhT1rmLSotraPEarVCNiFk7ZlAz6lpozhzCuncx ovVFvPNQ1iG07qb+bBhBoxLdQj7HOpEu4hx7a6FHLRO8F6m2GdEvYtkJOrSyRSkzV+YQUprxKoE7 6PMivFuPKwsg7jZihbFjdK3BX2JkV8H1K3C9h93/i7BFLVbfJaTTCWWtCK3hYgb9J1qIWXSA1gwO 7qs0n4zo4TWabRZlpW7Eq5UYqdxOWFC0e1NwQ8P/wFoW0kfm/lDhJH1kzUnr0CxuIK0vRmj9K+o5 hokdZ4JYpxUbWYg7nfyHaOQrlDWgleZ+MXkgLjz/M3GVBYg1adCn65UoEJ55IewZp+IdrRJ18oro hC1XBn9Bco2KjJ4I+4l14TUlFnrEayC4u2HxHrKhJMYKS7ZQvRWerA/uRM+9kP8ueu4n+W2wOEUO 7u6KiM6LZLUQh1ibVWHN9kGu2MtPxtVk6HkCep5QVpweel3nbAKd5DDxGQ68ymcz8T/Y8UgqNhFJ DS8UY08wGUnLpiBFia9WQvyWI+nFJwywy16AZGSLWS18USc+P8B+hPcf8ezn7ChLlPKkCSxJ+q30 W5YqfSr9nqVJn0mfseHSH6Q/sBF4fyyxTK7hGjaSR/EYZuJxPI7dw1N4Ksvhw/kIlstH8pEsn2fz bDaBF/ACVsBL+GQ2Ee+sZ7JJvJLPYtP4bMz2cj6Hz2Nf4Y/xGlbJF/JFbBavhXUf4lZuZY9yvGKz +dzO7ewxvoK3sxq+iq9hS/hmvpnV8y18CzMzKbo8eoP4/zF7n5UwtmIV0MWk5jSUG4AtoLMYW2kB /STdYyt2AN3As8ALwEtAD3AQOAz+bJRHgTcUnFLKMwrOAecVCPoS2uSi7FeuzzGpsU4umwtRXlNw k7FmuK5Zi/pSlEYgUW5DtAxp5d4QzVObLtmv2C/Yb9kTbbmEXEcsodRWLcNhItTaCgmljnECthZb roC9WkGpw2t/3+Fv6rdfb7pmv9V0037dziC31+EhaB3cbnToiK/U4bcXNp0haMFnjOy/6RShEPRz QJqCEH8WaMBW03RGYHCcNqYgNG4ap70cNEHQwGzHVEK1glKhE1CuINFRSWgEr0DougV0S/h6Tli+ oCOurdf+OOyzMZZGYJ31nH0TsAa0C9gKWmC39TzhOegmsM4xjxC67oWM3gj7K3qH7XHMYZdh7Scc t2URQvZ7S9gY2Eu+rrOfhW8EFP+h3Ixyc9gPckwk2fei7V55PCHfhn0c8m3IlyGZId+HZGdDFmCz YKyWu/jyzhj8U77/8vYZhDt9fx9ogqCFv8Kxk6UgFDv5hC/ldxQRahA/NUo8EayXCDUKQjE22zGD EOK/ExbEnSUiBkv/BEJ89ylzMhSjLuguEI5h0I0R1yJeBBIRX4m20sEYvv06HKs10LUa2I42O4FQ bArstaURwvEK+rmI6/3wh0CY37GQcOf9UHyHUC7H9xfWmVpcC7wKWuAQ6EM0xlxCL2IZsLU4dgmE dRtcn+TrEH+pAOK12lZOoPuCF22rI9oP8svrS2jcf/LasUzAVuNYKIA5uIlQKNY2mldZhGwFxx17 CEqsO562ZQlExLCJINZFgdA8FgjNtzvnXQjlCu6sr1UwOPdDa7M8xsH5K68JofJ96Pm+LZH0FeUX 4su2laDY0LEttMZBf4FjDifm5zz7W4N2bjpv/9i+BnNBIBTfhfBpoTKnI18blHnffq7plMDg/fbz hPC6Abow8jps+xD/JcKd68yd60Zo3t8H+wMrs1fmCthnrywkhOblHa8VYb0xJ9v7gWugsd6337Tl rmRfvB6cKxijwJ1zR7HVSsTpytLBmF5ZjuvywevwHNiE1wGBdXgdEDi28j4ZNi3hOHwnoNhl5Wxb FkHbdEYgFJsrjbg2DsZ4eL0N7QnufO1U9MeuyUD/C2f0X3Ad/f87WlOiKWGxmqma6SyO/ks9TFut fYxlaBdqH2cm+v/0aPo/8Vj6L2+B+Iwh/w2/AikjVaPFF1GpCplWVawqZfGqgOoaS9LkaPLZFk25 5jT7huaXml9KYzW/0k6XxmlnaO+Xvq6t0zZJ39Q6tA7pu9pmbYu0R+vSuqVnDdGGaOk5w8uGXun/ GPoMP5a+Z5SMTulFJklXeOngjs+yCdhK/9Filu3ATtD5jDU5Qe+me8zyHIBdlWU/0AscAl4FjgHH wV+E8i3grIL3lfKCgo+BKwoEfR1tpqK8pVx/zKS6FXLZMIOxBq5AB8QC2Ks3VKLMAExyG6JlSE19 YTqZ5YtPIbNqtogtYy1sFfOzrWwH28P2sh72CjvGTrF32GU2IOmYyrLF0mV50rLBsmPpQcYtMyyV S0rqb4IqsZQtyTVjs27JtRTWO+s/AmWyjKu31veDSrGMsIyufQOU0ZJoSav/ABS36Cyx9YcZN98w D1jU9cdQx8zXzDfr96Huuvlj85X6HlCXzR+YP6rfCeq8+Yz5XP0eUGfNx81v1WMXbj5pPmJ+vX4r qB7zG+bD9X5Qe82vmnvrVzE1JF82v7PkECRcNX+0VI+ay+Z9oA/gTt/SRbVl4Paa/ebN9fCvud28 ytxVP+NvFqUa+kwHo09zSNp12idYNH2uIYE+lTAMcZUmbaBfwj0MH7B6AcRFPfyMUTBbCspKpW4O MA9YCGCnX78MsAOIuXoP4AX8CjYr5TYFTwO7FAh6D/C8QoewT8EBALFR/wpwBHhduX/kC8hfsopS l3XFklXW9iUblmxZ0qVgFfDkkh1I3SifRP4s0E1Xghb5DiWJ+6hZXG29hNS/uEZ8Ugf2v8oYv8Y/ xfve38MXavKFlnwRRb4wwhfTWIxmetgj8fDIoyxV+xj8Mpz8MkJbq61lWfDLS2ykYT+8kw3v3GL3 GAbgo9z/jz1JrIJ5yNcFeG/M6vBOru4SgHdwdXintghrSR3erS3Fu7XlLqarnVM77/GnkS+sXfj4 5eW7xP/y+e/47zDS6xxrgaZMg9jVztfOZyrE3mKm1i5BBGoM3zd8n2kNnxs+Z1F/VRspsX+Y+Ay5 UTqMtYC54Xs34mb5+wRui8c14seN+HEjXtyIFzfixY14sSJG3YgNN2LGWinDfVKpF3xvhyH5shh/ fJ0MxDm3jUD9OyhHD9Z/GWw5QMGfwVcCQGNbBV3TuAgfKGMTY8E6tRzr8sI3bmsr812GT9RoP0up u/qXoy6eZIcRkuu+wXjgFuMbeFhnYdfB/gcwxqkEurbmfynoPvpByd9zze90+Re6FnWu8de56jvX +Ze5rJ2b/HbXis6tfqervXO734P6naiv79zt9y5o7HzO73et6tzr3+zq6tzv3+ba0Nnrf9q1pfOQ f5fryc5X/XvAuQn87Z3HqO0m//OQfxycOzrf8u8DfRZ9dXe+D55nOy/4D7he6PzY3wfOK34v8veR v9R53f+Kq6fzlv+I66CX+19fsNur8590HfbG+t92HfUm+d9xvYF+/a5T3gz/B64zXpP/I9c57zj/ Zdd5b77/quuSt8h/Q6np905FL9e8M1BzCvlJ5JVodco7B/lN7zz/gJt5FwbUbq23LqCH/DmQf8q7 zP+R2+i1+/e4E73OQLw7zesJpLizvN7ACHe21+9fKOfCbq1n3bnCYu5C72bwl3q3+Ze5y71PI3d5 X/cfuS1f4z0Zzl0iF9oFctzrvG/737kt30T5Vu87/svIP6D8nUCBezvV7PR+5L/h3o385G35c97L lF9Fvs57g6QN5pso3+sdCJS47/PuCox21dNo9/vUgTJoDQkdo33XAkfds717oGM1aSprdMw3IjDL 1e8bHahy9/r0sEYpdPSCU/Dkep+HBWS6xrsPtFxT6z3g9yu5RaH7kDd6X4HMyLzFe+SO/LgvBx6U Y4y86X7LV+Df5z7rK4G/3veV+T0Lqn0VgRFy3Cp6NaKt132IRviqL96Mel9KoMJ9wTcrMN+9zlfl /8D9sW8+4gcxGVgkvN+ywd3oW4Qer4hIc18n+pav3v+6HHUeLvTy6IQHxaxpPSbis7XRE4uR212H fVZEZnjuBOpFlC7YKlvAkyT86MkQWnhMvhVCI1+70Mi3alC7RdnQ7oKIH8844VlPPtFF5OVGsj/5 1zPV1+Xf5tH5NvgHPDOIriR6jrCMZ56wjJhlASvF8wpYaYu/zrPQ92RA76kTVvUsoxhoofikqPDY YclX3FeEJT1OYVWPh2ivb0eg3eP3dQdWeTb7ng10ebaRHZ4WdvDsElaC/esxqj2C9jxP9D7y/hrf C+gll2gXRXINzZE1RF/3zRK9ky9Kid4kaLHatJ71HPC9hPpGX4/f6+nzHfR/ZFnkO2xe6HnFl2Le JkcR4gGzwHOEIkqeERRXqMdMESuV8xURM4uXeV73HfVv9pz0vYGVAatWYINYH5wZnrd9p8y0ggW2 yJxiBQs8KdYKZ4aymoEO7PC8490W6PZ8QPOLfOH5SNBiZYM0rCGBZz2Xyf5Xhf09N3xnAi94Bnzn Ai/RHFkmz7sOdQStH7S/WA9bz4qVJ9DTEe877+/rSPFdwkoyGMkHO0b4+gOHV+vE3dWx4u7qJKIz iDYRPS6y1boNgRRXve8mVtpTXQyj7e46BPpo16voETG8cbOI4Y3blJlOq5McvavzvUkbn15d5H1+ 4y5lLZJn9CbyKdl59dSQnVv3kvU2r57RuWnjHrHGbnxemdEUsUI71JN26OtIWGus9hv3KetqxJiV VUVeYWhsmEFi5awd9PualEH5a0YImWtGC5mWqi5t4I2OM13XN7jce7uMgZKOnK7EwKmOgqUpgTMd JV1pqCnoygqcUe6WdWUHyjoqunID5zpmdRUGzlsWdZX67R1VXeWBS+C8j1rNBuf8rupAv2W+8GzH ov8l72ujosquRM+9tz75ahpLmiY2TQhdTQhjA4vGsiSGMXDrAyFQFIa2bSTGEMOzaZqGomCKqrIo HGMMzzC2Mca4DGGMYYzhOcZnHGOMcRyG53KMbRvHMC5CG+IzLpdjiOOyWfj23vfe4laprd3Jy5/h rL3Pvvucs88+5+yzzwdVdX3uDdNvnfCt3HCvo8HXGGIda31NIV1Hs299KKFt3NcWvNHR6vOGUkAf /+oVHR5fePWWDp9vcyitI+TbGsro2OTbHsqGuppCuR39vl0bSmXNt/kGQ/kdO337QsUde3wHQiVQ 9hD4LvBjoWXenK7z4T3SatWx13c6ZO/Y7zsTquo4+DfjIXejC7Td23HEd37DfqRDKzuO+y4F14Dk KyD5lO9qqLFjzHc91CStsNJa1nHOdyu0XsZFgewNRZ60QG6oDbUK7/UuDOSH93uLAsXhg15roCR8 xFsaWBY+7hUD9vAp7/JAVXjM6wq4w+e89cC/6G0IrAyPS2u0d22gMTzpbQ40wcoi7SJovfa2/o0Y vubNormf698b3OL1+PfD6gy7hd5hyX5gpmwB2xjsnuod8vq67oRO1FV1d/cavCGcxd5NgfXhm97+ QBtotS3gDU+jTLQHlOnd2XV9wznvnoA/fA9sOOJRpbXJu5dsSVqnpBWZfJR3P9o55B+O2LzKn6ht 3ntwzgOoPbP3CHpj73HyxuSlvaeQlj1tG3naPNWsV3lp71gg3Me85wKb+3Rqv+e9GNjal+AdD2zv S+nwBHZtKMKx60vDsevLgB0Izo6h7tG+bJy5vXfldaeYZkcYtLqsnk0d474ZGNnJHj7kBWwAjNZV JPMJv7WvJ2lDace1HhPwaR513OxJ3zDdMd2TGfLL+F6PORT2sJ680GaPrqcQZgHkpz0VjK8noccS 2upJ6Vka2u5J6ykLtbVf6HGCTA/u0xBvKPVk9FSH0jzZPSuCQU9uzyqYF76eNVHY7cnvWRfa5Snu aQkNEt6HeznA5JMl7CnpaQ8d6Ojv6Qa7XdYTDB3y2Hs2ho56qnq2hE543D2FodOelT0DgN09O0Jn PI09u0PnI3godMnT1DMcuuJZ3zMSugr4cOgqzq/QdU9bz7HQLRl7e06G7si0v2c0lCaNGrTrLNSb 0nMhNOMJ91zu5T2beyZWb/Fs7ZlavcKzvecG0Lt6bsPuMQOtl3CSijZ4Bnvurm4HPIvYr8FR8Mf1 mqRdtGefP7k3Xe7nA/7U3szGbf4FvWbPIX9Wbx7UvhR68qg/p7ewY8y/EGhZDuET/qJei+e039q7 FOjS3jLPGb/Y6/Sc9y/vrfZc8rt6V3iu+Ot7V3mu+ht613iu+9f2rvPc8jf3tnju+Ft723GN2OCh NWKks8wPuwhYN/nghU5nl7f3MO7Mewfw7NB7jOiTndW4F+pcQbt0X1e4ZXfnqu6k3lHcF/XS7r33 QucaoC8jvWFb5zqgJ6BsUu8UWe+NzhZYd26rLbm9xd8fbO9s928LBjs0/p1g1YPyngHmSGc3zhE8 m4DfgFNA76zMD/r3SHxYVYEf1iAdjqOTwoR6b9C5Ef1P5xbyP7A3AJ0Hugs3HCR6GOlwMu4Qwqny GrfDfzCc2rnbf+SVjcRfgPxwFtE5RC/sHPIfD+7oHPafCo50jhB9GGk8JYWLOo91W8LWzpN0UqA9 PO40WqrRnsOlSIdFpHsvEL1csvO3rvjHgu1v7fKfC05AnyA9iHRnGfqZzlH0M7gbadmNu5Gwi+hh ous7z/ov4s7EPw47Q9jxhhvQwsNrOy/4J4PDnZf912DH4iR6AmnMH27A/JCnDM9rnVP+m3AyAn8V bkbLb8Ez46XeY0iHW9V+jNb6YWmtn9vV1G1GOkxnq7Cn84Z/OjgC+t+DMYIz4OtX8LTVO9t5e24P g6fCsA/PXy3VbxUHGIzp3YAO5pFEzwYSwiHwbLhnOIR7Bq9mbgeLHjK8CedXuJ/obUjXNZIl7PTG BVI2xHWmB9Kg/3fRHoNWAW9yIGPD8b7Tfef7znTlehL6tiMO3n5rX2AQfJcvsC/k7ugPHNhQ6p0M HOrL9cz4Pb3dnbzf1xv0Xgsc7cv33gyc6CtucwVO95V4pwNn+pbVlQTO9w7JO/z6wKU+O/Z8XxXq 80q7917gSp9bOuHKZ1vpVBt9Yi1TTqldLHA1+qwqr+C0f+jSBa73rexKCNzacLMrJXCnr1Hyq2+d CczAKYPkeFKCfGimKy1o6GuiOTslzUSst2+9fJqGvTFwyJJRk7422d9GNOnzqj0knZQn8Izc55d8 GnqMvrB0vpb8Es7lsAfXjr7NEpY4Ui1dGd2GXlNXdjCpb6tkIbhqACc/aOrbJd9O0I1BV3FXW9+g dDvRVRJMBxuT7iLo1N+1LJjZt6/LHjRDjdKdA/WbdKsg7TO7moJlfUfVJ0qZlu4roFTfga6qYN7r TV3uYOH6m10rg5be9K7G4NK+Q/iLA/TtL6b69hdP3/7SGJYZ6pmWvvG1gL7x9XH6xle2wWPwsZcM AcPXWDF9m+uz9G2u6vhPxuczd/z/jf89W0XfQFtN3zf7ItRRyLLZpxljZew1ls7WsA2siH0Vgptt Zd9gdWwP+y77PNsL4RW2n42wlewn7ChbzU6zd9kX2AT7LXuT/Y7dYJ3sDrvPejiey2V/y23mtrAR bjv3LvtH7j+4q+wPmmbN6+x9zZDm++y+5pjm55ygOaN5hzNqrml+zz2tuaMVuPnabO0L3Cd0m3XH uBd0J3Q/5+p1v9D9glupG9X9kntV9yu9jvuS3qh/hntb/5w+gxvSf1wf4PYaA8aNvNb4VeMAn2j8 pnEn/4zxO8b9/MeMPzKO8Z8yvmO8zNuM/2G8w3/O+H6cif8K/ieF741Pin+KD8enxD/Db4y/Ev87 fkvCGwnf4bcnTCdy/D8npiem8+8kLkjM4i8kfjLxk/yvE/MS8/hxxkG/NNNNaQZ+Z6ZyrQzNjNn6 WXplQ+XayubK1kpPpa8yVLmpsr9yW+XOyj2Veyv3Vx6sPFJ5vPJU5VjlucqLleOVk5XXIM9+/A4W jS0zfNbwWcYbnAYnfVcthc/j8xjjLbyFcbyVtzKe/wz/GSbwy/jPMg19ZkjHV/KVTM/X8XXMwH+e X8mM/Gp+NUvk1/BfZEn0aaFk/nX+dfY038F3gMxOvpvNo88MPQP9nc3SdL/U/ZI9C226xK5Qy+jX SuxjbI39noM5dI4ER4ojzZHhyHbkOvIdxY4SxzKHHbhVDrdjpaPR0eRY72hzeB1+R9ix2T7m2OrY 7thlP+cYdOxzHLBfdBxyHHWccJx2nLGPO847LjmuOK46rtsnHbccdxwz9mtO3j6mCufkcFEO45Ew KQWnwX7TmWSfdpoALM50Z6bT7MxzFjqXOsucTmeLs9q5wj7uXAU51zjX4Xec9H8PvZkaZef4PfYi 1gpWa2VdYPPLyM4rwL5HWCVY+E9YFdj3u+xz7DqEauqjGv0n9C8wl/5F/YusTv8p/afYCv1f6Rey z+vz9fnsFX2xvpit1Fv1VvaqvkRfwlbpbXo7e03/qn4VW61v0Dcw/M2WXTCTsJezmJYxMQnAJEM6 QCYrEZPFVHGBmCXmiAvFItEqloqiuFx0ifViA/DXis1iq+iBVJ8YEjdBvn6gt4k7xT3iXnG/eFA8 Ih4XT4lj4jnxojguTorXxJvitHjPxmw6W4ItxZZmy7Bl23Jtdtsy4OWKO235tmJbCX4fzPCmoYO+ 9RcX1VtdEIrYv0F4mb0HoRhm/W/ZInYNgkVfra9mi/V1+jpm1a/Vr2VLGAeziH7RhOUyPWPVToBq xtWaIV4BsIpxpW0A64XC6rLapGpnrYkA6era9OoVtZlEI6yqNVevqc2LpK2rLYykKfmwLNKYrqS1 1FoiNPLba5dWd9eWRcUoG2mEYK2TQKE31lZH0hRQdFHyIaB8hUaZW+B5i6wT1qs8I2D6k4Kij1qv JwWlj1AHhafWQ0lX9EfegKwrxgg7oK1qUJdXA+qG7cR4N4wB9s+A3N9KHVvkGMdI/Yz9uUIug7pi mSE5VnRT5Ch9O1y7ImpMB1SxostI7SqKD9euidQVG2M9WL8SK7orbUF5x2rXPVBuIKbek7Ut1aO1 7dVna7sjeg7FtOVhuirtUctW99cF1TPqhzop8Y6YZ8Um1baotEPhXa4NVk/Ubowad4ydj2j/w3RS PyvzS+FDGVeuxIuNo8pO1W6pKaq9XGOtnYga18fErvwnS4/KF9vfTxBTeeU5tp9j++KD4gsxz9Du R8Zlqlglx1Us9dPj4g/US92Oh9mbMtdu1A5U367dQbQSK35ZmYN3a3dH0mZrh9BWajS1w2p/XRNX O1KTXHuY+kzRC+quSa09VrOg9qTa/mqyakdrcmrP1iysvRDxD7I/qCmtnaL5q/YvWJ9Ye4PKLq+9 HbFz0K/GVXsXgfqtyn2upr52lmi3+6JrpXsc7dXV6J50Nbmvuda7b7ra3NP4TH4eyruWgU9U1qCH jWXs2HihLtlPu/xzdUTSw+57rs117IGxeJRt7oiZ24/zV7Hpch+5ttbpXNvrEhS9sW9du+pS1H0V 0aH6EX4I+7PBrUGIrGuKnSjpa91xNc3uZIJWd2qNx71AvZ7W+NxZUeutap2tCblzYte3mk3uhTQW Cihy+t1FFG9zW2t2uktr9rhFqucRULPXvRyBfJnC2+92ReawvJbWHHTX1xxxN6h9Ws1x91pq2yl3 8yPXZbS9MXcrthfbWHPO7YnIvOj2qfurZtwdqpl0b6q55u6vueneVjPt3llzz73Hxdx7XTr3fleC +6ArxX3EleY+HrV2KHNPHStrSawfflQca1/VMbHCR7+/4yH29Ki1KHZNgrKuEtleH5ZPtZ5SPtVc JnvFeQfjrcS0N8H4ce38IF+L8W55r6HEyrxxxsyj2PVP2Y/As8seHUf2NsEH2/HAevuk+srpkbUy dl191P4jdjzluRWpD30a9Pcbp94Ye2Bvi/UN1qW5MtynXNnuMde+ugzXgbrsqD0jykXANqOsQ3W5 kTmM/aXeHyvzT9mHyPq4jtbl4zrhOlFXHJn3yD9dV4LzT13edaZuWUS/WNkg13W+zk5lL6nml8o/ Kb4osndGna/UVUX64mqdW/Hvrut1KyP9JuvsulXXGLUfkvuxlq9rixpjtA9lTcRyd+qaXDN16/EU b/i64X8yFl9AvyB0I/4Gw1/VNP9l71e0ArtP9yir6R7lC7oTul9w2+gGZQfdoAzSDcp5ukH5Dd2g vGcMxJn4ZXQvconuRf6d7kV+Tfciv6F7kd/jvYiQjvciQg7eiwifxHsRIR/vRYQCONEOseG52wNr CbNb3daV1kZrk3W9tc3qtUxZ/dawdbN1q3W7dZe1xDoIsM96wHrIarcetZ6wTEGO09Yz1vPWS9Yr 1qvW69Zb1jvWmSX8EsOSpCWmJenWZUsyl5iX5C0pXGKxVi1ZuqRsiXNJ9eJT1mUUqiCUULBTwKdl BEgD4E2A4RX8/GTM2bYbRqSHBeBUewDCYjrnWtkv2Xk4yV6A8GnuX7kxtlRzTvMOK8X7KijJsXrW MNfe/GmWpbQU2tkEcRNQ2F7kYJux1YPQ4kG51dBmaO8gtPg0BD/k8loHSce1oOMz9F02BtZjBl4O BB7O0rlMYHkQNGwhe4lpWQErhPP1y8zCjKBTGUtkIoQkZofwFHNCSGbLITzNqtjnQNMa5mImsLl6 lkq/dJjOPBA+xvwQFrAghOfYGQgZ0PZ32PNcEpfEPk6/tuWfa2tBqlBYfrJ8tPxs+YXyy/mW8ony qfyB/IHyG+W3y+9Cymy+RdSIcQWlYnL5LN5llJ+cu80oKC2wFtSLpeWji4dEsXwUbzbKRwsa6HZD uttIzb8tevLv4v0GSDspbiq/jFJB1sK58NIJkENh8dDioYIicRtKUQLUqoR+KLezoMGWjbJAyl1x P0jOAvoywWXUnfSfnQuLh8pvFxRBC5pB71D5BXEPtMAH7dpbPiGW5g/gLUv5WdGKUFAKOi7EO5fy C0BfwJuX8ssF1vLb4vLy2ygJAPsLYRZ0i4N2ApB0vKFJFluxn6ivoDaE/FmxVJxEuUotJFEB0AFB vAbxFEgFyB9YPAR6LccY73uAFstv4K1PgfjSlfKTNp04aUvA+iUdbClUf3J+UKkbAe+GxAWih1pb SJQCwJFKQ86TttOk2wPwML7ttO2M7XyU/irANNTZdsl2xXbVdl3RUA0P4yPPdst2R619pBXAt93C UZYA9cC+UfS35TqKxKLyy7Z8sYig2FYCPXzBtsxmFxfaqmxu20pbY/mErcm23tZGlg12avPa/CAJ JNjCts2Lb4j1tq3YhyBnu20X9qRt0LbPdsCWC7XCGNoO2Y46tzq32044dzkHnfucB5yHnEedJ5yn nWec552XnFecV5WRxBpsac7rCM5bzjuiKJXANOdMBS/Zj9yjcs9JIw62FRlTya4itgS2VWGoSELr qDBVpIt78u9WZKIE2xl7NZXA/kkuv+ywikWOUofoWF5Q6nCJVke9owHCWlu2oxlCq63KUeTwlI86 fFDjGrCv5YuHHCHHJke/Y5tjJ/D3OPYWNDj2Ow46jjiOQzjlGHOcE9c6LjrGHZOOa7ZskHTTMb34 sOOemApuSedMcKY4E8RmZ5ozw5ntzHZcdMKYOI6UzzrzncXOEucyp93hcVaVrcQUp9u50tnobHKu z591tjm9Tn/+FPgetLZRGL0Z23k7bzfYk146gTPQbrKn2zPtZnuePd12yF6o9JfdYl9qL7M7sfX5 loJ66neaPfYVyiyyr7Kvsa+zt1C/wpiU37C327vtQftG+xaCAfsO+25bCngRVwRobGzX7UP2YfuI /XCspYLXqEeQxsd2BcF+zH4Sbcc+aj+LsUKjL7BfsF+2T9in7Dfst1F/+137LLVDGVfwjw6NIw5n pSPZdrX8ZP5dBBpNsDtHqmOBI8uRYw/SPbFPXOhY2JiJ3rbCXJFXUVhhcYadmyuWVpSB5mcLE8BP JVc4K6orVojg8QrqK1ZBr9aDrpI3DomlFWsq1lW0gIRWsb6i3ckquiuCFRuBH6zYUjFQsQO4uyuG KoYrRioOg32nVRyrOFkxWnG24kKBteJyxUTFVMWNl45W3Eb/hz4XbRe0uVsxS30Cei9Plrwl9FMc +NLW5ZrlcbQWfum/0Q5qHWulO3P8XXBWuJFxAKbCEIRNEPohbIOwE8IeCHsh7IdwEMIRCMchnCq8 VzgG4RyEixDGIUxCuAbhJoTpwmn8lUHDakMj/ZpiObNBvzpYBewrKmF3oGO10Hvx0M+v4TdAEq4l 3CaN6H9dL88wzrKesWIe4jah8OU7lqaXZ2QAupgHMEg0PScBmFRp6ao0Jd+MRGN6JC1TRWM5M0Be TJwk0wiFMii0RZWmgKxLJF+eLD9vTqZSJ+mk0ofymT8EFMZArC4fBOkqHVR6RvRIn9Nb3UeRvuLl tqpAXT5KVqGcv1AeA9Ncf6vrID0MMc9Jc2VIV/NcHMlnjomXxoypOlZ0KZNj54M6ROIZuV0z0XpE yal+SBti610BsApgjUrP2LY8TNeH9M+jYtKv8ANi2SajbJGP4a0DaHl0P8S2/7E6qeeXMmcyo+de bB6K2wFOAow+Ynz/jPGj+v2J45h+ftLxemjc/oSxuo/lfnpc/IH1mh+jvzzXirsBgjIdnLONiC1j 3o2qPFvkfhqwRPvrHQC7LRGfEbGNIYDhmLpHAA4DHLPM+QfFDs9aaP5G+ReML8hlL1ui5+OEDMBb dATiKZk+DnBKssVFYwDnAC4CjEvP5OexfLpqDXqSOTlhifhpdR1K+qJJgGsP9vUjbfNxthbjrx7q l1CXmwDTKj707aJ70X0Vq8MDsjDthgzKs2InyvNtgLsyzEIdGkvUerooTpVXvTahjsmWB9a3Rany WCigyFkgx1kAOQALLQ+sTWpYVCQB2ZDCs6r6V15LF5UCiNHtXrRc0neRS9XmGMC8i+ql9mIbFzWo ZK6N7q9FzQCtAB4AH0AIYBNAP8A2gJ0AewD2xqwdeY+IHzJWj7TPJ/Vxhofb04ddkz5Qj9g5rI7T 5fGOif8kX6v4ElX8wPx51Pr/uPgx7fnI+n7Qmvkk45oXXb/im+pTo+1eiS0M7G4/wEGgdQAJcr0z qnp4uc0gy5JimZvDSZbo/bEy/5S9sayPJc1C64QlwzI375GfLc0/dXlLrkq/WNkg15Kv4inzUe2f FF9kntPBUjyXbimZ8++WZap+k3W22GPsRO5Hy/qYMTbMzUUqVwXgtjTh557o1+7Zf5+zJreV3oyX wCWxUsbM2wF2MZa9WwLzIMRDEO8DOABwCOAowAmA04xljEJ8RobzMh/yZRybg2dDUj7Ke0nKi3zz FYCrMv86wC2AOx8BZiQ5CijyXuQl/V80yLIBXkyKzhtTrtScYk4zZ5izzbnmfHOxucS8DILdXAXP bghV5pXAa6TQZF5vbjN7zX6gq8xh82bzVvP2FyZfmDTvQoyxRJkHCe/7WMuzOc/mmA+AvJVm+8fa zYcgHDWfUIUD+FnPBz/pS2940NC7HebTOxxS6R0Oz9LbGxbQexueo8/4ZtJnfP+K3tVQQG9pKKL3 M7xM72copjczWOjNDIvpnQyf+YvXx3EpnPSp2aPsU4y9UM/YM6cleKEBYC1A8xzvUfBCK4DnCfL5 AMD+XtgkPWcbYtL7Hy9Dhk9lT2XfiAm3n22O0HfV/OxZhVbleGjAN8LRJ7kZvcFDeneHlj7JHUef 5E6kd3ek0fs6FtCbOp6jd3Rk0rs4sugtHGZ680YOvW3jk/Sejdz/b3I5doAdmvsf0PPbWGVW0fxZ KWS5AKyRp9IsUaYoh5SStVxJV0oArs+qj3CKMESnK/IUWShJkSNLAE6qVSmn1Iw3h/x26Asdv4f/ Kbj1n/P/zDL4f+Gn2Cd0nbpO9ln0nqws/ifxJ1g5vTkkDSBFfifHxyPlNVAe/CC/lz/KtPwxkJVO ZfD9jKmE5f4wTTPOdJPKfQcxvlWGWdhSVY7zLGX+2fmFpkvzCzNTTJdMV0xX5vPzedN501XTddMt 0x0KMyQDf1Ejjv8+/32o+4f8D4HzI/5HjOcP8geZwP+Y/zFo9k+gjRbaNMoM1Jo40OynLD7+Z6Bf Msy4Tdwo3d252NNQu5uxzGyA3A+A/EemcaYSVjl/gRRMSaYkhZ6/af4mek6en2zKM+Xhs5zrBuLn bz1/y9Ruan/+zvN3MB8+R8qqA5SnUoWmwvkhU7U6YNnY/JhPHWLTM/lMXq1jpiHToNCSdpJ+pnZs TyboJdX/KH3m2iXXj3rNPD9jcpqc80OQw4n5pGBaCjzPfA/ES2kc8b1LjN5exBlXGl9jvHG1sZHp jGuNa5nB2GT8MjMav2L8Cos3vmF8gyUY24xvsUSjx9jJnnpiG+a4/dxdGm8P7FtYytonhwzwqhng VTNyHgKtEsxbD3GzHLcyLgPfTVXPKlMa5xkwPH3vuZvzWiQ6IyUj5bnJ56ZTZlJKUtKA0z6vPeXS PEOKO+USgPu58efGsVyKDnLdhADPkgypfEq2HDeChPUUZ8xrAVmNc4A1ZGRAXRkkF4KULxrmGVAy 1QXpGdmSjikzqOO8dtJR1m/eqjn9qNzN5+6BljOKTg/TB2UQ3x1JL0nJeO5aSnFKcUYa5CjGfBCf B8hNKZ6XPm8NxH4cJf7rPPho/pv8N5mR/xb/LRZnfMX4ClhAg7EBLOCLxi+CBTQbW1iS8U3jm2we vX3KFP+H+D+wZ+L/GP9Hlkbvl3r2Q/m4eoBqgBbycln0HZOV9FmGEtnz0ftfWTd94oBjoipfIWvC d6VE8nHgjb4NFs2DP6L6qbYMqg3fiWogS2dk6RqydB1Zup4s3UiWHkeWHg+W7mGJJAnbwKgNWmrD C1Q3vm8INZfq/gTp6CWtOdYa4fFslay5Op+kNcfsMu+jaPa4tj5cb45tl/tbeuNvNvFCst4nVLyz cn+r8x2V9W6VefirX3+KzaC1pD2yBTqSxEgSR5J4kiSQJAPJwLf8ah/UgWqJJ/lJHzCG29kR1RhK vKNsSGV7Eq9F7g01b0DuDYX35+qLJ2nNn9JbD+sLjh1mZ2hXkI6/W52UwVjCMYLKhEuJpqTUxGMI CWeSUjGGpwUJB5JSIe2YlJ6UlZSVOJK0AFJHIM7CPJArh/DCpIXIxZBwCUO0REWenAKSouSYkhYk mjA31gY1Uc0oCdti/ILxC9DmViNYpLHDiLPhidcmdpBGUP7PZvwoQWViWaIzsTpxBeBViWsS10Fo AWgHXllid2IQuN2QujFxS+IAwI7E3cAvSxyisIryV1NedYiWqMjrhucyoLeQnHVEr4Jc7fA8BHKH gTMM/YD4cOIxnPHGNcb2j9rCuCmCSnwTYHxb/Ez8nQQ+wQD0TEISgIk46XBqL0lIh3gGeEqcCSlm Cjw+E28iIROBpN2B0nMSI/KgdIkiKSKnMP5EgiVhKsEMdGZCHgFiCNTCLxnXfYj1g4f9/0XyUtI8 NOMvr3OFnIWdhOcdUdwcbiF5s1AUN4PLJp+4Popr4tJZEJ5XRHHjuGT6nmVpFJdxOuaG51wVl2d3 aJ9tivDmRu/xMzyFH+S/Bzn+nt8LXv4H/A9gZ72f3w8lR/gR6Jsj/BGmh775OTPwp6CHjPy/8efA /5zn32GJ/Lv8u+wp/hJ/iSXzl/nL7Gl+gp8Ame/x74HPORp/FHzOT2FXPh925T8D28C9/TcIf53w tx6gv6GiB1T0NhX9tkxD2zk3txL2fnly218k3nLOhb/eGMUr45zA00TxSrhl8HQrilfEWeFpPIqX xxXC02gUL5vDM+GhKN4CDvcFe6J4OLocrN9qXgKXQiu4mqfh8PMea9U8fBedas2QeNPsnmrNkHg3 2G3VmiHxrrLrKpt4kewcx5+R7+bId/PkuwXw3ethJ9ACHlwfOxLG5gdGYkDF/zui16joBtVofUNF f/0B+m1VnrdVZd9WyXxbVZdE/48oC5BobG8WfUIUz6RSi3PmckPrpPMs4oOA45gWdo5xEW6U79KF GdMXskrdAIQdhMt0q3RBCE6gV+h2A4W8Id0w0MO6EYBh4AzrDkPKMQplVG43hMNyGJCDWqIibwBk BWVJmHqYcmDaCMg6rDtJEoK6UaDO6tDbKPuxJ/XOk1wqtRA/G8u00ELtZoCtANtlehfAoBzvk+kD MhyiuFIbhLCRcKHWqW2BYAG6TLsFKOQNaHcAvUO7G2AHcHZohyBlmEIhldsCYUgOQQonQdKcRIuc K0iyJEmSnCBJKAPOMDyNkIQW7WGgjmlHPuJ++0lPlkmcm3qvDayGacGvaOLmgJ6vxYDMfypPBYUy WACWApQBOCFfxhw8dZbKVmpSISzQaAD7NMka/IsTLkO4QLyQJkeTpckSLmuKNJs0CwH6Nds08p8w KuWEvFY5pMphAWJhlCQq8lJBVirIKALAPFaUALlQtgaeRM1O5EEsavZoxD/b3vMj9b0A617i0BwI foDsaEA+fxNouwxVAG4ZkF4J0CjRicNzkFRP/Ep8VzTotonfCW5lG75VhO/nGyDUE08Hq+NeCA38 ESGBPygkCClCGuXCsFzOWc8fl8NOOexBLEvsBxpz7QRZm/iDsMYe1FggPk4SMO0IUMf5MSGDeGNA ZfNjf+m+p/er3lPtJvCO0DDbOpswu5SAwodYWfA8x9Fook8evW+J+Gim2QVjfeQ+4inCDZjKbUWa 3dPBOYk7qTUhlvkW4gwjnsXdz5TEmb2AZbXjgDNITt5sK8qczSSODssSZ5owm03AsrqtWFbjJ3oa aCelNuiSUDeSz7T4Fj2ma0M5WAvDP7BPPOFC3YzwWuTM4tl2O6VKexDaYYAdI95KWNqvSLuHnYTP E38e0bQL4KaJlnYdU8Q5Q5h2hNwE4SzCRwgPIebrCRsIBwnTbpMvkyWUkMwc0iGHdMsgrXJorJHv oxpph8FfRSwkEG0m2o5YQ+2VdjXQWqbsZqDXME8TYXqXM7eR8EXCbSRnN6VmkpzlRI8RvkZ5qDdg lWbKjkbes0m7KtqX3R8h3CjJuX8B9UTMTRNdT/QQ4TzEAk90G6XuJnyMOEco1U6cIOF9hLcRv4pw K+FrhMOEqS5NMuFNpO1luW8zyFa3EsbPmd7TBwnXk+Ugh0m09hZxMOcU2RLZPFhaK+qv9eKI4Ixg 43qcg4cIj1PZQ4THqewhxLxZS6ODMnmzzk0Y7xqmtGQ5yIeZwggTTdbeoF1LFk40ygS+m/A0pTJK NRJ9i2hM9VEpH6X6iO+j/D7SpAxTYQa5qV6iJclU6iTRDVJ+jYV0pjwamrnkAU4izQ6BLXD8l+// J3B+cH83tpf65xDh8Vn8H8EhwlPYY9B7I0SvwhlHM/ckzf2TEk38BsmrkH9Imx2kWUw+AWkou5T8 g4U4WGqC6Ami8yg/jRRgicb8eXJvb6VS6CVu0Wje1+I8StK8j6NPPioJfRf7hWYS8B+Jf4u82TzN HeoB5PwRS7HzuhcRa/Ge7Dda9L4Zmi/hfKSeySFsIswkjH0F9JcI68iu0sjGKojzPtHfIPos0XE0 6z9BeDVqhWfS+5OM8tP/uBhyhFZdHtn/LhpTonEEhVbsE0Mm9oNuK2KtiH5VswtzCgmINRa0DSFB snAcWe0W5MP8QnoU+81wDfm6rWhLmkmyGcbvJvw9xNxFos/h3OTeA/wPcELl+HOwZoFkot8kvJjw MeTDuRNobh3hCf7H6HUFxJ3IEfop53v8/8JSyAdp/wclE70YaxdS+cPoMbCsMAM+j+PvcttxPnJg LXAc+0egT3O/Jfp9pHkb1YjWMs2/gb2qyUXPzOG4l3IdyBFAf24B/y8gcwH3KyorYUnObsLvYU7k c/3YdjgR3iD+JfTnfAq2mjuANDeGXoJ/HtuINOTEUnU8zprNuAZBu35NZX8AMp/lT6OPAs/NCUUC 2nybACuU0I200CTsQA8sfBXwIOYU9hPneS2sy5ow/Xf877SfgVH7nAYEaiq1ywE/S/hXxC9AmjcR 3q6FWaCV6Ge0cGrW/QJpbYNWhPyZmi6gczSVQC/WYC3f1VYBvYPyfA1prU8LeuqrtJBH+7oW+la7 U7sC8nRjHuGb/P8GPE+oBfyqtgewT6sFfAp2bpzwaeE1aN33BNgtCM3Ct4H+sjYAEt4UROIg3kSt bhawT74tLAL8twL2/8eEfuD/WED7/IHwXaxL+A7gGgHOrJprWEr7Req9Lws/An62sA7wa8JPAe8T YM7y/0X4JmLYraGeTwvPAOe0AFYkvISY8wjfJw1R5nexnzVPCV+DPE8JP4M8qwT0Zib0ippJzb/S eIH9aN/SfgXoDhq157U4Ik0asBbNCTi5cZopzWHqHzgla3K0r9K4vEYj8iq2TgveT6vBVPC3r9KI NNOIwAlb+Jk2GfD7hEdI2mFK3Ymjr68hG9hBZX8nbKQeRjvJEt4EvBw9m6AVNgB+XfvXNApfR74A criwcBXwNmGC+Mex7dp/Aske4S3K8xaNQj6OozwWIRoLmI9cveZ3NBY/Q02EERoLOLcL/y78BOfv /bM4Z3F14N+k9fc9WinqiP4HSl1MnAZal09TTkarAN0O8IzyMOSzG5Snn/J/megDRFtpv1FNs6mK SvnQQwpduIPiC0jmGfR+wncpf8F92D0Ke4n+HmLtDxEL3yf8MvpVYe8s2DYXkvShur6HewZhE8mM w//paJIRC/Ml+cifvaYdBf/8n5oRbK/uvwC/qy/AVuvw/uJN7STSEtanEB891buYKvQQfwg5mv/H 3nfHVXVs+8/Zs2fOEbaIgIqIDbsgHAQVsKFiQ+yNJFhQQFFURGM3UWLvicbEXEVimqIi1mhibLFE E0siauwFY9dYo7HAm/XdO+f67rvvvt/9472/fjef+93rrFmzZs2aWWvPzN5s/cFfTRzbfj0eqOaA VpXylVYVo8z0RKAq1fKQx74G5xWh7ZRZS0STjKAnS0X6HULcs57Y0ygPo197sEKrSutJdR9VfSzy JLpwi8Uh9MOac45a26reqbsQ3WWwbiEvqXs6rdV9sVJ6bvcnmkoVYnVBbSn0x/2uBvBPwqK3sJ6Z hHu9ed+X4PhDTxTu7JJigWTUGqImVulkWz5WsDjdLcQql+WgF3utdT7RvwKPADFzCg9ZtUwN5lND mi3muxQVgD6WzA/Y+xBHQMOXoEsCS6OV8uCvhvwNoeZMYSShGn1JSBGn7uNVwVH5kJWwkDhH6N+x UaXBtFowaZIvumOuCmj+KEnQZqkG7+l+4HuC7gv8hjxDHi6MtKsMVvgp0UWt7eOhEysEsQg+7w56 CXAK8CxwG/AUZJqDvgX6OLAKMBXr4WIo/RicOaCxt5LQI8eAcw6Ip7EUCwoLgDsgowNLM9tL7ImK rsOfZYElsCZnTN2Jiv5A6QPMxj8svg84iv8S6zq1AsdzUjVPCU0O7Qg60MpN66d/oOL6gF3dL0QP Qr0AOIJQyyHk5QntJs4FB6gzyEQSSqAIQmk0+LtADwZ/NeRB6yfAWYbSJ+A0hAYf0B+DnorSfeBo 4NSCTjv4l8GZAXtSoA20CAO/HmqZfVkJ/kPwm4LTCRr6gg5BqQ5OAjibQM8GZqPFGuAvB+c55N2A MeAPAf86cCI4SaD3AB8AnwLhYb0N6HTYA29ISMrjKDV7nQv9oeC3B386cBwQo8BPgy4C3gVnDqEb xqtYN0IHRsfuD5kMcK6CswSc8cDJqAvf6vno70y0a7YeDH5L8BeDUxmcOOB+1E0GTgFCXhwGZoED GR100RWab0V7ab4x2Ma7Q3M/OqPQ4tW+k1BFuhZFcS0O0AmJ6EGoFwBHEGo5hLw8od3EueAAdQaZ SEIJVHM7DbM6DfM5DXM7DbOdMAh1o1FrF+jBqLUa2kDrJ0zNkF8GmSfgNEQrPqA/Bj0VpfvA0cCp Bc128C+DMwM2p6AV0CIM/HqoZfZ3JfgPwW8KTido6As6BKU6OAngbAI9G5iNFmuAvxwcnDUJN2AM +EPAvw6cCE4S6D3AB8CnQIyC3gZ0OuyBTyQk5XGUmr3Ohf5Q8NuDPx04DoiR4qdBFwHvmmNHXuVA FblpyCdpyDZpyDyEc0jSDWNXrBvRDoyy3R96MsC5anqJZNwwQ+xLwBkPnIzWMRZ6PvwzE3aa1gaD 3xL8xeBUBicOuB91k0E/KnaKZjs4qCUOA7PAgaRu0t1xvteR8rA4QHdt0YNQLwCOINRyCHl5QruJ c8EB6ljdaZGEEiiCUBoN/i7Qg8FfDXnQ+glwlqH0CTgNocEH9Megp6J0HzgaOLWg0w7+ZXBmwJ4U aAMtwsCvh1pmX1aC/xD8puB0goa+oENQqoOTAM4m0LOB2WixBvjLwXkOeTdgDPhDwL8OnAhOEmic fvAHwKdAeFhvAzod9sAbEpLyOErNXudCfyj47cGfDhwHxCjw06CLgHfBmUPohvEq1o3QgdGx+0Mm A5yr4CwBZzxwMurCt3o++jsT7ZqtB4PfEvzF4FQGJw64H3WTgVOAkBeHgVngQEY36e6gr+D8sAvw Albp80C/xMmkJ3F0rP10rBx0Wi/YJE5u+QrITylSqy99I9Z7+8HHKk5g7cHxjF6vBTocMiuBi8wz VZxc3cf50kDUwrsCtlBagfAu2CnUhzx2IrZb0CZBT8Y54T2UviJammfCb0AG56KaeVYcRHr08+D0 Q1tbCfUrhePIKuBLQi0LeAxr5uHwTzCsErR2sn1OpWpFTfIXYL/pB+y8NPjWVp808xWQKQ35WOyP VqB109vN4LdT8G0VcN43T1Bh21lw6sByB0bqEKz9zdzHoRTrczETYzEAvfsJuLEoRpUi9m0nqV09 AhrOoMWxsLMAFmJOamiXj6N3/PTmsMGJk73Pgb1heTih1gF0beAh7NSege6CleFK4D1oNsDfgj1d KvgnCNUdejF2oOmQT4eFJD+v8BDqEjrA2VJ0hRDtngEOR2kMIceuSuB0XfuWNHMN1mag3cE4nxyI drdD217QlyEJ/Zo//Fmo1r80XlS6CBpOo639oLdaNGnbAJlJ5tMQ6HwJS0oDu0IyDd72A5o75ZKw x466CdATC34C8BlwFPArzNhfMSKTwUkFzgf+CNwNyxdivCpC8jI4xywfKhR46iHiEe8+6OMRlKJF +jsPhf2hDXnGtg/aktGv+tb9hejb4HeG5EzTTuipixmIfKutAgdParTRkMezFRGKVrahNNJqCz4H PRb4FnA9ak0x95WQ2QUNeI4jNiKinZDZCfkA9LEuNMNv/CLaqoD+/gCr2kEy24r6D1XuxbMbRx4i 5T5wNvSfgB7MBDue4EjMRv05LOkKDp7+qLUm6dyAiC6G0voUa7KPlalUK9pszJmLGP2+yF14RqMV h52DUToX82E06G50iqLj2Za607WhUYY9mF1aa1iIZ2eaP776vgx9h6+4HYg44rsgXx2jdgAyZgxu BicbpdOt8aXWW6J0DSTfQn9/Bb4DbA7JXMiEg94PHA35mqDxfEpiRaFmF82iAtjTENbutPbsmdiz Z9O+kj/EPn0pdu6LsbP2BCcCO+4I7Nlxek+Sas9u0tj/0gofb2eo/TtKSwCZ5gD9EjJxFE20O9ZG Ae8BtwNnAfvhSegt0PuBGwh5ClADxwt0aaABzAc/C3VP0o5DaXhOJyfAx9iDjCJa8wLtBb4vMAh8 ByE3UOqAhlzgBGAsPeHiGuhCyESBvgT6GT3t0mbZ61EOBH2PkJcGzoNtz1C635J04ISnHtCUrwd5 4pzE85eTog9ZDvoxaF+xDpgEa/ugFzlAopmsqnC1aRs4USiNpNMzfgGe8dVbKg5HK7NR2g/t1jYt ofd0lMeIfwycs6D3g84FPR/0AVj1M2hfewzsoZNVDZxbkByF/kaB0820E/Qq1I2l59TcAOcxnYpo WfBDP3jmEtmvz4Dl4bKawkQ619Weye8o26N3u6H/GOT3gDOLSjUvWRlt0XMQJk5T66h1C20FYSwY zg+vgl8I3xbCQidkJoAeLj6i01dh0OhA81X46iu0e898jo+Z8xNmjhvOLeOADLga55lh9B0+rbKu fMvn4yTzCkbBhtLRVMobo6c+NIK27qYGGUCtg3OfesRjTD7V5RtxjroXepaA3w2ay5q1RE/UDYCd pDkBMilijsJAzIT9eisgaShDtLKZSm3g5xLf9gVwH7A7TlbvQb466P1Af3hYh4w/cTgT8yhXo/QV /HxRV+sxbQXqxqBH5jltntlf1C0LfAT+EvSiltUXegfyMuoy2FlgWXsVkQhLIFmAtoLIz7YImjO2 rcTRDwp13xeSkNfSX9F9mU75+AphV6Wp4hdFB6I0gFDzgCfvwGPvot3N8Pk4M34xz/MxEzSLdoCm WXQL0bfSjAvMtKtmrsPcXmnmOszYD5F5MHO0M+DfxLgcMDMVnSVqvYBewEdovR7NahUvVGsDZq8v Pa/kC2FPG9iTAnsM0KVJm4pKB+IXGQOWpJlxh9PpCcBY7I4vou7HkC+kZ1WqrYmITcSOnEb3OETW K7Roh1Uc8RJP9jsGEce+gTjiPKHMJ09KD0RxK0L7VnAKiBbFCfWuiK/VZCEvB50OtBKDdj2ov44Z 9B6L0uyjat0hVBFHfmtMsWD7BPG4FZacgYZ41O0Pfgb40ZBcZEYNImiQpFVBDMULx72Al4H/79H5 vBZA88S2BHm+nb4KkUszKlaShrpWFJB8ImZgEObwR9C/G6P5WIxV9FG0xaDnJHHU3WQsZizV7Yha OaStaC+ddfOFdK/R44B/AI8AlwJ7EIoKwMWE6o45BpFOnLqQ8SOUheDk4M51A3xP0Pmgr6B0DjCT 0N4B9FCU7jV10kk7t8PbTYjWJTRUAv8GsA2VqnsQyVdH6RSM0RiUdgFOAa4g1LYDjxGqPO9D1hIt nkPmJVqJAL0G9Ei6U4gcYBPgS0K5CXbWIlq/Dr6Be0oLQnWnIE5Z4CnwI+nUUVlCOBhPplbqH1GU EfJl4K8Hfgu8S6gjm4kesOQ9cEbg2SXTnykbLsFjB9AjL67mj14RbZXDCWcJ0E9Bp8LOMLT7RJZR nGYonQmdRzA/e0GmAD6MRu/egowdMlfQr0eILDwR00PEGToRgq8WQKYdvTshLqPWQkhOoLsYx1th 2nA6odVx7xPBxNci9d04SfOA/6nXyTTnVa8H44SW7GmI0ZkgKtFKlXotDgobZOgkoT15Q7hTqRxB 9zI9RxSHPL34HwXJAmpLyZMl43gSnUrhKe0I4sheVEt6ES0ukH7bdrqnaDngTBDwNuLrHvF5O/0J nfmYOum5tjxGMqIx/H8Dz9w30zsq8kfY/ynGrhf6+zY989VeUh/FQ+gPpbpyFuhLdAfUq8L/zXky UFnLr/IXQPLPZpoPOp4T6VUgUxIyx4HRhFqO2uvYeHeyTVlI9FxCvR2h6kULhefIWi2SOGqF1oJO ychOCQ5/DtxM2oQbv65K/4TfAsg/yjPknz6omwM9T4A5eMq/lLdVeN0sJTu1peh1pJ4KnWTJOugf TbX4IOqdCCVU/eKK88C0Gc/Hm5tI/lS9IPkJpF+vT/dZvY3VIzrHSAcf74nJwejLHmBj+H8qZmku /HZND1R8jXTq01E6DjgQM6oq3qyIpbZEBMY0AnM7zhxNoB9m7DzM832Y5xNBHyVaz8Ns344sUQjJ MdAQZspgnudD5hj4FXGiWw6cQGh7iFaSEbnbUOslJFsjfjvhvtYSelrL3pgVtMpqRpHlhkxVrBuV 2ucSOhiyqz8iOoPQcRX5ORL4Cyx0J0k35GpV1w91ySfjESmTEX21MAdugDOTnn2rducgOmgddYCQ L8HdZD+tWsUHyMPz4fmF4nvE6feoFYz8T/Q6rPpykMEW69SXfTSmYoqZ1UmbbsOcScKsyMCMKsBM m0tvcImuFEFqXj3Hqi8Z84Hu4/thvwOtY/VY9Ad7E08wK1B+xunWKOC9ous0XqBnAftZfLwRAVxg ntoBN+B8LAWomZKFaqepRZEeboCfD3486p4kvu0WsBBtOUA/Bu2FHb0XJH3xfsUYcBygb1utk3ys pYE0R+G0c495BguZQnPnbr4pAc2rgXg+yy9YthHWBr8D9vuzcB41CtpiIZmP0izYcM06qyTJDdjp a6AdKL1Kkuw2OMNhg7/ZL+iMgj0e4IdBvgCtu0FnHOgwtFUZ9HxIXoGkDXq6w57RKG0M2sfkW20R 3ocHYiAzGvRGaNgLXIK2IukNB60b5M33SfxROhw6EyCTAk48SvfDqjJoKxf4BXAf0Jwt1VHX9C16 zaHT9graLkJmBTAG/O6o2w3Pyu8Dn8Oez4GPzFGGpCdwndkKal0G7gH/Bd7W2A/aPEkOgmRVzJYz 4G/FWfFBvFEjcdJ7kGrxWpBfCJthm54KOhD2B6DUHK87oN+FTzYD1+Ik6hPgLYzvSshcBacQnHuW DMmvtOZVPuQJ8eaPth0nnA4grNVuwuZboGeBPmDR6YiOFcB06G+D2ZWP2Uj8Rda7qSanDWjqUQrO r0pDxgFas85+ScYDbyncRq0o2LzAsnYFoiAfrSAWwHlsxjLoPZCMR10vYDxGB6d8jkEkaUd+EOcJ 5WAqFd+jR3cI7dHEkV9hXH4GdsW8LUd8xwzUhf9tmagVDZsXmfMZOAgjPhz2mOfPe2CDGQW+wDKQ fFb0JfLYUuS6L9FTOvnEWNvaYZ7Eond1oaE3em1gft5Gu4XAk8Bc4K/AIGj4CHV3A4+iRcxMrSO0 5RBf2VdTcfrqVwkx60bpHRTuxtPM3Tgb3I3n+IGM4Q0UxtxYli2HicSMxH6sUv+xGWms24CM5MGs 98DkfhlsUFriyKFsDP01WvcuMZXojaGiIvo3A1kx5s5KMm9WnH4pntpHKimDlWBezId5qN/0ZjyV MBdlo2+2WLTGJOOkN65bm0r0bReU61aZYJ6sVP/+Q9LZJOA04BzgYmAWcGVSWuoAtiEldWgi2wrc kTo0dSTbCzyUOmJYGjsGPKkEE9k54JW0Yf3T2A3gvSHJSansMfB5hiq2MSCeZbG/IwdFL8ZRH8R/ 4vydsjG8iaW883d0ew0dr2Hx1xBnx5Ye99fQsLAkq8qCWDhrxGJYHOvGElgSS2Mj2QR8fWERW8o+ Z5JeS2Yz4GGbzcu84l+GoJN2+ka0WqE7qjJ6x8pW7JD5283J8Fcvbtmw1+b2jXX9wbx6GubVO1vJ q2sZf/Pq29ys7/uJakvp982xfu+weuGl/h+Atkvgb9HjWHvG8K9vav/337dSKyg1o2wBWjhvpccz fxbFmrNY1kWtUvqxQSyDjWOZynML2Mcsm61keWwL28H2syPsJLvArrI77DF7qRZHhn0L4/Y19rX2 r3HNtW/FdZ19G6559m/Uda2ivsV1rX07rrn273BdZ9+Ba559J9PUdZf6laukd+O61r4H11z797iu s+/FNc++T0nn2verX+uU9AFc19p/wDXXfhDXdfZDuObZf1TS6+w/qV95SvowrmvtR3DNtR/FdZ39 GK559p+VdN4/eIS+dD6GTfp/8sgv6Pka+3HLM/mWZ05YnjlpeeaUameN/VfLP6ctv5yx/HLW8ss5 yyPnLY9csDxy0fLIJcsjl+GRK5ZHCiyPXLU88pvlkWuWR67DIzcsj9y0PHLL8shtyyN3LI/c/R88 sphlsS9Z7n/rkXuWR363PHLf8sgDyyMPLY88gkceWx55Ys2YPyzPPLU888zyzJ+YMc8t/7yw/PPS 8ssryy+FlkeKTI+oRAOPOGymRxya6REHJ484dNMjDmF6xCFNjzjspkccDtMjjmL/hkf2sp9YPjuH v/B+yJ6rBaabw830iMPd9IjDMD3iKG56xOFhesRRgjzi8DQ94ihpesThZXrE4W16xOFjesRRijzi KG16xFHG9IjD15wxjrKmZxx+pmcc5WjGOPxN/zjKW/6pYPmnouWXatRTRyXLL5UtvwRYfqli+aWq 6Zd/2yN3XB6pbnmkhuWRmpZHalkeqW15JBAeCbI8UsfySLDlkRDLI07LI6HwSF3LI2GWR8Itj9Sz PFLf8kgDeCTC8kik5ZEoyyMNrRnTyPJMY8yYJpZnmlqeibY808z0DH2rk+zGHegDdScw2FB1C3Co u4E/q86cyl8xrAOLN35Rmb6Fo7P+gXHcohYa+aC6KN4Ji1ponFRUS8idsqiFxq+gSO60RS3E91qq smAWocYjjvVgfVVWH8neYTOMM66WzrpaOudq6byrpQuuli66WrrkaunyXy0ZtxTV2tFC8W5b1ELj DqiWinfXov6VRVdcFhW4LLrqsug3l0XXXBZdd1l0w2XRTZdF91wW/e6y6L7Logcui1Ts24JtwWoB 46fRGUAVrQruxWrlVjwMq4CRatQmsbL/1Wb2iVpf5LKt7Bc1j5/Z6BsRpW2VbLVt4bYmtja2UbRy c9/DNHzzQHf/3kXt/YvSDivqY1BHXNRRF3XMRf0MilaHhvYL0VqBwsUoO+6SyndRJ0Bx1QsP5qOd RA2yZK5GVnwImVOvyZTWyKbF2j7GleRi7VeXptMu6oyLOuuizrmo8y7qgou66KIugRJq/H3UnA9g NTV1f9aWqbbU/VnLUtcDSmKZ9oPCLO2yq94Vq992bZ62QI1Rtvalkl+prWFuWq6Wy0poedp65qlt 1DYxL22L9o3Sz7Ea9WG0hovGWsvT+irip6pgtbZa6dyk5Ln2nfadWp+p0dYW4S+06Zt3NPYq02Mt 60bf46K/AWfltaXaUlZB6djJKuIvrpviL65J/1A1Kq9HsrKbt1Y6n4Jq46LauqhYF9UOlMD3Fn3V PqIqaj5ErUeo8RjSTyD5B2US7aGqwfDVPC6ny2ka7Qw4R7e5G3ej/RM30A8lwW/K8pxmuU1WlJWp ni2ereK3eCVekwfxYF6X1+eZfAqfxmfwWXweX8AX8cX8E57FV/AveQ5fw3N5Ht/At/Bv+A6+h+/n h/gR/gs/yc/wC/wKv6Z03eH3+H3+UNQUQaKxaCqaiRaipWgt2op2oqPoKnqKt0Qf0V8MEIPFMDFC jBbjxbtisnhPTBXTxUwxW8wV88X7YqH4UHwkloi/iWViufhUfCFWibVivdgsvhbfiO1il9grfhA/ iWPiF5EvTolz4pK4Km6IO+K+eCyeiZeSSV06pCE9pZf0kb7ST1aQVWQ1WUPWkoGyjgyRoTJM1pOR sqFsKpvJFrKXTJTJcoT7BvdN7lsMzZCGm+FheBmlDT+jghFgVDdqGkGG0wg3IoxGRrQRY7Qx4oxO Rjcj3kgw+hpJxkBjkEH/kuJK7uC0tKjIK6oxqMFrMI0H8kA1BnV4HTXWoTyUCV6P12OST+aTmZ2/ x99jDj6VT2XF+HQ+nbnxmXwmc+dz+Vxm8Pl8PivOF6rR8+Af8g9ZCb6EL2GefBlfxkryT/mnzIt/ wb9g3nwVX8V8+Gq+mpXia/laVpqv4+tYGb6er2e+fDPfzMrybXwb8+Pf8e9YOb6b72b+fB/fx8rz g/wgq8AP88OsIv+Z/8wq8RP8BKvMT/PTLICf5+dZFX6ZX1Yz8zf+G6vGb/KbrDq/zW+zGvwuv8tq 8t/576wWf8AfsNpqBtRkgWoWBLEg0Ug0YnVEE9GEBYtoEc1CRHPRnDlFjIhhoaKVaMXqijaiDQsT sSKWhYsOogOrJ7qILqy+6CF6sAbiTfEmixC9RW8WKfqJfixKpIgU1lAMUjuXRvQtE9ZYZIgM1kSM EqNYUzFOjGPR4h3xDmtG3yRhzUWmyGQtxBQxhcWIaWIaaylmiBmslZglZrHW9GUT1kbME/NYW7FA LGCx4gPxAWsnFolFLE4sFotZe/qiCesgPhGfsI5iqVjKOokskcU6i2yRzbrQF01YV7FSrGTdxBqx hnUXeSKP9RCbxCbWU2wRW1i8mrnfsjfETrGTvSW+F9+zBHFAHGC9xI/iR9ZbHBVHWR/xs/iZ9RXH xXGWqOb1KdZPnBVnWX9xUVxkSaJAFLBkcV1cZynitrjNBojfxe9soHgkHrFU8VQ8ZYPEC/GCDRZF ooilSS45GyLt0s6GSnfpzobJErIES5clZUk2XHpLb5Yhy8gybIQsK8uykbK8LM/elgEygI2SVWVV NlpWl9XZGFlT1mRjZW1Zm42TQTKIjZfBMphNkE7pZBNlXVmXvSPDZTh7V0bICDZJRskoNlk2kU1Y poyW0ew92Vw2Z1NkgkxgU2Vf2ZdNk0kyiU2XGTKDzXBf776ezXTf6L6RzXL/2v1rNttQt1A2xxCG YHONYkYxNs8obhRn842SRkm2wChllGLvG2WNsuwDo7xRni00KhuV2SKjmlGNfWjUMGqwxUagEcg+ MkKMEPaxEWaEsSVGA6MB+8RoaDRkfzOaGk3ZUqOF0YItM1obrVmW0c5ox5YbHY2OLNvoanRlnxo9 jZ5shfGW8Rb7zOhj9GGfG/2N/uwLY4AxgH1ppBqp7CtjsDFY7f/oK04jeGVei4fwMP6Iz+bv84/4 3/hy/hn/im/kX/Nv+U4Vbfv4j/woP85P8bP8Ii/g1yl+RC3+SNQStflsESc6iW4iXiSIviJJDBRp Il2MFGPEBLFCfClyRK7YoGbUVlFbfCd2i33ioDjMj6vrCXFanBeXxW/iprgrHogn4k/xStqkkMVk cX5dxMlSvLIsJwfL+qKbonrLfjJFXHbfrG4QdsPdKGF4G2WMckZFo4pRxwg16hmRRmOjmdHSaGu0 Nzob3Y03jF5GopFsDFF9zUBmY8hsNuQ0DTmNI6fpyF0CWUsiX9mRrxzIV8WQr9yQr9yRlwzkpeLI Sx7ISyWQlzyRl0oiL3khL3kjL/kgL5VCXiqNvFQGeckXeaks8pIf8lI5ZCR/ZKTyyEgVkJEqIttU QrapjGwTgGxTBdmmKrJNNWSb6sg2NZBtaiLb1EK2qY1sE4hsE4RsUwd5IBh5IAR5wIk8EIo8UBd5 IAx5IBx5oB7yQAPkgQjkgUjkgSjkgYbIA42QBxojDzRBHmiKPBCNPNAMeaA58kAL5IEY5IGWyAOt kAdaIw+0QR5oizwQizzQDnkgDnmgPfJAB+SBjsgDndQKoSLrjIjugljuiljuhvjtjvjtgfjtifiN R8y+gZh9EzH7FmI2ATHbCzHbGzHbBzHbFzGbiJjthzjtjzhNQpwmI05TEKcDEKcDEaepiNNBiNPB iNM0xOkQxOlQxOkwxGk64nQ4YjNDzddrLJ0H8NrcycP5Yz6Hf8A/5kt5Nv+cr+Sb+Fa+ne/ie/kP /Cd+jOfzX/k5folf5TfUauaOis3HKjYDVWy2F51Fd/GG6CUSRbJIFUPEcPG2GCsmis/EV2K1WCc2 im0iUOwQe8R+cUgc4fnqelKcERfEFXFN3BL3xEPxh3guCqUmpXSTHvyGaC9L8wDpL9NkfRWXfWR/ OcB9q6EbDsMwPA0fw9fwNyoZVY1go65R34gymhjNjVZGrNHB6GL0MN40ehv9jBRjqOrlsP8flf92 VFI8hiEewxGP9RGPDRCPEYjHSMRjFOKxIeKxEeKxMeKxCeKxKeIxGvHYDPHYHPHYAvEYg3hsiXhs hXhsjXhsg3hsi3iMRTy2QzzGIR7bIx47IB47Ih47IR47IxK7IBK7IhK7IRK7IwZ7IAZ7IgbjEYNv IAbfRAy+hRhMQAz2Qgz2Rgz2QQz2RQwmIgb7IQb7IwaTEIPJiMEUxOAAxOBAxGAqYnAQYnAwYjAN MTgEMTgUMThM7Zsl/h3GvmwFW8O2sF3sEMtnF9gN9pC9xPkH9jystto51WeN+BM1dzP5U4VT+J8K Z/AXCufJGUwTjeUYhU3lOIXN5ASFLf6Jhj+g4Rk0PIeGl9AwExrGQsN4aJgIDWoPJt8hCVDvuqhJ Lmqyi8p0Ue+5qCkuaupfFP3rkxb1CJTatau7/iXGxCtRyDR1f1a7UXWPVpsVdZ92Yw51f03Blw1j cTZUnYVjp+/p/pOKX1WT3/qLUvOBzg8Oq1+P1F7tPOQ8+Lsq2lWZeeW3sB+kPQTDbsCmal6kHSCe Pjiwr76udpNr6HRDyzb3ieyEewl3j//yTIJsoqdOASxI+TfaOoH4ETvmn1wnCVfp24agfnNR1/6i 5GiS/pc7cPOZmw1P2ww8V1LO0u7zcvoAfaCeaj2Vs5lSjPkdYAx/n6/+57fTmen3rSxWe1qbaU+L 2+xadqbfGsVaqdlsoe7OYlIEenDNTzBnonQLlDbdltlAs+nZXZ2dnUGvcfxXVJjkzxrhv46sHxuh pm8aS2Yj1f+b0H/Oyq8p031k5bIF7bZUqDxwwcoFP//QflbTXW/3y84slenM1L93ZvLV2VyzaZp3 mDIxvGpo9MHs3WPnwuBwZ3GXtfSXWs7RMJN316W31r1rqLezJP1weLv1TBwxMHXogJHDhoZ6Oj2I afe2d0lOGjJsaFJoBac/cdy8S7VP7Z8xbMSwlJGVWgzLSB+WkTgyVdWo7KxI5dzb9+/l3VKHJNfp OjJxSHqlTi2aOSuUKR4a5gyr26Cu0xlRt96b6me4s77rp3Pyxv8Vy4o73anc3Vtv37FTl9Aazmrm zwpDW6SmD0zOqBTTtWWlll07RDWPaNmiTpizWXidBqHh4aHVnFXMHvn/0x51Tc4Yldo/2ZlpC3jd wzbBeKatBFN8Ny3TZmO/+dnXui0Oyt8SnvRjeKWH2/X4zNmbi53rkp++/EpC0PUngz5/siV4/eRp b9jutE2rpVd4EjG7p++TXXWL3w1fcGd/y9++neVWLef3T8dP//VB+oDYw4POXVsn3m98V6TfbnZ0 9fpqKd+uXvG1759jvMe8fXh2WMLEuwP23uWvaq6J77t7/HeT5oYtTOznWD+/s1fy/Gbv7D1R7Wad lGbHW4Q//2jys5fTP70b2aXis5tNinpPOijr28+e3TboQIOj0zb7tYvNr/bwwA9z1yUOmHWma8ij uArvBfU/lO3ZpeQ3k+NHNJ9SEL7h3q2FO+Iyj01c7N7x3ZCjnr38Wqas1h70qcpa7d7d/Zf3MpoH TIv6fMfCTjaNPkj8WaatmPKIcJZXLi3voZfWffq0a37B2BaRnZ9Sf26PFyPfaJsyORBzqHwV3ddZ epJPlfBnp7u0Sne7G/1i1IuNgXnf19tYwtmNBCrq7Z3tnG2zW2e3nNZi4MiR6VEhIf0z0oKH/DVO wf2HDQlJH5xK3JD0jGFJb/cfOSLENYw0ihhENSuDlYgzXjpUYApht9n0OGess81fv53atEZWA6NH j/5nDSRn/AvNI53eZG813XC6/aWSO/4hIDnNkhLNO2WfqLC2TNOKbl8GNpg1IL7OemfHhr/v6Zl6 J/l43L5OGQ9HVPvj6hRt39v+w+NbrH5wMGfexUPD4hvNvB5yeFy9OymnTvT+Zt7yntMWeWbf7txg bc8/aoyv0rHsr5eGjNKrORO91n4x77PqW9r81vVhyw77ts6s4blsVcHRKjfHpuUuHBjl98h7r8+W cVFZzc4s6ZF17Pil0osXZMStsz2tKl+UDfx4Q/efxi2/8UHU4NDxkx55ZPWc/fU1sSWy2icfZdaq PzsiN3e235p71+8E72wX/IW93uRH3pVubYpdmLVz6Xs93l1bKiSh1nD3RQMiXjp3Jl9/EnnhVsDd 6XNWb2i42bZn7aWX86qVMgJ2LDfulldp7I5KY/mvpbG8kuvcZh9ruPw80nDeP6axsf8ryaKKs7IZ 9H6vlyclV+qaOmCo0vpaIgutG163blhYWKSZyMJdP52T3/u/SGSWOP9vxP/HxHRjXcKKSsWf1Zyw XYx/d+2926PW1OzaNOps9MSN88Ku9Wz6RedS4d2+OLpp9qqmKxtcrtPpbr3SHX5vP+6s96gZeUH3 30hYdfvyqVpvXy03tcbfHj2rk9WsfqB79IsdDb/ZlvD2wtJd2h0K29cg79Htd1Y+aVYqwZFcvnKD +0HfBLh7rvdcNjpg6pQJHbeVW5D35LPC2Y+NTzpkPznoVvlKToGtfutXIZmDJvMnq+qdW9Rz2Yt2 +R6ZZyPmexUWnBw3ckbS5X57qwXXzl3mW9GjwpY966pu8ui0/YL/woS2X47dvOXskT/Tx9e0Tdn6 H9XZZ1hTyRoA4CQklIChhKJ0BOmBcwIIKEgvUgIKBksQ6b3FgGADgoAiWCjSBBO6ShVcUUBERelN EBdFiihNilgQFLkHXBVd9+7uj/v43F/JNydnkmfmmzffzJGVaau5iEINDrD7my8WksTDZSbu15nU j0ode3D0nh5rIgxVauHsX/cFpn3QiJB+tlAZVmm1yz93t5J5bzJT6NIx4ZtR82S8ziywbfkyJxLy ItsQ0P9xfqAMWQ5RWFklUEVdRU7Zxd4FcFAFcfZOSqo4ZXt7JZz9RihU3ejgCKjglZSV7Z2+A7CJ c7Sxs5x3J7xBVUGJl/e6WSpaBCB+BtACgAikQQRGGvwrAKFchjIZSmI7QA2nBOLwAAisELh7FYEE AEJwFYFb/hmBf9E35WfegT0+slw2SmHd6fcm5jd16ZszZ0zt7ffYcy24DXG+KtAt4wz9POudkMyY V+Y3EtU/rBkYTHtjK8EuEHucZ9Phx4WtZQ1eN9TlDY5IcFpLAmvWLBmNMzA9H3axlT+ULnSRY0Gw hDJr4e6ZcVHiWO/kOVr//uxpD/4CU4eMV4dvcYcYt5hf0Z+f0Yj31n00evgFHy3NzY1Feh6RNM3J cMN1e2HtWNn+3E7HFpOhLcOvCYtL9IFKBHazrejTHVpZRWe0QbUA6b3Ii4beL94eDNauFmkZNegu GrLd8jbg/gsXx33N3anHomIlgLlp5XZHoVJdVxOMac0mzPRviZvy1IY3xDHnHneByjZUFeRd9mfv 0PZKkvwr1Rr4I3N2K3qgWeIkT8TPyjvB1/EyQAMPrgP4vmtk+TovIA6Q++yCxDcXtvv6QjhAE+Xu 4u5oT3EW1QmguPmS3SnBK5hBBZgSiMeD6kp4CDP8HyF+OfyVzv6dYFfIu0jrAKcaodR9oqK6KYFW XlsEHvo2N70a9/yUxMsx0L+JEs5/TZGGf7n09LYuQbybDHusYoM+0VgkuvXNjFuBuWlsTnWwqX+a EVPv4ob+9IDjbZf264f0hD1+XT27MbuBZPCkuFBzQNotiT8vh7yf+IovYXhRJYFMexhoJ3zAIDxC jbd9/x4UlDKxOVfcFXvXsX6Ko8gMBSpa93EDu953xjosNjXYGYKW16Www9pAG1mGQ3r9fVWCJg2v eaaFrsYYQSIQqdKyKPw10x4Lx5FOnMMrA82RAmbYO0N6RseeGEmr0YOXTGYN21Q11DLKD5By+DJi mzhPEzVqC1jsGB58EWwvNCK7AfZlGbBw+BISBTBAL6v0+qkky1gJsSORUAZGAlyMLH9sTXjgSNRK x1D5+7UNsdzLYgdIeCAZnTiYvG9zPuibq1H1CAes+/ohbgSSTRgNs4IFQNsZPZjOd5ZhCqj7tIlS Sc83YD/KDqKtEncNZwOWny3bChgBBjQ9mk6k1j+37OtlMpTaywStKGa9SjFjAEJ5lWJq/6aQW14w ep97/bNfCDhsl/qWEEnD4glf7VL8VY8JjKJP/ta5CbuASbPNuB69QtZPTWM4MEu8+bBlcqiYbYGm otmNzHzi+Wd+lRXl74OvbiXPbRnXCWkcZONzb8o5L4pbYLW8S2zBPTPprPIbyV+TyZBDHKiINrWZ TdQ9/+r19NSzSBFljQpi6oyVeIRsNlUwfiiBSWh2iPA+ht44is05S6gX6DxNTpT1907jfy84Y/XQ tXn9EkmoJTOmWupKsCNRP3Nby/xY1k5iXxrCQF/R7k1vURcV7/MxOxE7POE+cjFT/ma9HAfG+VTK 47eZC1ySLM5qCa8OiphUdgwSR9uDzq0lNajw2vXFC209hbtZqKwvOMXBww+z7VPZI9aafJ9lKgIT Y+GNwRI0D8sYnyd3vPZqrH3pl2UTZ3MkIZYmYMywe64tyxVNydk4iVPkq39BVuV641uq4Uqd334l VonXWRgT3cfx1OmNb6th1wO+seC7yPIHH+T7RaIzCtAfsFLahcPzgxdDDCuZ9hk579MmlOi+JEyW BQY/QiuzeAuGgiJDGOu+5/QPz404Cp2Slyx5FQ7XoMQODiXqSLnfiT+d2BD7KE2saA3p/ExmUaRb OJsHrjLQEyZ0rnCW99A73nCJ68fbPPKNQMXUJ8/8NXtgRx2MOlqPN1SsXcCQY2uzNIsR2h5L7mnn hjjyOcpVLZkf3tEEqIxMkN/TX/zmdVNe8VvwV/gNqALKACS2ihKwXIziwZUQ2mpD4a/b7v+d3hfo XqX9j43jZA97KqwbrB56VpeyTdyysLVvLUGCfaojr8OskAKIck4wdVsn8mxNENCNK0omAZK9MM/R Q9UvTzCxz2GQyTMnmkWalCSi0mffuArKfzw0clxofISQRa8Vt2qMXTBoY2nfW9xeoovMnM/1inft kX5iaFUS2f5c2lBBqiDSYsd2tmEG+Q8eZ84APlGvdwHpC0cfJpWNiiUdfd+Jfc18zcp7e7nBmQvG MBMjF04pGZf8pOEHjGEmmfPH8jiNuFmoF45N7gj6BE8VsmSOgHEAhpPXnoobVt7FWV8oFg7SAQ80 p/VvDo+n2yOuCq0p/TiXdgXeut7Uemkedee2KOsXvS9DI5L33/T+6Ub4O705VusNtcCAsOTP+Iad AcJif84v3THb/n+enlSO4EJeugktp9Bs/843TFgF5/8b9f/R1h0aa46k6DskBv2NfWPlhQcetwZv M4eXKlD893izYS+33jx0ukKhiyszxtuhwgbRRBDFWqb0HdQesqks3pkqOCgEjyyoDJo92f5yM3xq 6OZpNKo+1nhoxoqnz+Jy3PBIrEd3aO2LhFlGxQiGsbOyEuv9Prz7OByUorBmjmnIr2otIf2UJ5qc WEFXP++Kq9uGGXcgafEmnxTVGmLix883gyaBoKYcmbV+3E9zKQKN7b+Ntj8101PBN0E4GVKnIrc3 q2ai6gir7qEuK7LYFNBYGeRM2gPnQ3NjOnu5k99qXHfZWYZTHJmPiGzeRhxN90vwKlA363oXXHNp 7UEHmenMNBllxgP8Dg2awt4i1BnW+/KVbXplz+dfHrn6LDufolJBqPMX55IMZNXYHuO/21CPu6qs rMTctf6C7lJosFhoBg/gMqrLtZe/PmO9WLvemNxY5RvjZvmuR/hQM0lZYwm73ePE6dynKemNm3yr w6QojJxTgWI1adRaKevfSj00T9AD7ct96NjcmktGM1y+i9F4ryuf+rfVx4g3uFSnC0VxOSE0ccW7 TlcMiz2/WtLoWB5kjerSUbAsSCjJCbpcRjsXwP97XBQ2YL0iPp/Zh7YnZkMNbfpYo9jDCWGLhtSp rQNzcGffE6xH6t3rX/iM5yW1gjJLmLo9pEfmAvRHC4oZWgo7eD0bsFmLIBUJLWFkHgIOB6Dl9uvq 5Z8fm3w7RKaF3V0u1/7IXxYGkG31CTX0A75FrCAGWH2VZ7kY/HIjEoRQ0uY2z8NHHomaKOeZE7Pc X16iHlgCOK26hQ0kAtY02VBpmDnMHeYII8N8Vw65XWAUmCjMGhYM84MiV6jdHnrnBgumS4ZK/OVi pQT7+bqS7f3cghV/+FNBUuEwy/SKFDx7hPr8jKreQqfwTbWdDSKTd3roz+860ko2FXZf90Gx7uzN Zn1M6dDFnG5JMc5S6JG0NV0UvLdAvllK9eL9/XcDy7cauoaePSIpKl6REVG4OHXOCxe6tyLMMvE+ N0pROxqynrXq0qQdF9tt41v60Lo3oz0yKmyK3zPfEU8K/2BXXgRPkUVe053bUumnuM/cUp5NS8uu Kst3w+ApzLvogNrAnhhn/bWmQTlBzLHxJqSz26Tli/jg5LIEHdlX91pByc33Cmpjhuas4/sFpKOd LIZz/ag2jH0n8qjgg1ydOuFEo7U9/gxvL0pY6NsG4ptglJy7SSWDnqR3r+tucAeeo1MR0gAVIfFt jhhBKoIHauJcycpTv6wK+PkTiVU5aQusXZ2SrN+erMChL/96BQWyfz5lA9VANSUAAHf/KSNfW5bb ese3SGWYdaYmKk56nlMf9PjB6+VcMbILaqo8ctI1S5RBjlJR06F/5MJtgezxkb5zLdORkb7d/T1C 7LtHNtec3gz42Ql+fGjzHj2dc60r/Dh6iuxVbCUX8mwCdpxgvsCMrO00HGtgeVs26/Gp335gRN8Q 23tfgRqysU5YCUEUun10Kmi2g+3q+JOkvIC45gOiqmUMhzgHgzJoTw5Uebvdojtq99+iVTLCbDi8 BVFxtS/r5DJnbxggZ/yuPAAv0xrkXhYvuuyozOkz6hLgk7BBpzdL/hY+l1QuXf3uPsqgbmCqDqkj ShF4JJggwG5wf0PvFo1bGTE7Lm50acs/+7sFs3VN20byE+JdEa0q4xLEpDlJX/BeXmdpbz7sP/oN VHgNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMTMgMCBvYmoNClsgMFsgNzc4XSAgM1sgMjUwXSAgNVsg NDA4XSAgMTFbIDMzMyAzMzNdICAxNFsgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4XSAgMzRbIDQ0NCA5MjEgNzIyXSAgMzhbIDY2 NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzM10gIDQ3WyA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2 NjcgNTU2IDYxMSA3MjJdICA1OFsgOTQ0XSAgNjBbIDcyMl0gIDYyWyAzMzNdICA2NFsgMzMzXSAg NjZbIDUwMF0gIDY4WyA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAw IDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAg NDQ0IDQ4MF0gIDk2WyA0ODBdICAxNzdbIDUwMF0gXSANCmVuZG9iag0KMjE0IDAgb2JqDQpbIDI1 MCAwIDQwOCAwIDAgMCAwIDAgMzMzIDMzMyAwIDU2NCAyNTAgMzMzIDI1MCAyNzggNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAwIDAgMCAwIDQ0NCA5MjEgNzIyIDAg NjY3IDcyMiA2MTEgNTU2IDcyMiA3MjIgMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2 NjcgNTU2IDYxMSA3MjIgMCA5NDQgMCA3MjIgMCAzMzMgMCAzMzMgMCA1MDAgMCA0NDQgNTAwIDQ0 NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAw IDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAwIDQ4MF0gDQplbmRvYmoN CjIxNSAwIG9iag0KWyAyNTAgMCAwIDUwMCAwIDAgMCAyMTQgMzMzIDMzMyAwIDAgMjUwIDMzMyAy NTAgMjc4IDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDAgMCAzMzMgMzMzIDAgMCAwIDUw MCAwIDYxMSAwIDY2NyA3MjIgNjExIDYxMSAwIDAgMzMzIDAgMCA1NTYgMCAwIDAgNjExIDcyMiA2 MTEgNTAwIDU1NiAwIDAgODMzIDAgMCAwIDM4OSAwIDM4OSAwIDAgMCA1MDAgNTAwIDQ0NCA1MDAg NDQ0IDI3OCA1MDAgNTAwIDI3OCAwIDQ0NCAyNzggNzIyIDUwMCA1MDAgNTAwIDUwMCAzODkgMzg5 IDI3OCA1MDAgNDQ0IDY2NyA0NDQgNDQ0XSANCmVuZG9iag0KMjE2IDAgb2JqDQpbIDI1MCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgNTAwIDUwMCA1MDAgNTAwIDAgMCAwIDAgMCAz MzMgMCAwIDAgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMiAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCA1 NTZdIA0KZW5kb2JqDQoyMTcgMCBvYmoNCjw8L1R5cGUvWFJlZi9TaXplIDIxNy9XWyAxIDQgMl0g L1Jvb3QgMSAwIFIvSW5mbyAzNCAwIFIvSURbPDgxRDcxQTczQjQ0ODMzNDFCNDNEMUVDMDY0NkFG MkI1Pjw4MUQ3MUE3M0I0NDgzMzQxQjQzRDFFQzA2NDZBRjJCNT5dIC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDQ2NT4+DQpzdHJlYW0NCnicNdRJVw5wFAfg982YOVORBhUyU+YMCZmJUCRThoyV Mss8i8xknsdP4dhwrC34BhYWFpbk7f9wF/c5d3HvOXfzi0Ri1dwcjfWESKSFenwIxOUEEjPwJZD0 Eb8Dfd4F+jYFkrNRiJ+BfnmBlOn4jO+B1EZ8DaR9C6SfCvTPxY9AxvNA5sNA1srAgJJA/p9Awa/A zBGBkhQUB0orAxVLYl/F/hsWeYGXeIXnKEFbRPFv73XsyqbS/1MrxKENWqMz2qED2iMendARPdAF XdEd3ZCAZPRCTySiN/ogCX2RihT0QybSkYYM9Ec2BiALgzAQwzAEgzEUozECwzEKIzEOucjBWIxB HiZgPCZhIvIxBZMxDVMxCwWYjpmYgaWYjULMxRwUYTHmYSHmYwEWYQlWYBmKsRylWIkKrEI5yrAa a7Aea7EOG7ARm7AZW1CJrdiGN9iOHdiJOtSiCrtQg2rsxh7sxRHUYz/24RAO4CAO4yiO4TjO4SxO 4gRO4xTO4Dwu4CIacAmX0YgreIuruIbruIGbuIXbuINHeIi7aMJ93MMDPMYTPMWzWOhUjQsJVr2h heiqhkBZiNFoeVZgTVELcTXvA7UVgbpPgb3xkchfZzJ6Dw0KZW5kc3RyZWFtDQplbmRvYmoNCnhy ZWYNCjAgMjE4DQowMDAwMDAwMDM1IDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAw MDEyNSAwMDAwMCBuDQowMDAwMDAwMTk1IDAwMDAwIG4NCjAwMDAwMDA1NjIgMDAwMDAgbg0KMDAw MDAwNTkyMiAwMDAwMCBuDQowMDAwMDA2MTAxIDAwMDAwIG4NCjAwMDAwMDYzNDQgMDAwMDAgbg0K MDAwMDAwNjM5NyAwMDAwMCBuDQowMDAwMDA2NTcxIDAwMDAwIG4NCjAwMDAwMDY4MDkgMDAwMDAg bg0KMDAwMDAwNjk1MiAwMDAwMCBuDQowMDAwMDA2OTgyIDAwMDAwIG4NCjAwMDAwMDcxNTMgMDAw MDAgbg0KMDAwMDAwNzIyNyAwMDAwMCBuDQowMDAwMDA3NDg5IDAwMDAwIG4NCjAwMDAwMDc2Mjcg MDAwMDAgbg0KMDAwMDAwNzY1NyAwMDAwMCBuDQowMDAwMDA3ODIzIDAwMDAwIG4NCjAwMDAwMDc4 OTcgMDAwMDAgbg0KMDAwMDAwODE1NCAwMDAwMCBuDQowMDAwMDA4MzI0IDAwMDAwIG4NCjAwMDAw MDg0OTkgMDAwMDAgbg0KMDAwMDAwODY4NSAwMDAwMCBuDQowMDAwMDA4ODY4IDAwMDAwIG4NCjAw MDAwMDkxMTggMDAwMDAgbg0KMDAwMDAwOTMwNSAwMDAwMCBuDQowMDAwMDA5NTU5IDAwMDAwIG4N CjAwMDAwMTY2MzggMDAwMDAgbg0KMDAwMDAxNzE0MSAwMDAwMCBuDQowMDAwMDE3NDU0IDAwMDAw IG4NCjAwMDAwMjIzMDEgMDAwMDAgbg0KMDAwMDAyMjM1NSAwMDAwMCBuDQowMDAwMDIyNjMyIDAw MDAwIG4NCjAwMDAwMjU0MjUgMDAwMDAgbg0KMDAwMDAwMDAzNiA2NTUzNSBmDQowMDAwMDAwMDM3 IDY1NTM1IGYNCjAwMDAwMDAwMzggNjU1MzUgZg0KMDAwMDAwMDAzOSA2NTUzNSBmDQowMDAwMDAw MDQwIDY1NTM1IGYNCjAwMDAwMDAwNDEgNjU1MzUgZg0KMDAwMDAwMDA0MiA2NTUzNSBmDQowMDAw MDAwMDQzIDY1NTM1IGYNCjAwMDAwMDAwNDQgNjU1MzUgZg0KMDAwMDAwMDA0NSA2NTUzNSBmDQow MDAwMDAwMDQ2IDY1NTM1IGYNCjAwMDAwMDAwNDcgNjU1MzUgZg0KMDAwMDAwMDA0OCA2NTUzNSBm DQowMDAwMDAwMDQ5IDY1NTM1IGYNCjAwMDAwMDAwNTAgNjU1MzUgZg0KMDAwMDAwMDA1MSA2NTUz NSBmDQowMDAwMDAwMDUyIDY1NTM1IGYNCjAwMDAwMDAwNTMgNjU1MzUgZg0KMDAwMDAwMDA1NCA2 NTUzNSBmDQowMDAwMDAwMDU1IDY1NTM1IGYNCjAwMDAwMDAwNTYgNjU1MzUgZg0KMDAwMDAwMDA1 NyA2NTUzNSBmDQowMDAwMDAwMDU4IDY1NTM1IGYNCjAwMDAwMDAwNTkgNjU1MzUgZg0KMDAwMDAw MDA2MCA2NTUzNSBmDQowMDAwMDAwMDYxIDY1NTM1IGYNCjAwMDAwMDAwNjIgNjU1MzUgZg0KMDAw MDAwMDA2MyA2NTUzNSBmDQowMDAwMDAwMDY0IDY1NTM1IGYNCjAwMDAwMDAwNjUgNjU1MzUgZg0K MDAwMDAwMDA2NiA2NTUzNSBmDQowMDAwMDAwMDY3IDY1NTM1IGYNCjAwMDAwMDAwNjggNjU1MzUg Zg0KMDAwMDAwMDA2OSA2NTUzNSBmDQowMDAwMDAwMDcwIDY1NTM1IGYNCjAwMDAwMDAwNzEgNjU1 MzUgZg0KMDAwMDAwMDA3MiA2NTUzNSBmDQowMDAwMDAwMDczIDY1NTM1IGYNCjAwMDAwMDAwNzQg NjU1MzUgZg0KMDAwMDAwMDA3NSA2NTUzNSBmDQowMDAwMDAwMDc2IDY1NTM1IGYNCjAwMDAwMDAw NzcgNjU1MzUgZg0KMDAwMDAwMDA3OCA2NTUzNSBmDQowMDAwMDAwMDc5IDY1NTM1IGYNCjAwMDAw MDAwODAgNjU1MzUgZg0KMDAwMDAwMDA4MSA2NTUzNSBmDQowMDAwMDAwMDgyIDY1NTM1IGYNCjAw MDAwMDAwODMgNjU1MzUgZg0KMDAwMDAwMDA4NCA2NTUzNSBmDQowMDAwMDAwMDg1IDY1NTM1IGYN CjAwMDAwMDAwODYgNjU1MzUgZg0KMDAwMDAwMDA4NyA2NTUzNSBmDQowMDAwMDAwMDg4IDY1NTM1 IGYNCjAwMDAwMDAwODkgNjU1MzUgZg0KMDAwMDAwMDA5MCA2NTUzNSBmDQowMDAwMDAwMDkxIDY1 NTM1IGYNCjAwMDAwMDAwOTIgNjU1MzUgZg0KMDAwMDAwMDA5MyA2NTUzNSBmDQowMDAwMDAwMDk0 IDY1NTM1IGYNCjAwMDAwMDAwOTUgNjU1MzUgZg0KMDAwMDAwMDA5NiA2NTUzNSBmDQowMDAwMDAw MDk3IDY1NTM1IGYNCjAwMDAwMDAwOTggNjU1MzUgZg0KMDAwMDAwMDA5OSA2NTUzNSBmDQowMDAw MDAwMTAwIDY1NTM1IGYNCjAwMDAwMDAxMDEgNjU1MzUgZg0KMDAwMDAwMDEwMiA2NTUzNSBmDQow MDAwMDAwMTAzIDY1NTM1IGYNCjAwMDAwMDAxMDQgNjU1MzUgZg0KMDAwMDAwMDEwNSA2NTUzNSBm DQowMDAwMDAwMTA2IDY1NTM1IGYNCjAwMDAwMDAxMDcgNjU1MzUgZg0KMDAwMDAwMDEwOCA2NTUz NSBmDQowMDAwMDAwMTA5IDY1NTM1IGYNCjAwMDAwMDAxMTAgNjU1MzUgZg0KMDAwMDAwMDExMSA2 NTUzNSBmDQowMDAwMDAwMTEyIDY1NTM1IGYNCjAwMDAwMDAxMTMgNjU1MzUgZg0KMDAwMDAwMDEx NCA2NTUzNSBmDQowMDAwMDAwMTE1IDY1NTM1IGYNCjAwMDAwMDAxMTYgNjU1MzUgZg0KMDAwMDAw MDExNyA2NTUzNSBmDQowMDAwMDAwMTE4IDY1NTM1IGYNCjAwMDAwMDAxMTkgNjU1MzUgZg0KMDAw MDAwMDEyMCA2NTUzNSBmDQowMDAwMDAwMTIxIDY1NTM1IGYNCjAwMDAwMDAxMjIgNjU1MzUgZg0K MDAwMDAwMDEyMyA2NTUzNSBmDQowMDAwMDAwMTI0IDY1NTM1IGYNCjAwMDAwMDAxMjUgNjU1MzUg Zg0KMDAwMDAwMDEyNiA2NTUzNSBmDQowMDAwMDAwMTI3IDY1NTM1IGYNCjAwMDAwMDAxMjggNjU1 MzUgZg0KMDAwMDAwMDEyOSA2NTUzNSBmDQowMDAwMDAwMTMwIDY1NTM1IGYNCjAwMDAwMDAxMzEg NjU1MzUgZg0KMDAwMDAwMDEzMiA2NTUzNSBmDQowMDAwMDAwMTMzIDY1NTM1IGYNCjAwMDAwMDAx MzQgNjU1MzUgZg0KMDAwMDAwMDEzNSA2NTUzNSBmDQowMDAwMDAwMTM2IDY1NTM1IGYNCjAwMDAw MDAxMzcgNjU1MzUgZg0KMDAwMDAwMDEzOCA2NTUzNSBmDQowMDAwMDAwMTM5IDY1NTM1IGYNCjAw MDAwMDAxNDAgNjU1MzUgZg0KMDAwMDAwMDE0MSA2NTUzNSBmDQowMDAwMDAwMTQyIDY1NTM1IGYN CjAwMDAwMDAxNDMgNjU1MzUgZg0KMDAwMDAwMDE0NCA2NTUzNSBmDQowMDAwMDAwMTQ1IDY1NTM1 IGYNCjAwMDAwMDAxNDYgNjU1MzUgZg0KMDAwMDAwMDE0NyA2NTUzNSBmDQowMDAwMDAwMTQ4IDY1 NTM1IGYNCjAwMDAwMDAxNDkgNjU1MzUgZg0KMDAwMDAwMDE1MCA2NTUzNSBmDQowMDAwMDAwMTUx IDY1NTM1IGYNCjAwMDAwMDAxNTIgNjU1MzUgZg0KMDAwMDAwMDE1MyA2NTUzNSBmDQowMDAwMDAw MTU0IDY1NTM1IGYNCjAwMDAwMDAxNTUgNjU1MzUgZg0KMDAwMDAwMDE1NiA2NTUzNSBmDQowMDAw MDAwMTU3IDY1NTM1IGYNCjAwMDAwMDAxNTggNjU1MzUgZg0KMDAwMDAwMDE1OSA2NTUzNSBmDQow MDAwMDAwMTYwIDY1NTM1IGYNCjAwMDAwMDAxNjEgNjU1MzUgZg0KMDAwMDAwMDE2MiA2NTUzNSBm DQowMDAwMDAwMTYzIDY1NTM1IGYNCjAwMDAwMDAxNjQgNjU1MzUgZg0KMDAwMDAwMDE2NSA2NTUz NSBmDQowMDAwMDAwMTY2IDY1NTM1IGYNCjAwMDAwMDAxNjcgNjU1MzUgZg0KMDAwMDAwMDE2OCA2 NTUzNSBmDQowMDAwMDAwMTY5IDY1NTM1IGYNCjAwMDAwMDAxNzAgNjU1MzUgZg0KMDAwMDAwMDE3 MSA2NTUzNSBmDQowMDAwMDAwMTcyIDY1NTM1IGYNCjAwMDAwMDAxNzMgNjU1MzUgZg0KMDAwMDAw MDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUgZg0KMDAw MDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1MzUgZg0K MDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAwMTgxIDY1NTM1IGYNCjAwMDAwMDAxODIgNjU1MzUg Zg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAwMDAwMTg0IDY1NTM1IGYNCjAwMDAwMDAxODUgNjU1 MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQowMDAwMDAwMTg3IDY1NTM1IGYNCjAwMDAwMDAxODgg NjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBmDQowMDAwMDAwMTkwIDY1NTM1IGYNCjAwMDAwMDAx OTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUzNSBmDQowMDAwMDAwMTkzIDY1NTM1IGYNCjAwMDAw MDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2NTUzNSBmDQowMDAwMDAwMTk2IDY1NTM1IGYNCjAw MDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5OCA2NTUzNSBmDQowMDAwMDAwMTk5IDY1NTM1IGYN CjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAwMDIwMSA2NTUzNSBmDQowMDAwMDAwMjAyIDY1NTM1 IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAwMDAwMDIwNCA2NTUzNSBmDQowMDAwMDAwMjA1IDY1 NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDI4NDcw IDAwMDAwIG4NCjAwMDAwMjg3NzAgMDAwMDAgbg0KMDAwMDA4ODcxNiAwMDAwMCBuDQowMDAwMDg5 MDY1IDAwMDAwIG4NCjAwMDAwODkzODAgMDAwMDAgbg0KMDAwMDA4OTY4MCAwMDAwMCBuDQowMDAw MTYwMTkzIDAwMDAwIG4NCjAwMDAxNjA2MTEgMDAwMDAgbg0KMDAwMDE2MDk2OSAwMDAwMCBuDQow MDAwMTYxMjg5IDAwMDAwIG4NCjAwMDAxNjE0OTUgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAy MTgvUm9vdCAxIDAgUi9JbmZvIDM0IDAgUi9JRFs8ODFENzFBNzNCNDQ4MzM0MUI0M0QxRUMwNjQ2 QUYyQjU+PDgxRDcxQTczQjQ0ODMzNDFCNDNEMUVDMDY0NkFGMkI1Pl0gPj4NCnN0YXJ0eHJlZg0K MTYyMTYzDQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDIxOC9Sb290IDEgMCBS L0luZm8gMzQgMCBSL0lEWzw4MUQ3MUE3M0I0NDgzMzQxQjQzRDFFQzA2NDZBRjJCNT48ODFENzFB NzNCNDQ4MzM0MUI0M0QxRUMwNjQ2QUYyQjU+XSAvUHJldiAxNjIxNjMvWFJlZlN0bSAxNjE0OTU+ Pg0Kc3RhcnR4cmVmDQoxNjY2ODMNCiUlRU9G --_007_0fb6887f5f964458a8f8e4c1d8db7fe2TUCM03TUECSPUNICCORG_-- From nobody Tue Mar 3 15:09: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 F120F1A1BCD for ; Tue, 3 Mar 2015 15:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdfVKxGrkJz2 for ; Tue, 3 Mar 2015 15:09:30 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0611A1B7A for ; Tue, 3 Mar 2015 15:09:30 -0800 (PST) Received: from fifthhorseman.net (201.Red-81-36-32.dynamicIP.rima-tde.net [81.36.32.201]) by che.mayfirst.org (Postfix) with ESMTPSA id AD186F984; Tue, 3 Mar 2015 18:09:27 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 85F4920338; Wed, 4 Mar 2015 00:09:27 +0100 (CET) From: Daniel Kahn Gillmor To: Hubert Kario , tls@ietf.org In-Reply-To: <3129450.Wk0h42r8eh@pintsize.usersys.redhat.com> References: <3F4C76ED-4375-438F-ADC9-66E49A19574B@ieca.com> <878ufhaptd.fsf@alice.fifthhorseman.net> <3129450.Wk0h42r8eh@pintsize.usersys.redhat.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 04 Mar 2015 00:09:27 +0100 Message-ID: <87385l8yqg.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-tls-negotiated-ff-dhe@tools.ietf.org Subject: Re: [TLS] WGLC: draft-ietf-tls-negotiated-ff-dhe-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 23:09:32 -0000 On Mon 2015-03-02 13:11:54 +0100, Hubert Kario wrote: > I also see a change from 2048 to 2432 of the smallest group (page 4, line 35), > but no change in the parameters... Thanks for the review, Hubert (and several others who notified me off-list about the lingering 2432). I had initially had 2432 as the lowest FFDHE parameter, but moved it to 2048 at the request of the WG. Apparently i missed one 2432 → 2048 change in the line mentioned here. I've just uploaded -07 to correct the error. --dkg From nobody Tue Mar 3 15:15: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 304B21A1BEA; Tue, 3 Mar 2015 15:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_6FpphY1P-c; Tue, 3 Mar 2015 15:15:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D731A0263; Tue, 3 Mar 2015 15:15:48 -0800 (PST) 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: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303231548.18831.97394.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 15:15:48 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-07.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: Tue, 03 Mar 2015 23:15:49 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-07.txt Pages : 25 Date : 2015-03-03 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-07 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 Tue Mar 3 16:06: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 48DCF1A8701 for ; Tue, 3 Mar 2015 16:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC2eaQdlzUiu for ; Tue, 3 Mar 2015 16:06:23 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (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 C36E11A86FA for ; Tue, 3 Mar 2015 16:06:22 -0800 (PST) Received: by qcwb13 with SMTP id b13so33609945qcw.6 for ; Tue, 03 Mar 2015 16:06:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Z3y0krI4CqHoutcviO0wgxtv4q6qLuVwRx9J4WRprGw=; b=cOo4WIi3RMJHpklsD+pSEFkQ8xRqDWqsq21HnpY2pwBcCsWdAVFWTHpMPT/W5OLsKY C3e+Uwp8jkBERxrTjR31HdYT4JbreHkL+bXHfSMQl+PB4UI92m3/sOfvV//oJICJof0b VhwiVgGAxXfU8bLstrz6KMqVoDi9tqlC3iewg1lJyuwn6Id8I0cMRO4Ok0dYc72ZYEQp IMKLmAUwZ9Yz9eyBvaWHqZzW6kWjdWWLvQ8BXaFLK2Vi9PA9Rm6VJq/tBtHUShxLaIID nZFs8kJ+uLRdnMCZvsVgGItpZhDxqZfNjmjRiTAopj92OwXqD3ASG0Glh2zbx/nKn1pH Japw== X-Gm-Message-State: ALoCoQl6LgHcbxXcsnLzvW7zaVgksLYR2ZWklDOVLnk/5Vh1/JjV8ATlwacsCRrNliYwfVtaFc3x MIME-Version: 1.0 X-Received: by 10.229.96.135 with SMTP id h7mr2456397qcn.0.1425427582084; Tue, 03 Mar 2015 16:06:22 -0800 (PST) Received: by 10.96.121.104 with HTTP; Tue, 3 Mar 2015 16:06:22 -0800 (PST) X-Originating-IP: [50.206.82.175] Date: Tue, 3 Mar 2015 16:06:22 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113396a4af00e005106b3836 Archived-At: Subject: [TLS] TLS Interim - update and agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 00:06:24 -0000 --001a113396a4af00e005106b3836 Content-Type: text/plain; charset=UTF-8 If you are planning on attending the interim meeting and you have not received an email from me about Logistics for TLS interim meeting then you need to contact me so I know you are coming. The agenda for the interim is available here: http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1 This is a working session so we will be making adjustments as needed. Thanks, Joe --001a113396a4af00e005106b3836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are planning on attending the interim meeting = and you have not received an email from me about Logistics for TLS interim = meeting then you need to contact me so I know you are coming.
The agenda for the interim is available here:=C2=A0

http://www.ietf.org/proceedings/interim/2015/03= /10/tls/agenda/agenda-interim-2015-tls-1

T= his is a working session so we will be making adjustments as needed. =C2=A0=

Thanks,

Joe
--001a113396a4af00e005106b3836-- From nobody Wed Mar 4 05:08: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 29A191A03C7 for ; Wed, 4 Mar 2015 05:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 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, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 hnEsDlbnJ_4C for ; Wed, 4 Mar 2015 05:08:45 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c: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 98AE61A1A2D for ; Wed, 4 Mar 2015 05:08:45 -0800 (PST) Received: by wesq59 with SMTP id q59so9280079wes.3 for ; Wed, 04 Mar 2015 05:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jTygli5Upa19AEtqdcKcQJxCHH+2wLRn64s1vnsa9MQ=; b=UC1Mzv0u439QakEd958+6KvqZ1te9e5JWaUya3gNtw1OtjT1MOfzIv28SyOGVUmNTz b6VVPq9QmKO0hAmnIZhIBw0MJTfLPGtCOUk0/05sMg0pdd6/R4vRIAe07SHDPZ4q1TbC AObjQurNKV02P/1qdP3VVMd6xryxv9qlsLYQ5fnP7+tddLmSFtEvYc1bA6RJ3S70ln70 PJ1xp2guk4i2BLeNaWbN0W/hXw6NA2aAkADQWniEvw8DXNQdiomGn8yjElqBg8c/a4zr jALZv2GnGfnL6v3W4os854BxIsdSSZsnwjyvGTxW2v7TkQCKcyoAzcZL7iFEplNB1Ad7 jy5A== X-Received: by 10.195.13.104 with SMTP id ex8mr7979221wjd.12.1425474524417; Wed, 04 Mar 2015 05:08:44 -0800 (PST) Received: from [172.24.251.208] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id m4sm7031697wik.20.2015.03.04.05.08.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Mar 2015 05:08:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CDC46350-EE3F-44FB-9943-508CDCF4566F" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Wed, 4 Mar 2015 15:08:40 +0200 Message-Id: References: To: Joseph Salowey X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Interim - update and agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 13:08:48 -0000 --Apple-Mail=_CDC46350-EE3F-44FB-9943-508CDCF4566F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Will there be an audio stream or at least a recording? > On Mar 4, 2015, at 2:06 AM, Joseph Salowey wrote: >=20 > If you are planning on attending the interim meeting and you have not = received an email from me about Logistics for TLS interim meeting then = you need to contact me so I know you are coming. >=20 > The agenda for the interim is available here:=20 >=20 > = http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-inter= im-2015-tls-1 = >=20 > This is a working session so we will be making adjustments as needed. =20= >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_CDC46350-EE3F-44FB-9943-508CDCF4566F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Will there be an audio stream or at least a recording?

On Mar 4, 2015, at 2:06 AM, Joseph Salowey <joe@salowey.net> = wrote:

If you are planning on attending = the interim meeting and you have not received an email from me about = Logistics for TLS interim meeting then you need to contact me so I know = you are coming.

The agenda for = the interim is available here: 

http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/a= genda-interim-2015-tls-1

This is a working session so we will be = making adjustments as needed.  

Thanks,

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

= --Apple-Mail=_CDC46350-EE3F-44FB-9943-508CDCF4566F-- From nobody Wed Mar 4 05:49: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 9B22D1A1AD0 for ; Wed, 4 Mar 2015 05:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK6OSDrGDL4k for ; Wed, 4 Mar 2015 05:49:12 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BF91A1AC7 for ; Wed, 4 Mar 2015 05:49:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,687,1418079600"; d="scan'208";a="124356246" Received: from ra178-1-88-163-20-214.fbx.proxad.net (HELO [192.168.0.2]) ([88.163.20.214]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2015 14:49:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Benjamin Beurdouche In-Reply-To: Date: Wed, 4 Mar 2015 14:49:10 +0100 Content-Transfer-Encoding: 7bit Message-Id: <09A2861B-A392-40ED-9D1A-2257D0B30ED1@inria.fr> References: To: Yoav Nir X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] TLS Interim - update and agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 13:49:14 -0000 > On 04 Mar 2015, at 14:08, Yoav Nir wrote: > > Will there be an audio stream or at least a recording? +1 for recording if possible =) B. From nobody Thu Mar 5 11:41: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 C5DA91A885F for ; Thu, 5 Mar 2015 11:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmL8wMQ7mSQ7 for ; Thu, 5 Mar 2015 11:41:16 -0800 (PST) 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 86EE61A873E for ; Thu, 5 Mar 2015 11:41:09 -0800 (PST) Received: by wibbs8 with SMTP id bs8so9699582wib.0 for ; Thu, 05 Mar 2015 11:41:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SDdSKDeFGFeexOgLwtcqQYY4JkExQ+tVf0DfCnSkqwQ=; b=NPBntq8kOYeX6ZdpvlJO/vKc3J1cg/jrWlrUm9GX9y8ks9AGHPxZ/ZH2J9loY5aS40 t7pi9B8LuPLsNbqMjbwHtzLplce9KIohKuafOiz9/NY54vo01w1gSaKqvl8BSIZduJuZ K+VLYvY81yXpUCh52t8g92KZTrBkNA0Kj1eW6CbhdRvJfOGMGUO66QEItdtGr9r5ca4f 7QFpSZ9ANPgVBCrbBRxIV6CuO3f7/hECK6qVKW+wXHtkFb3awL26ngnnFzf36FxZ1umn /iUqn6Z74xi+sgrzVPq8m0989MHkIbJsCc5k79IildxVpLxG9dakQhJZlnOzdWDAOkQ0 9PnQ== X-Gm-Message-State: ALoCoQk8jCEObQ+DoH0Fd4SH74oWzld24LptA3GRLIM6TXA26Gmqy7Qb64SmP+lVeSHDXwbLp0or X-Received: by 10.194.191.228 with SMTP id hb4mr22510724wjc.116.1425584468214; Thu, 05 Mar 2015 11:41:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.214.203 with HTTP; Thu, 5 Mar 2015 11:40:28 -0800 (PST) In-Reply-To: <201502250009.08942.davemgarrett@gmail.com> References: <201502242043.50128.davemgarrett@gmail.com> <201502250009.08942.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 5 Mar 2015 11:40:28 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b8750bed36e6005108fbfd7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 19:41:18 -0000 --047d7b8750bed36e6005108fbfd7 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 24, 2015 at 9:09 PM, Dave Garrett wrote: > On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote: > > On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett > > wrote: > > > > > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > > > > version of the basic mechanism. > > > > > > The current proposal says: > > > > > > "An implementation MAY send an UpdateRekey at any time after > > > the handshake completes." > > > > > > Is there a particular reason to not just have an automatic rekey at > > > semi-regular intervals? So, every N records or M minutes (or whichever > > > comes first) an endpoint must send a rekey, and then after a similarly > > > measured interval the other endpoint sends a rekey; repeat ad > infinitum. > > > > It's not entirely clear that we know how to design a good heuristic here, > > especially one that covers the entire range of possible algorithms. > > That's sort of my point; this proposal requires implementations to do so. > I'm saying that picking one in the spec would be preferable to leaving it > up to the whims of whatever the many combinations of implementations > end up deciding. Even if some use-case needs to add rekeys, starting > from a conservative heuristic in the spec would ensure implementations > are provided with at least a general expectation of how to use this. I'm going to argue that the frequency of update is a semi-orthogonal issue. I.e., if you think this mechanism works, then we can decide to put it in and have a separate discussion of minimum update frequency. Best, -Ekr > > As a minor nit, it's kind of a pain to say every M minutes because > > often TLS stacks are driven by the application and don't have internal > > timers, but you could of course say "first record after M minutes" > > which would (probably) be close enough. > > I'm not suggesting a precise heuristic here; just some semi-regular > interval > that would be more specific than "MAY ... at any time". With it left as > vague > as proposed, you could get deployments that never rekey or ones that > decide to rekey stupidly frequently. (DoS risk if not implemented > efficiently?) Picking any arbitrary interval would make things simpler and > ensure that this feature is used sufficiently. > > The simplest route is to just specify a number of records to rekey after. > > > > This would also ensure entropy for rekeying comes from both endpoints > > > equally over the course of the connection. > > > > Can you explain more about why that's an important consideration? > > It's just something that occurs to me with the current proposal. It allows > for one sided rekeys, whereas the handshake gets randomness in each > hello from each endpoint. It just strikes me as notably different to rely > on > just the one source of entropy here (plus previous). > > It's a "huh, interesting" thought not a "oh, that's horrible" thought. > > > > I would expect it would be better to not rely on implementations all > > > designing their own heuristics on when to send rekey updates, and also > > > would avoid multiple updates being sent at the same time by each > endpoint > > > (and the possible pitfalls of doing so) > > > > The algorithm in this document is intended to be safe in the case of both > > simultaneous > > and (I believe) pipelined updates. I'd be interested in knowing if it's > not. > > Yes, I don't think it's a spec risk. An implementation risk is possible, > though. > > It's a new feature that could end up with a new setting for an admin to > fiddle with that probably doesn't need to be highly variable to do the job. > Or put another way, it's a feature that I'm overthinking about the > possibility > of implementations overthinking how to use it. ;) > > > Dave > --047d7b8750bed36e6005108fbfd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 24, 2015 at 9:09 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote:
> On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
>
> > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > > > [0] See https://github.com/tlswg/tls1= 3-spec/pull/94 for a WIP
> > > version of the basic mechanism.
> >
> > The current proposal says:
> >
> > "An implementation MAY send an UpdateRekey at any time after=
> > the handshake completes."
> >
> > Is there a particular reason to not just have an automatic rekey = at
> > semi-regular intervals? So, every N records or M minutes (or whic= hever
> > comes first) an endpoint must send a rekey, and then after a simi= larly
> > measured interval the other endpoint sends a rekey; repeat ad inf= initum.
>
> It's not entirely clear that we know how to design a good heuristi= c here,
> especially one that covers the entire range of possible algorithms.
That's sort of my point; this proposal requires implementations = to do so.
I'm saying that picking one in the spec would be preferable to leaving = it
up to the whims of whatever the many combinations of implementations
end up deciding. Even if some use-case needs to add rekeys, starting
from a conservative heuristic in the spec would ensure implementations
are provided with at least a general expectation of how to use this.

I'm going to argue that the frequency of upda= te is a semi-orthogonal issue.
I.e., if you think this mechanism = works, then we can decide to put it in
and have a separate discus= sion of minimum update frequency.

Best,
= -Ekr

> As a minor nit, it's kind of a pain to say every M minutes because=
> often TLS stacks are driven by the application and don't have inte= rnal
> timers, but you could of course say "first record after M minutes= "
> which would (probably) be close enough.

I'm not suggesting a precise heuristic here; just some semi-regu= lar interval
that would be more specific than "MAY ... at any time". With it l= eft as vague
as proposed, you could get deployments that never rekey or ones that
decide to rekey stupidly frequently. (DoS risk if not implemented
efficiently?) Picking any arbitrary interval would make things simpler and<= br> ensure that this feature is used sufficiently.

The simplest route is to just specify a number of records to rekey after.
> > This would also ensure entropy for rekeying comes from both endpo= ints
> > equally over the course of the connection.
>
> Can you explain more about why that's an important consideration?<= br>
It's just something that occurs to me with the current proposal.= It allows
for one sided rekeys, whereas the handshake gets randomness in each
hello from each endpoint. It just strikes me as notably different to rely o= n
just the one source of entropy here (plus previous).

It's a "huh, interesting" thought not a "oh, that's = horrible" thought.

> > I would expect it would be better to not rely on implementations = all
> > designing their own heuristics on when to send rekey updates, and= also
> > would avoid multiple updates being sent at the same time by each = endpoint
> > (and the possible pitfalls of doing so)
>
> The algorithm in this document is intended to be safe in the case of b= oth
> simultaneous
> and (I believe) pipelined updates. I'd be interested in knowing if= it's not.

Yes, I don't think it's a spec risk. An implementation risk = is possible, though.

It's a new feature that could end up with a new setting for an admin to=
fiddle with that probably doesn't need to be highly variable to do the = job.
Or put another way, it's a feature that I'm overthinking about the = possibility
of implementations overthinking how to use it. ;)


Dave

--047d7b8750bed36e6005108fbfd7-- From nobody Thu Mar 5 12:22: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 A56B71A8A5F for ; Thu, 5 Mar 2015 12:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnfgAdTnaTxN for ; Thu, 5 Mar 2015 12:22:25 -0800 (PST) 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 790321A8A60 for ; Thu, 5 Mar 2015 12:22:19 -0800 (PST) Received: by qgdz60 with SMTP id z60so7672036qgd.1 for ; Thu, 05 Mar 2015 12:22:18 -0800 (PST) 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=8uGAgCk3EF8fUqyProWV3Z2cbsfS7QortH/Ix18BDUg=; b=uHcs8vwGaVfDWlINXLfHo5z9OkiQwu41fgIsq6RgEb1X1MlEZbWQneONUUf+uZCDmF ol2M5o5alqXYQfxTuMgqgNDUDklsXPFlRPzphGQ/Lb9gtxS/bwEDKiGfTweRx61BdL4h dWdFbx2KY2cQUcg2nYpVMhhCES2bP0BRDa+0BgHjyll+dPoAJwH8cq+lXC0RMzN7JmAJ ZBo5wpfdzpine7oNFlHssvH5zQ2vCe6NX1h5t3yNuENjdg1vcxsehzLBsvTFg2GQTLIK 1kuU43/oL9YigaLxjONgjc4OWeUFl1gwUqdfSvc5FCpUQogikBpqBOqMZtOHWnnCwDjL PiZw== X-Received: by 10.55.42.129 with SMTP id q1mr21812485qkq.54.1425586938782; Thu, 05 Mar 2015 12:22:18 -0800 (PST) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id i185sm4388370qhc.49.2015.03.05.12.22.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Mar 2015 12:22:18 -0800 (PST) From: Dave Garrett To: Eric Rescorla Date: Thu, 5 Mar 2015 15:22:15 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201502250009.08942.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503051522.15862.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Followup on Update X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:22:26 -0000 On Thursday, March 05, 2015 02:40:28 pm Eric Rescorla wrote: > On Tue, Feb 24, 2015 at 9:09 PM, Dave Garrett > wrote: > > On Tuesday, February 24, 2015 09:00:46 pm Eric Rescorla wrote: > > > On Tue, Feb 24, 2015 at 5:43 PM, Dave Garrett > > > wrote: > > > > On Tuesday, February 24, 2015 07:44:22 pm Eric Rescorla wrote: > > > > > [0] See https://github.com/tlswg/tls13-spec/pull/94 for a WIP > > > > > version of the basic mechanism. > > > > > > > > The current proposal says: > > > > > > > > "An implementation MAY send an UpdateRekey at any time after > > > > the handshake completes." > > > > > > > > Is there a particular reason to not just have an automatic rekey at > > > > semi-regular intervals? So, every N records or M minutes (or whichever > > > > comes first) an endpoint must send a rekey, and then after a similarly > > > > measured interval the other endpoint sends a rekey; repeat ad > > > > infinitum. > > > > > > It's not entirely clear that we know how to design a good heuristic here, > > > especially one that covers the entire range of possible algorithms. > > > > That's sort of my point; this proposal requires implementations to do so. > > I'm saying that picking one in the spec would be preferable to leaving it > > up to the whims of whatever the many combinations of implementations > > end up deciding. Even if some use-case needs to add rekeys, starting > > from a conservative heuristic in the spec would ensure implementations > > are provided with at least a general expectation of how to use this. > > I'm going to argue that the frequency of update is a semi-orthogonal issue. > I.e., if you think this mechanism works, then we can decide to put it in > and have a separate discussion of minimum update frequency. No objection. A baseline, minimum, and maximum frequency are all needed here, plus recommendations on why to diverge from baseline and what to do if limits are exceeded. A new fatal alert for passing limits sounds appropriate. Without ~something~ specific, however, this sounds like trouble. On a somewhat separate issue, I think there needs to be something indicating when an "ignored" ACK message is appropriate and how to deal with it properly at both endpoints. The gist of my concern is that this needs to all be spelled out very carefully with strong expectations. It needs to be very clear to prohibit rarely or never rekeying or a million rekeys in one second and with a specification on how to react to things. As many have pointed out, leaving things vague and up to implementations eventually causes problems that may never be fixed. Dave From nobody Thu Mar 5 16:03: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 A22491A9094 for ; Thu, 5 Mar 2015 16:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atTw8YyNWQ8L for ; Thu, 5 Mar 2015 16:03:06 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [74.52.223.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE0E1A884B for ; Thu, 5 Mar 2015 16:03:06 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id C7FB884A7D69A; Thu, 5 Mar 2015 18:03:05 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id B630784A7D668 for ; Thu, 5 Mar 2015 18:03:05 -0600 (CST) Received: from [96.231.226.227] (port=50969 helo=[192.168.1.8]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YTfjM-00045P-Uf; Thu, 05 Mar 2015 18:03:05 -0600 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Thu, 5 Mar 2015 19:03:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7409C148-11C7-491C-8606-2294236387A1@ieca.com> References: 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.226.227 X-Exim-ID: 1YTfjM-00045P-Uf X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [96.231.226.227]:50969 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Interim - update and agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 00:03:08 -0000 Stay tuned for webex details. spt On Mar 04, 2015, at 08:08, Yoav Nir wrote: > Will there be an audio stream or at least a recording? >=20 >> On Mar 4, 2015, at 2:06 AM, Joseph Salowey wrote: >>=20 >> If you are planning on attending the interim meeting and you have not = received an email from me about Logistics for TLS interim meeting then = you need to contact me so I know you are coming. >>=20 >> The agenda for the interim is available here:=20 >>=20 >> = http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-inter= im-2015-tls-1 >>=20 >> This is a working session so we will be making adjustments as needed. = =20 >>=20 >> Thanks, >>=20 >> Joe >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 5 19:37: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 4B9071AC402 for ; Thu, 5 Mar 2015 19:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucZIzMAVQoII for ; Thu, 5 Mar 2015 19:37:01 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::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 CBAAE1A8748 for ; Thu, 5 Mar 2015 19:37:00 -0800 (PST) Received: by qcwb13 with SMTP id b13so10257633qcw.12 for ; Thu, 05 Mar 2015 19:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FliFK91gJBJDJVi16vJ1Us+HqCm805macmLgwAPQkXQ=; b=s0AY9xylbjkTlz/qgS01HpN32oCZgqsRamIGDlv9c5RKqlc+AyELvwfSv6mdpThBbu zvOvX9vPsIHZgkfB7jH9Fsk1Bytpz7dZp+rdqOvSLvpzP1BAZDnIFA83XkZpm4tPoV+4 OJV9fCByHeHqNzn6AV5umKPfrMF3bhqmnUqa8yODytslHx3BeEcf6nAO0TxmSpqgPudz eeE3CgX56IKXse+hqrRD+oWlOLMZ0G9hoR7OfZGGucCMkurQFq9MclXDDM0R7sF6K6Vf AdR4TultD6beCDhiT71VFdbIqDdYxq6QXAeahwi8QBmF752lS1EPIWmuso7hrO/R8CJN K6zA== MIME-Version: 1.0 X-Received: by 10.140.43.199 with SMTP id e65mr16622092qga.34.1425613020128; Thu, 05 Mar 2015 19:37:00 -0800 (PST) Received: by 10.140.41.201 with HTTP; Thu, 5 Mar 2015 19:37:00 -0800 (PST) Date: Thu, 5 Mar 2015 19:37:00 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 03:37:03 -0000 Dear all, Consider https://www.smacktls.com/. It's clear that the implementors of TLS libraries attempt to minimize codesize by sharing code between various exchanges but in doing so often mis-implement the state machine. As we decide to further complicate, not simplify, the state machine in TLS 1.3, we should strongly consider making the description of the state machine more formal, and simplifying the flows: mo' code, mo' problems. The independence of the implementations suffering these problems demonstrates that it is the RFC which is at fault. One can only blame the coders so many times: once the same bug appears twice independently, it's probably specification issue. Sincerely, Watson Ladd From nobody Thu Mar 5 20:09: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 DEA051AC424 for ; Thu, 5 Mar 2015 20:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, 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 bzs0OD4oU2sQ for ; Thu, 5 Mar 2015 20:09:15 -0800 (PST) Received: from BLU004-OMC2S10.hotmail.com (blu004-omc2s10.hotmail.com [65.55.111.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AC51AC429 for ; Thu, 5 Mar 2015 20:09:14 -0800 (PST) Received: from BLU177-W34 ([65.55.111.71]) by BLU004-OMC2S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 5 Mar 2015 20:09:13 -0800 X-TMN: [VvZEIR0aKejRXpYtOtQ0KSQgJfC0mdA3] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Watson Ladd , "tls@ietf.org" Date: Thu, 5 Mar 2015 20:09:13 -0800 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Mar 2015 04:09:13.0913 (UTC) FILETIME=[4E638A90:01D057C3] Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 04:09:17 -0000 The fact that the Finished hash depended only on the master secret is also = part of the problem=2C to be honest.=0A= =0A= > Date: Thu=2C 5 Mar 2015 19:37:00 -0800=0A= > From: watsonbladd@gmail.com=0A= > To: tls@ietf.org=0A= > Subject: [TLS] While we're patching=0A= > =0A= > Dear all=2C=0A= > =0A= > Consider https://www.smacktls.com/. It's clear that the implementors=0A= > of TLS libraries attempt to minimize codesize by sharing code between=0A= > various exchanges but in doing so often mis-implement the state=0A= > machine. As we decide to further complicate=2C not simplify=2C the state= =0A= > machine in TLS 1.3=2C we should strongly consider making the description= =0A= > of the state machine more formal=2C and simplifying the flows: mo' code= =2C=0A= > mo' problems.=0A= > =0A= > The independence of the implementations suffering these problems=0A= > demonstrates that it is the RFC which is at fault. One can only blame=0A= > the coders so many times: once the same bug appears twice=0A= > independently=2C it's probably specification issue.=0A= > =0A= > Sincerely=2C=0A= > Watson Ladd=0A= > =0A= > _______________________________________________=0A= > TLS mailing list=0A= > TLS@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tls=0A= = From nobody Thu Mar 5 20:20: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 BE8E61AC431 for ; Thu, 5 Mar 2015 20:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYhtbwBHjED0 for ; Thu, 5 Mar 2015 20:20:49 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4C81AC42E for ; Thu, 5 Mar 2015 20:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1425615649; x=1457151649; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ieujY6M3ZtaWN1kHC/UUJV8BTyn8LSdWi4PGiw79ugM=; b=LcIahP5zfPjG2AizCwQW3gU9WPFbCAPFVKwX6bCoH5cHue0qVLFfYQsv Hid+m4uyulrVFPibeHZhkFPcMVy4gXz01e5uUw6FMyBfz8dgll/NQuO29 8yU5qRgckr5Srfje2WzzH0rRQ2Mau3qenA3+bItPk1p8Ksue5SR1jV6EK E=; X-IronPort-AV: E=Sophos;i="5.11,351,1422874800"; d="scan'208";a="311766515" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Mar 2015 17:20:47 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 6 Mar 2015 17:20:47 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] While we're patching Thread-Index: AdBXxOtLj4g5p+WdQE+UUevaTRbqHg== Date: Fri, 6 Mar 2015 04:20:46 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 04:20:53 -0000 Watson Ladd writes:=0A= =0A= >Consider https://www.smacktls.com/. It's clear that the implementors of TL= S =0A= >libraries attempt to minimize codesize by sharing code between various =0A= >exchanges but in doing so often mis-implement the state machine. As we =0A= >decide to further complicate, not simplify, the state machine in TLS 1.3, = =0A= >we should strongly consider making the description of the state machine = =0A= >more formal, and simplifying the flows: mo' code, mo' problems.=0A= =0A= The problem isn't that the state machine is too complex, it's that there's= =0A= a state machine at all. The SSL/TLS message flow is so clearly a ladder=0A= diagram that I've never understood how anyone could implement it as a state= =0A= machine. I never even tried to make my implementation a state machine,=0A= which would be why SKIP-TLS just bounced off it. Look at any security=0A= text that talks about TLS and it's always represented as a ladder diagram.= =0A= Heck, even the TLS RFC itself uses ladder diagrams to represent the=0A= mesage flow:=0A= =0A= Client Server=0A= =0A= ClientHello -------->=0A= ServerHello=0A= Certificate*=0A= ServerKeyExchange*=0A= CertificateRequest*=0A= <-------- ServerHelloDone=0A= Certificate*=0A= ClientKeyExchange=0A= CertificateVerify*=0A= [ChangeCipherSpec]=0A= Finished -------->=0A= [ChangeCipherSpec]=0A= <-------- Finished=0A= Application Data <-------> Application Data=0A= =0A= So the way to fix things isn't to do anything to the state machine, it's=0A= to document the protocol for what it actually is, a ladder diagram.=0A= =0A= Peter.= From nobody Thu Mar 5 20:36: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 574571AC433 for ; Thu, 5 Mar 2015 20:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA22W-Wg4Y1S for ; Thu, 5 Mar 2015 20:36:39 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::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 6D4C11A1AD9 for ; Thu, 5 Mar 2015 20:36:39 -0800 (PST) Received: by yhoc41 with SMTP id c41so11330905yho.13 for ; Thu, 05 Mar 2015 20:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TJC0qf6fFIFnTx6OOVY+5Pj5WDlDAWLFRaFNpC6f8OA=; b=eKd/IUCsw+vcu66zbFYeY/egW2tFJg4M0GnSdqugQMe/Kusf6mv6GqnqBfIhZViNgk 3KkBxO6cF6BLsxFomapITk+Fm3diarCetL3dq9PNgFqvEuGQE0y6nO06DyBdQgmTak/d zP7FxO6yEYjvIv4Eo7gg4G8Y5GRG1WmaboiB8nSnxFzBzXUn2vr0L6obqgMTt5AOEoJq cbI3KOcZWU4f82dvkxthBS707T3Y5gj/JrSpMnedbeOpvKnxTR4oqcIvNEcyBHU3h9Wd +Y89aWQWKI80amyKhR5xolhbT1/XK9XPXQTTPRoKHwQnbFhmuojldakytmecSkZ5lXwV /dAQ== MIME-Version: 1.0 X-Received: by 10.236.18.194 with SMTP id l42mr10786312yhl.172.1425616598685; Thu, 05 Mar 2015 20:36:38 -0800 (PST) Received: by 10.170.58.198 with HTTP; Thu, 5 Mar 2015 20:36:38 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 5 Mar 2015 20:36:38 -0800 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 04:36:41 -0000 On Thu, Mar 5, 2015 at 8:20 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>Consider https://www.smacktls.com/. It's clear that the implementors of TLS >>libraries attempt to minimize codesize by sharing code between various >>exchanges but in doing so often mis-implement the state machine. As we >>decide to further complicate, not simplify, the state machine in TLS 1.3, >>we should strongly consider making the description of the state machine >>more formal, and simplifying the flows: mo' code, mo' problems. > > The problem isn't that the state machine is too complex, it's that there's > a state machine at all. The SSL/TLS message flow is so clearly a ladder > diagram that I've never understood how anyone could implement it as a state > machine. I never even tried to make my implementation a state machine, > which would be why SKIP-TLS just bounced off it. Look at any security > text that talks about TLS and it's always represented as a ladder diagram. > Heck, even the TLS RFC itself uses ladder diagrams to represent the > mesage flow: > > Client Server > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > So the way to fix things isn't to do anything to the state machine, it's > to document the protocol for what it actually is, a ladder diagram. Just to clarify: Did you test SKIP-TLS against your implementation? Because it's not clear from the paper that IRINA did. Regardless of whether we call this a ladder diagram or state machine, the issue is that optional messages are actually required depending on what ciphersuite was selected. I don't see how this requirement goes away if a ladder diagram is used. (What is a ladder diagram anway? How does one implement it without writing a state machine?) In particular, accepting a Server Key Exchange when the negotiated cipher doesn't require one is exactly the FREAK attack: unless you condition accepting the Server Key Exchange on the selected cipher suite somehow you have the problem. Sincerely, Watson Ladd > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 5 21:12:43 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 8DB631AC43D for ; Thu, 5 Mar 2015 21:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILkVzsX9YOkC for ; Thu, 5 Mar 2015 21:12:39 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 02F391AC43C for ; Thu, 5 Mar 2015 21:12:39 -0800 (PST) Received: by lbvp9 with SMTP id p9so32407276lbv.8 for ; Thu, 05 Mar 2015 21:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XtvUE2GsT7bmO5gsY7C+J88Hx36ssnm7W4qLP4XWjF4=; b=AblWk54iitbCEAWn1cl7KorH5IgZRUluyP2Blp+LAzs4Qm3u/vNm/snAwiuvnGPfkR CW2cJEET3mR1M+kFYLcxxszhgG8ZVKgFGj82gunmewxAIMmnoedSpUl8SOI1gGjB5ffA NDFR9mtkIsZsIqRGU0NWGxeNzkPEvFElWfL7lfveMXtoTkPvX/kR3gHd/qPv5m03MM+y cs7W1TOpQxj1RGa2UZwGx32rU3D9nFzYVeTTy/AjTb56fxhbjzLSYvQMuTmDpCNJr2D0 IOOXovGyYXsu7nGKwWQWwqbNefl2JGIozNqTMZy4eMLRNy6yyaCAt8OGhAn16y0awthd 6bMw== MIME-Version: 1.0 X-Received: by 10.152.120.134 with SMTP id lc6mr10893926lab.72.1425618757423; Thu, 05 Mar 2015 21:12:37 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.55.241 with HTTP; Thu, 5 Mar 2015 21:12:37 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 5 Mar 2015 21:12:37 -0800 X-Google-Sender-Auth: dEBbBJaqITR1E0aDfb_-ngHcZZs Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 05:12:40 -0000 On Thu, Mar 5, 2015 at 8:36 PM, Watson Ladd wrote: > Regardless of whether we call this a ladder diagram or state machine, > the issue is that optional messages are actually required depending on > what ciphersuite was selected. I don't see how this requirement goes > away if a ladder diagram is used. (What is a ladder diagram anway? How > does one implement it without writing a state machine?) I'm also not quite sure that I understand what Peter meant, but it seems that his thinking might be similar to mine: TLS's messages should have encompassed entire flows, except where switching cipherspecs requires splitting them. I.e. the ServerHello, Certificate, SKX etc should all have been one message. It's possible to implement it like this, but the presentation in the RFC has very often lead to software designs that involve a state machine. After processing each handshake message, all the state is serialised back into structures, the next message is read and the state machine is run again, at which point it needs to pull the state back out of structures. The constant marshaling of state is hard and makes the code hard to understand. This has lead to numerous bugs in stacks that I'm aware off (most of which don't have names). Rather, if the whole flow were available at once then the code could be very much simpler. (And it is available if one structures the code like that but, again, the RFC style leads implementators in the wrong direction.) (This is why QUIC's handshake has one message per flow, except when starting encryption requires two.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 5 22:00: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 48B1B1ACC8B for ; Thu, 5 Mar 2015 22:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os8_TwlYD22w for ; Thu, 5 Mar 2015 22:00:33 -0800 (PST) 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 CF6E71AC442 for ; Thu, 5 Mar 2015 22:00:32 -0800 (PST) Received: by wibhm9 with SMTP id hm9so1062782wib.2 for ; Thu, 05 Mar 2015 22:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AwBa+dT24c6AAlAmSG8EH33DcQdwqb1pITcCYHdJgcY=; b=kekgan7+q8yXOk6OMAVogA+aWnYLNL0QeCJzy72xaoHBzqy/TH3725xP3sEJvnCFrn tsxnezXuMsLqp3fBrYDcI7zKo5GmWMMEcG0iM2yDPD93i4Wyy36ah57RBKCEpnRcwbPe tjCSz++V0nHN//sIufcy8kqBHslaaqucVekEiOrM2tluwaLExLXvFiztff2irf9atB+u h8P4MhZKRZTDFTQxQ4S3EVAKqkIrQWn05LOVZPDC/SMpy0iUCx2BjTU81UhtQ+g1mNGZ zwq0G1bP9bWbdEURglkixD2xF12Ls8wslSFTFj4iqyT1WoCdStBILNalIw4JuHrkjhR4 tpIw== X-Received: by 10.180.74.15 with SMTP id p15mr72303954wiv.63.1425621631686; Thu, 05 Mar 2015 22:00:31 -0800 (PST) Received: from [192.168.1.44] (162.92.69.86.rev.sfr.net. [86.69.92.162]) by mx.google.com with ESMTPSA id fs8sm730304wib.8.2015.03.05.22.00.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 22:00:30 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E0FD48-2100-40E3-9170-A7E4C46FAA5A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 6 Mar 2015 07:00:27 +0100 Message-Id: <2FCEF459-9E4B-43B6-8122-853BC37FE35C@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 06:00:36 -0000 --Apple-Mail=_E6E0FD48-2100-40E3-9170-A7E4C46FAA5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Did you test SKIP-TLS against your implementation? Because it's not > clear from the paper that IRINA did. Hi, We were surprised by the number of TLS implementations out there, and = didn=92t have the resources to test them all. We mainly looked at a few open source = implementations, but the pattern of attacks we found should be more general. Our plan is to release our FlexTLS recipes for our client/server tests = (SKIP+FREAK) so everyone can test their implementations. For clients, we will = probably provide a test server to try out. When looking at a number of implementations, we roughly saw the = following patterns. I am going to use the word state machine in the following, but you can = read it as =93protocol engine=94 or =93top-level client/server function=94: - Branching on state vs. branching on incoming message Some libraries look at the current state first and then require the = incoming message to have a certain shape. These generally do better (have fewer bugs) than = implementations that look at the incoming message and then try to fit them with the = current protocol state.=20 - Same or different state machines for client and server Libraries that use the same state machine for client and server have = to jump through lots of hoops to discover what state they are in, and this leads to = bugs and crashes. - Interleaving CCS vs Handshake vs Application Data Libraries that treat CCS just as a handshake message tend not to = forget it. Those that treat CCS specially forget to check it was received, or = when it was received. Similar problems lurk in the interleaving of Application Data and = handshake messages. The informal observations above (of course, it is possible to code TLS = correctly in all these styles!) go against software engineering principles a bit. For example, they = suggest that we shouldn=92t share=20 code for processing the =93Certificate=94 message between client and = server. They also suggest that we shouldn=92t cleanly separate the Record = layer=92s ContentType-based=20 dispatch from the Handshake state-machine. Perhaps most significantly, they suggest that in TLS, both peers should = at all times know exactly what type of message to expect next. Perhaps this is what is = meant by a ladder diagram? When a server receives a ClientHello, it should know the full shape of = the upcoming handshake, and the same goes for a client after the ServerHello.=20 Best, Karthik >=20 > Regardless of whether we call this a ladder diagram or state machine, > the issue is that optional messages are actually required depending on > what ciphersuite was selected. I don't see how this requirement goes > away if a ladder diagram is used. (What is a ladder diagram anway? How > does one implement it without writing a state machine?) In > particular, accepting a Server Key Exchange when the negotiated cipher > doesn't require one is exactly the FREAK attack: unless you condition > accepting the Server Key Exchange on the selected cipher suite somehow > you have the problem. >=20 > Sincerely, > Watson Ladd >=20 >>=20 >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_E6E0FD48-2100-40E3-9170-A7E4C46FAA5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Did you test SKIP-TLS against your = implementation? Because it's not
clear from the paper that IRINA = did.

Hi,

We were surprised by the number of TLS implementations out there, = and didn=92t have the
resources to test them all. We mainly = looked at a few open source implementations, but
the pattern = of attacks we found should be more = general.

Our plan is to release our = FlexTLS recipes for our client/server tests (SKIP+FREAK)
so = everyone can test their implementations. For clients, we will probably = provide
a test server to try = out.

When looking at a number of = implementations, we roughly saw the following patterns.
I am = going to use the word state machine in the following, but you can read = it as =93protocol engine=94
or =93top-level client/server = function=94:

- Branching on state vs. branching = on incoming message
  Some libraries look at the current = state first and then require the incoming message to
  = have a certain shape. These generally do better (have fewer bugs) than = implementations
  that look at the incoming message and = then try to fit them with the current protocol = state. 

- Same or different state machines = for client and server
  Libraries that use the same state = machine for client and server have to jump through
  lots = of hoops to discover what state they are in, and this leads to bugs and = crashes.

- Interleaving CCS vs Handshake vs = Application Data
  Libraries that treat CCS just as a = handshake message tend not to forget it.
  Those that = treat CCS specially forget to check it was received, or when it was = received.
  Similar problems lurk in the interleaving of = Application Data and handshake messages.

The = informal observations above (of course, it is possible to code TLS = correctly in all these styles!)
go against software = engineering principles a bit. For example, they suggest that we = shouldn=92t share 
code for processing the =93Certificate=94= message between client and server.
They also suggest that we = shouldn=92t cleanly separate the Record layer=92s = ContentType-based 
dispatch from the Handshake = state-machine.

Perhaps most significantly, they = suggest that in TLS, both peers should at all times = know
exactly what type of message to expect next. Perhaps this = is what is meant by a ladder diagram?
When a server receives a = ClientHello, it should know the full shape of the upcoming = handshake,
and the same goes for a client after the = ServerHello. 

Best,
Karthik
<= div>





Regardless of whether we call = this a ladder diagram or state machine,
the issue is that optional = messages are actually required depending on
what ciphersuite was = selected. I don't see how this requirement goes
away if a ladder = diagram is used. (What is a ladder diagram anway? How
does one = implement it without writing a state machine?)  In
particular, = accepting a Server Key Exchange when the negotiated cipher
doesn't = require one is exactly the FREAK attack: unless you = condition
accepting the Server Key Exchange on the selected cipher = suite somehow
you have the problem.

Sincerely,
Watson = Ladd


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



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

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

= --Apple-Mail=_E6E0FD48-2100-40E3-9170-A7E4C46FAA5A-- From nobody Fri Mar 6 01:27: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 307AF1A0338 for ; Fri, 6 Mar 2015 01:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKOmJNmdY-09 for ; Fri, 6 Mar 2015 01:27:49 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309D71ACD42 for ; Fri, 6 Mar 2015 01:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1425634070; x=1457170070; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=QsHLBnPFEdxR+d3PFnLVimBsdLGxSJ+wjkavg4rOcVU=; b=gg3yxjU2AX/JdaXvh75+T8kIhWRkHSOfQ9qpRbtSHculCOsrTnX1pUuT iwzfqhnF/X1G2RxU7XE+PMp/eqLOtW28WwIS7HQfsYbnwlBrKUJkaUD2q x2bGYVdJCeqE3wARd3SSDAeq3oYEG2kxu1wpLn9vz3M6AFDq5Buq3pR8I o=; X-IronPort-AV: E=Sophos;i="5.11,351,1422874800"; d="scan'208";a="311804022" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Mar 2015 22:27:46 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 6 Mar 2015 22:27:45 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] While we're patching Thread-Index: AdBX74UUD5TQKh+RS16dXjY2y11ivA== Date: Fri, 6 Mar 2015 09:27:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFA87A5@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 09:27:54 -0000 Watson Ladd writes:=0A= =0A= >Did you test SKIP-TLS against your implementation? Because it's not clear= =0A= >from the paper that IRINA did.=0A= =0A= Yes, but I'm not sure if the test was conclusive:=0A= =0A= -- Snip --=0A= =0A= Testing TLS 1.0 session...=0A= Remote host: https://ht.vc:6443.=0A= Attempt to activate TLS 1.0 session failed with error code -25, line 1141.= =0A= Error message =3D 'Timeout on read (select()) after 30 seconds'.=0A= =0A= -- Snip --=0A= =0A= Mind you it's enough to get Firefox, it's been sitting there for nearly ten= =0A= minutes now with the spinner whirling endlessly, so you don't even need to = try=0A= attacking the TLS implementation on that one.=0A= =0A= >I don't see how this requirement goes away if a ladder diagram is used. (W= hat=0A= >is a ladder diagram anway? How does one implement it without writing a sta= te=0A= >machine?)=0A= =0A= My implementation is:=0A= =0A= Expect A;=0A= Send B;=0A= Expect C;=0A= Send D;=0A= if( A.option )=0A= Expect E1;=0A= else=0A= Expect E2;=0A= Send F;=0A= =0A= which is quite different from:=0A= =0A= while( TRUE )=0A= Get something;=0A= See what it is;=0A= Set state to some-state;=0A= =0A= Actually TLS is pretty straightforward to do as a ladder diagram, if you wa= nt=0A= to see a really hellish protocol to get right I'd look at SSH, which not on= ly=0A= allows arbitrary iterations of several messages but breaks what should be a= =0A= single message down into lots of little bits and pieces and sends them all= =0A= individually, with other messages coming back in between. If SKIP-TLS was= =0A= bad, I'd hate to see what SKIP-SSH (or UNEXPECTED-MESSAGE-ORDER-SSH, or=0A= ENDLESS-LOOP-SSH, or several other possibilities) would do.=0A= =0A= Peter.= From nobody Fri Mar 6 02:14: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 F2A231A1A0F for ; Fri, 6 Mar 2015 02:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Lpc6ptBPoKi for ; Fri, 6 Mar 2015 02:14:44 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 33B421A00B6 for ; Fri, 6 Mar 2015 02:14:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425636881; l=1307; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=1cA90KmsNkrIhJI+JVCWTRt1A0DpvQh62bTPa2Sjky4=; b=sQwnw9WE2LDKGg1nNuIW09Msgbn7t9NRIdoCbM53EkzS8rfngRvwNAVG0AOXm7YNWMy u7cVt/jGILJ3ADGloNFifFg1wWJKMvlIftm+fv3XwHmHxo80/WgMP2Hxkm8fhxidyFcF1 fD1diVKS5tMOno+Elrbu6xrGlQJr4vQ/QAs= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzQWXmxx9E/e9N9qQgcHv4bTIl7 X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:a5f3:45fb:7757:b51] ([2001:4dd0:ff67:0:a5f3:45fb:7757:b51]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPSA id 206caar26AEfQjG (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Fri, 6 Mar 2015 11:14:41 +0100 (CET) Message-ID: <54F97E11.4030008@zinks.de> Date: Fri, 06 Mar 2015 11:14:41 +0100 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAFA87A5@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFA87A5@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:14:46 -0000 On 06.03.2015 10:27, Peter Gutmann wrote: > > My implementation is: > > Expect A; > Send B; > Expect C; > Send D; > if( A.option ) > Expect E1; > else > Expect E2; > Send F; > > which is quite different from: > > while( TRUE ) > Get something; > See what it is; > Set state to some-state; > > There are many ways to implement something. In our implementation a state machine compiler was used. Basically you do write something like expect A Send B in it by writing for a state a a => (do b, go c). The compiler then ensures that when in state a some other event happens than A there will be a failure. The expect A seems to imply a synchronous threaded implementation. When you go to asynchronous single threaded then you may end up with something like a state machine, e.g. you are in a state where you expect A and store this state somewhere. I don't think the specification should say something how it is implemented. It should only clearly state what message sequences are allowed and which are forbidden. If optional messages are required in some cases then this must clearly be specified. If a formal state machine can be given then this is fine (but may turn out to be complicated). Otherwise text may be enough to state what is required. Regards, Roland From nobody Fri Mar 6 06:09: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 92B031ACE17 for ; Fri, 6 Mar 2015 06:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmkX_7_74TzI for ; Fri, 6 Mar 2015 06:09:28 -0800 (PST) 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 147241ACDF2 for ; Fri, 6 Mar 2015 06:09:27 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id EF2BF6997D; Fri, 6 Mar 2015 16:09:25 +0200 (EET) Date: Fri, 6 Mar 2015 16:09:25 +0200 From: Ilari Liusvaara To: Adam Langley Message-ID: <20150306140925.GA3059@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:09:31 -0000 On Thu, Mar 05, 2015 at 09:12:37PM -0800, Adam Langley wrote: > On Thu, Mar 5, 2015 at 8:36 PM, Watson Ladd wrote: > > Regardless of whether we call this a ladder diagram or state machine, > > the issue is that optional messages are actually required depending on > > what ciphersuite was selected. I don't see how this requirement goes > > away if a ladder diagram is used. (What is a ladder diagram anway? How > > does one implement it without writing a state machine?) > > I'm also not quite sure that I understand what Peter meant, but it > seems that his thinking might be similar to mine: > > TLS's messages should have encompassed entire flows, except where > switching cipherspecs requires splitting them. I.e. the ServerHello, > Certificate, SKX etc should all have been one message. Looking at TLS 1.3 flows, the unencrypted flights should all fit into one record each (as long as neither endpoint is doing anything ridiculous). In fact, in most cases those should fit even into one IP packet each (doesn't really matter for TLS, since TCP hides the IP packet boundaries). The encrypted flights might not fit into TLS record, because both contain certificate chains, which can be quite large. Also, if one wants to ensure proper sequencing on state level (and I consider it dangerous not to), the handshake can't actually restart (the initial and post-restart states are distinct). > Rather, if the whole flow were available at once then the code could > be very much simpler. (And it is available if one structures the code > like that but, again, the RFC style leads implementators in the wrong > direction.) Also, it occurs to me that there is duplication between ciphersuite and message types. Except for some optional messages (like EncryptedExtensions and CertificateRequest), the sequence of messages is determined by ciphersuite. Thus most message type info is duplicated information, which is infamous source of (security) bugs. Also, there is possiblity of omitted messages. E.g. omit Certificate or include Certificate but omit Certificate Verify. The problem is that neither is really optional, those two are dependent on the ciphersuite (except for resume). I recently tried to construct state machine model for TLS 1.3. I discovered that CertificateRequest adds many new states (this is because of the way it changes messages and rekeying behaviour). On high level, the TLS 1.3 1RTT/2RTT flow looks pretty decent to me (although there are problems). Since 0RTT flow seems pretty much handwaving as of currently, I can't say anything about it, except note that getting that kind of thing right might be pretty difficult. The simplicity is not measured with the simplest implmentation that works, it is measured with the simplest implementation that is _secure_. And having large gap between the two is extremely bad, since it guarantees security holes in practice. Bugs that result in things failing visibly in operation (incorrect key derivations, deadlocks, etc...) tend to be fixed MUCH faster than bugs that result in things failing insecure in invisible ways. Also, it is not just TLS protocol and TLS implementation security bugs... There are also bugs from misuse of TLS (which can be pretty subtle). -Ilari From nobody Fri Mar 6 09:25: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 9903F1A0137 for ; Fri, 6 Mar 2015 09:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vWPaD467JOFj for ; Fri, 6 Mar 2015 09:25:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2B91A0092 for ; Fri, 6 Mar 2015 09:24:55 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 17:24:54 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 17:24:53 +0000 From: Andrei Popov To: Karthikeyan Bhargavan , Watson Ladd Thread-Topic: [TLS] While we're patching Thread-Index: AdBXxOtLHg0M9ah7YEiMDw6sGgvZdAAAjcMAAALtYYAAF6TUsA== Date: Fri, 6 Mar 2015 17:24:53 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> <2FCEF459-9E4B-43B6-8122-853BC37FE35C@gmail.com> In-Reply-To: <2FCEF459-9E4B-43B6-8122-853BC37FE35C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(377454003)(19617315012)(2900100001)(33656002)(76176999)(92566002)(62966003)(2950100001)(102836002)(76576001)(74316001)(86362001)(15975445007)(86612001)(16236675004)(2656002)(19300405004)(87936001)(19609705001)(19580395003)(46102003)(50986999)(122556002)(19625215002)(54356999)(99286002)(77156002)(40100003)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BN3PR0301MB1251; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 05079D8470 Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB125052068A3964E0DC971DAE8C1C0BN3PR0301MB1250_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 17:24:53.8459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251 Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:25:17 -0000 --_000_BN3PR0301MB125052068A3964E0DC971DAE8C1C0BN3PR0301MB1250_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Exactly how the code is structured in a particular implementation may be a = factor, but I think bigger issues that lead to bugs like this are: 1. Protocol complexity: multiple message flows are possible, dependin= g on negotiated parameters. Unfortunately, this will get even worse with TL= S 1.3 support added to existing implementations. 2. The fact that implementations tend to disable weak crypto by defau= lt, but keep the code around forever. Had we removed EXPORT cipher code yea= rs ago, we wouldn't have the issue now. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Karthikeyan Bhargavan Sent: Thursday, March 5, 2015 10:00 PM To: Watson Ladd Cc: Subject: Re: [TLS] While we're patching Did you test SKIP-TLS against your implementation? Because it's not clear from the paper that IRINA did. Hi, We were surprised by the number of TLS implementations out there, and didn'= t have the resources to test them all. We mainly looked at a few open source implement= ations, but the pattern of attacks we found should be more general. Our plan is to release our FlexTLS recipes for our client/server tests (SKI= P+FREAK) so everyone can test their implementations. For clients, we will probably p= rovide a test server to try out. When looking at a number of implementations, we roughly saw the following p= atterns. I am going to use the word state machine in the following, but you can read= it as "protocol engine" or "top-level client/server function": - Branching on state vs. branching on incoming message Some libraries look at the current state first and then require the incom= ing message to have a certain shape. These generally do better (have fewer bugs) than im= plementations that look at the incoming message and then try to fit them with the curre= nt protocol state. - Same or different state machines for client and server Libraries that use the same state machine for client and server have to j= ump through lots of hoops to discover what state they are in, and this leads to bugs = and crashes. - Interleaving CCS vs Handshake vs Application Data Libraries that treat CCS just as a handshake message tend not to forget i= t. Those that treat CCS specially forget to check it was received, or when i= t was received. Similar problems lurk in the interleaving of Application Data and handsha= ke messages. The informal observations above (of course, it is possible to code TLS corr= ectly in all these styles!) go against software engineering principles a bit. For example, they suggest= that we shouldn't share code for processing the "Certificate" message between client and server. They also suggest that we shouldn't cleanly separate the Record layer's Con= tentType-based dispatch from the Handshake state-machine. Perhaps most significantly, they suggest that in TLS, both peers should at = all times know exactly what type of message to expect next. Perhaps this is what is meant = by a ladder diagram? When a server receives a ClientHello, it should know the full shape of the = upcoming handshake, and the same goes for a client after the ServerHello. Best, Karthik Regardless of whether we call this a ladder diagram or state machine, the issue is that optional messages are actually required depending on what ciphersuite was selected. I don't see how this requirement goes away if a ladder diagram is used. (What is a ladder diagram anway? How does one implement it without writing a state machine?) In particular, accepting a Server Key Exchange when the negotiated cipher doesn't require one is exactly the FREAK attack: unless you condition accepting the Server Key Exchange on the selected cipher suite somehow you have the problem. Sincerely, Watson Ladd Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_BN3PR0301MB125052068A3964E0DC971DAE8C1C0BN3PR0301MB1250_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Exactly how the code is structured in= a particular implementation may be a factor, but I think bigger issues tha= t lead to bugs like this are:

1.   = ;    Protocol complexity: multiple= message flows are possible, depending on negotiated parameters. Unfortunat= ely, this will get even worse with TLS 1.3 support added to existing implementations.

2.   = ;    The fact that implementations= tend to disable weak crypto by default, but keep the code around forever. = Had we removed EXPORT cipher code years ago, we wouldn’t have the issue now.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of Karthikeyan Bhargavan
Sent: Thursday, March 5, 2015 10:00 PM
To: Watson Ladd
Cc: <tls@ietf.org>
Subject: Re: [TLS] While we're patching

 

Did you test SKIP-TL= S against your implementation? Because it's not
clear from the paper that IRINA did.

 

Hi,

 

We were surprised by the number of TLS implementatio= ns out there, and didn’t have the

resources to test them all. We mainly looked at a fe= w open source implementations, but

the pattern of attacks we found should be more gener= al.

 

Our plan is to release our FlexTLS recipes for our c= lient/server tests (SKIP+FREAK)

so everyone can test their implementations. For clie= nts, we will probably provide

a test server to try out.

 

When looking at a number of implementations, we roug= hly saw the following patterns.

I am going to use the word state machine in the foll= owing, but you can read it as “protocol engine”

or “top-level client/server function”:

 

- Branching on state vs. branching on incoming messa= ge

  Some libraries look at the current state firs= t and then require the incoming message to

  have a certain shape. These generally do bett= er (have fewer bugs) than implementations

  that look at the incoming message and then tr= y to fit them with the current protocol state. 

 

- Same or different state machines for client and se= rver

  Libraries that use the same state machine for= client and server have to jump through

  lots of hoops to discover what state they are= in, and this leads to bugs and crashes.

 

- Interleaving CCS vs Handshake vs Application Data<= o:p>

  Libraries that treat CCS just as a handshake = message tend not to forget it.

  Those that treat CCS specially forget to chec= k it was received, or when it was received.

  Similar problems lurk in the interleaving of = Application Data and handshake messages.

 

The informal observations above (of course, it is po= ssible to code TLS correctly in all these styles!)

go against software engineering principles a bit. Fo= r example, they suggest that we shouldn’t share 

code for processing the “Certificate” me= ssage between client and server.

They also suggest that we shouldn’t cleanly se= parate the Record layer’s ContentType-based 

dispatch from the Handshake state-machine.

 

Perhaps most significantly, they suggest that in TLS= , both peers should at all times know

exactly what type of message to expect next. Perhaps= this is what is meant by a ladder diagram?

When a server receives a ClientHello, it should know= the full shape of the upcoming handshake,

and the same goes for a client after the ServerHello= . 

 

Best,

Karthik

 

 

 

 




Regardless of whether we call this a ladder diagram or state machine,
the issue is that optional messages are actually required depending on
what ciphersuite was selected. I don't see how this requirement goes
away if a ladder diagram is used. (What is a ladder diagram anway? How
does one implement it without writing a state machine?)  In
particular, accepting a Server Key Exchange when the negotiated cipher
doesn't require one is exactly the FREAK attack: unless you condition
accepting the Server Key Exchange on the selected cipher suite somehow
you have the problem.

Sincerely,
Watson Ladd



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




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

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

 

--_000_BN3PR0301MB125052068A3964E0DC971DAE8C1C0BN3PR0301MB1250_-- From nobody Fri Mar 6 09:38: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 095E81A0149 for ; Fri, 6 Mar 2015 09:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UUkovSrH2hg for ; Fri, 6 Mar 2015 09:38:33 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (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 E793B1A03A5 for ; Fri, 6 Mar 2015 09:38:30 -0800 (PST) Received: by qcxr5 with SMTP id r5so52251140qcx.13 for ; Fri, 06 Mar 2015 09:38:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7s6c87eutP78NofjXpGtckwUoq6X5vpz6NHiegKLz5M=; b=kLfC5QI5NUU4F1qd7e6tMk+GX0lUKZZiVIqCpOEPg8TA80LDsQWLo+c28SVqMKh+9V m1SNjenbZwEI0ckuusr4CNfXPSLWVF/jbGxv9awauEfFJ7uNDWLowpwLWsorxLaNbVhd BJEpj9L/Ds+JInEkCwadVfLWol3lQZtgddg2nn6OUc/yfFnpLO3xBlSEVIJpE/fR4HJn ikxYaFG+u8O1/Eaw8ll6OvbqpHR/wIh4ueu9DPVOV4uIkaDHBvLH4opA+6L+AHN7agg2 yiJsfYpPyPI83Tb+TvZzx7MClh4XUIEAhQK1kq7FbTLw6EsvtDlZ64TGgqWW7ZOM5jdx 5huw== X-Gm-Message-State: ALoCoQme56tH9WB0bEsU9JL0z2Pj4J69fXmxniYBqlM4CACnlhKxfDuMwPEoAYv+gkgTWAlGV/ak X-Received: by 10.55.25.38 with SMTP id k38mr27516739qkh.48.1425663510200; Fri, 06 Mar 2015 09:38:30 -0800 (PST) Received: from ?IPv6:2601:a:2a00:381:9891:7ff3:a57c:9d06? ([2601:a:2a00:381:9891:7ff3:a57c:9d06]) by mx.google.com with ESMTPSA id e14sm5037920qka.31.2015.03.06.09.38.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 09:38:29 -0800 (PST) Message-ID: <54F9E61A.1040508@nthpermutation.com> Date: Fri, 06 Mar 2015 12:38:34 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:38:35 -0000 On 3/5/2015 11:36 PM, Watson Ladd wrote: > Regardless of whether we call this a ladder diagram or state machine, > the issue is that optional messages are actually required depending on > what ciphersuite was selected. I don't see how this requirement goes > away if a ladder diagram is used. (What is a ladder diagram anway? How > does one implement it without writing a state machine?) In > particular, accepting a Server Key Exchange when the negotiated cipher > doesn't require one is exactly the FREAK attack: unless you condition > accepting the Server Key Exchange on the selected cipher suite somehow > you have the problem. > I think there are actually 6 state machines running for TLS as far as I can tell: client and server version each of parameter negotiation, key negotiation and authentication. And there are many variants on these based on how many older versions of TLS you support. Peter's comment that this is a ladder diagram is really a distinction without a difference. (And I think Adam's note about serialization is really a good explanation of the ladder diagram). The ladder diagram *might* correctly describe the time order of the messages (e.g. with no exceptions and a well behaved server); the state diagram - if done properly - should give you insight into what those messages actually mean and why they're important at this time and for this recipient. Mostly its possible to convert one of these to another - albeit with occasional information loss. In my own protocol designs I used to use the UML based state diagram almost exclusively, but it fails miserably when trying to diagram exceptions. I've started to use UML to describe the normal path as an overview, but I've transition to using SDL (Z.100 series - sigh) for anything more complex than a state diagram for a traffic light. UML is transition based - SDL is state based. The SDL state machine can be decomposed down to a single diagram per state each of which describes possible transitions from that state and allows the use of If/then/else and case logic to mix in other variables besides simple message or timer based transitions. The other nice thing is there are equivalent graphic and text representations. In any event, we've got the ladder diagrams and I don't think they're going away anytime soon. Until the RFCs can incorporate better diagrams than ASCII art, I think moving to a state diagram is off the table. Mike From nobody Fri Mar 6 09:58: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 AD4511A00DC for ; Fri, 6 Mar 2015 09:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 F0PIdDI3O7EO for ; Fri, 6 Mar 2015 09:58:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209161A0137 for ; Fri, 6 Mar 2015 09:58:13 -0800 (PST) Received: from BL2FFO11FD045.protection.gbl (10.173.160.31) by BL2FFO11HUB041.protection.gbl (10.173.161.57) with Microsoft SMTP Server (TLS) id 15.1.99.6; Fri, 6 Mar 2015 17:57:56 +0000 Received: from mx01.five9.com (198.105.204.2) by BL2FFO11FD045.mail.protection.outlook.com (10.173.161.207) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Fri, 6 Mar 2015 17:57:56 +0000 Received: from MB02.five9.com (10.7.8.142) by mx01.five9.com (10.7.15.111) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 09:57:21 -0800 Received: from MB03.five9.com ([fe80::4d18:3a9c:2936:eea8]) by mb02.five9.com ([fe80::ede6:8312:5207:4046%16]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 09:57:54 -0800 From: Ronald del Rosario To: Andrei Popov , Karthikeyan Bhargavan , Watson Ladd Thread-Topic: [TLS] While we're patching Thread-Index: AdBXxOtLTOor04dr30KWyt126BFLLwARUUsAAALtYoAAF+dPgP//gxSA Date: Fri, 6 Mar 2015 17:57:54 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> <2FCEF459-9E4B-43B6-8122-853BC37FE35C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.7.8.130] Content-Type: multipart/alternative; boundary="_000_D11F2A651E15Frrosariofive9com_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 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; Authentication-Results: spf=pass (sender IP is 198.105.204.2) smtp.mailfrom=rrosario@five9.com; gmail.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:198.105.204.2; CTRY:US; IPV:NLI; EFV:NLI; BMV:0; SFV:NSPM; SFS:(10019020)(438002)(199003)(377454003)(189002)(584604001)(106466001)(93886004)(77156002)(83506001)(512944002)(5890100001)(19617315012)(92566002)(84326002)(30436002)(16236675004)(46102003)(62966003)(54356999)(50986999)(4546004)(53416004)(19580405001)(6806004)(15975445007)(2950100001)(2900100001)(102836002)(2421001)(2656002)(86362001)(2561002)(5250100002)(87936001)(76176999)(19580395003)(19625215002)(36756003)(1511001)(7099025)(85436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB041; H:mx01.five9.com; FPR:; SPF:Pass; MLV:ovrnspm; A:1; MX:1; PTR:mx01.five9.com; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB041; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:BL2FFO11HUB041; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB041; X-Forefront-PRVS: 05079D8470 X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2015 17:57:56.1829 (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] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB041 Archived-At: Cc: "" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:58:18 -0000 --_000_D11F2A651E15Frrosariofive9com_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =3D=3D=3D Exactly how the code is structured in a particular implementation may be a = factor, but I think bigger issues that lead to bugs like this are: 1. Protocol complexity: multiple message flows are possible, dependin= g on negotiated parameters. Unfortunately, this will get even worse with TL= S 1.3 support added to existing implementations. 2. The fact that implementations tend to disable weak crypto by defau= lt, but keep the code around forever. Had we removed EXPORT cipher code yea= rs ago, we wouldn=92t have the issue now. +1 Cheers, Andrei =3D=3D=3D My thoughts exactly. Ron From: Andrei Popov > Date: Friday, March 6, 2015 at 9:24 AM To: Karthikeyan Bhargavan >, Watson Ladd > Cc: ">" > Subject: Re: [TLS] While we're patching Exactly how the code is structured in a particular implementation may be a = factor, but I think bigger issues that lead to bugs like this are: 1. Protocol complexity: multiple message flows are possible, dependin= g on negotiated parameters. Unfortunately, this will get even worse with TL= S 1.3 support added to existing implementations. 2. The fact that implementations tend to disable weak crypto by defau= lt, but keep the code around forever. Had we removed EXPORT cipher code yea= rs ago, we wouldn=92t have the issue now. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Karthikeyan Bhargavan Sent: Thursday, March 5, 2015 10:00 PM To: Watson Ladd Cc: > Subject: Re: [TLS] While we're patching Did you test SKIP-TLS against your implementation? Because it's not clear from the paper that IRINA did. Hi, We were surprised by the number of TLS implementations out there, and didn= =92t have the resources to test them all. We mainly looked at a few open source implement= ations, but the pattern of attacks we found should be more general. Our plan is to release our FlexTLS recipes for our client/server tests (SKI= P+FREAK) so everyone can test their implementations. For clients, we will probably p= rovide a test server to try out. When looking at a number of implementations, we roughly saw the following p= atterns. I am going to use the word state machine in the following, but you can read= it as =93protocol engine=94 or =93top-level client/server function=94: - Branching on state vs. branching on incoming message Some libraries look at the current state first and then require the incom= ing message to have a certain shape. These generally do better (have fewer bugs) than im= plementations that look at the incoming message and then try to fit them with the curre= nt protocol state. - Same or different state machines for client and server Libraries that use the same state machine for client and server have to j= ump through lots of hoops to discover what state they are in, and this leads to bugs = and crashes. - Interleaving CCS vs Handshake vs Application Data Libraries that treat CCS just as a handshake message tend not to forget i= t. Those that treat CCS specially forget to check it was received, or when i= t was received. Similar problems lurk in the interleaving of Application Data and handsha= ke messages. The informal observations above (of course, it is possible to code TLS corr= ectly in all these styles!) go against software engineering principles a bit. For example, they suggest= that we shouldn=92t share code for processing the =93Certificate=94 message between client and server= . They also suggest that we shouldn=92t cleanly separate the Record layer=92s= ContentType-based dispatch from the Handshake state-machine. Perhaps most significantly, they suggest that in TLS, both peers should at = all times know exactly what type of message to expect next. Perhaps this is what is meant = by a ladder diagram? When a server receives a ClientHello, it should know the full shape of the = upcoming handshake, and the same goes for a client after the ServerHello. Best, Karthik Regardless of whether we call this a ladder diagram or state machine, the issue is that optional messages are actually required depending on what ciphersuite was selected. I don't see how this requirement goes away if a ladder diagram is used. (What is a ladder diagram anway? How does one implement it without writing a state machine?) In particular, accepting a Server Key Exchange when the negotiated cipher doesn't require one is exactly the FREAK attack: unless you condition accepting the Server Key Exchange on the selected cipher suite somehow you have the problem. Sincerely, Watson Ladd Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ________________________________ 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_D11F2A651E15Frrosariofive9com_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

=3D=3D=3D


Exactly how the code is structured in a= particular implementation may be a factor, but I think bigger issues that = lead to bugs like this are:

1= .  &= nbsp;    Protocol complexity: multiple message flows are possible, depending on negotiated p= arameters. Unfortunately, this will get even worse with TLS 1.3 support add= ed to existing implementations.

2.       The fact that implementations tend to disable weak crypto by default, but keep= the code around forever. Had we removed EXPORT cipher code years ago, we w= ouldn=92t have the issue now. +1

 

Cheers,

 

Andrei

 

=3D=3D=3D

My thoughts exactly.

Ron

From: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Friday, March 6, 2015 at 9:24= AM
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com&g= t;, Watson Ladd <watsonbladd@gm= ail.com>
Cc: "<tls@ietf.org>" <t= ls@ietf.org>
Subject: Re: [TLS] While we're patc= hing

Exactly how the code is structured in a pa= rticular implementation may be a factor, but I think bigger issues that lea= d to bugs like this are:

1.       Protocol complexity: multiple message flows = are possible, depending on negotiated parameters. Unfortunately, this will = get even worse with TLS 1.3 support added to existing implementations.

2.       The fact that implementations tend to disabl= e weak crypto by default, but keep the code around forever. Had we removed = EXPORT cipher code years ago, we wouldn=92t have the issue now.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-= bounces@ietf.org] On Behalf Of Karthikeyan Bhargavan
Sent: Thursday, March 5, 2015 10:00 PM
To: Watson Ladd
Cc: <tls@ietf.org>
Subject: Re: [TLS] While we're patching

 

Did you test SKIP-TL= S against your implementation? Because it's not
clear from the paper that IRINA did.

 

Hi,

 

We were surprised by the number of TLS implementatio= ns out there, and didn=92t have the

resources to test them all. We mainly looked at a fe= w open source implementations, but

the pattern of attacks we found should be more gener= al.

 

Our plan is to release our FlexTLS recipes for our c= lient/server tests (SKIP+FREAK)

so everyone can test their implementations. For clie= nts, we will probably provide

a test server to try out.

 

When looking at a number of implementations, we roug= hly saw the following patterns.

I am going to use the word state machine in the foll= owing, but you can read it as =93protocol engine=94

or =93top-level client/server function=94:

 

- Branching on state vs. branching on incoming messa= ge

  Some libraries look at the current state firs= t and then require the incoming message to

  have a certain shape. These generally do bett= er (have fewer bugs) than implementations

  that look at the incoming message and then tr= y to fit them with the current protocol state. 

 

- Same or different state machines for client and se= rver

  Libraries that use the same state machine for= client and server have to jump through

  lots of hoops to discover what state they are= in, and this leads to bugs and crashes.

 

- Interleaving CCS vs Handshake vs Application Data<= /p>

  Libraries that treat CCS just as a handshake = message tend not to forget it.

  Those that treat CCS specially forget to chec= k it was received, or when it was received.

  Similar problems lurk in the interleaving of = Application Data and handshake messages.

 

The informal observations above (of course, it is po= ssible to code TLS correctly in all these styles!)

go against software engineering principles a bit. Fo= r example, they suggest that we shouldn=92t share 

code for processing the =93Certificate=94 message be= tween client and server.

They also suggest that we shouldn=92t cleanly separa= te the Record layer=92s ContentType-based 

dispatch from the Handshake state-machine.

 

Perhaps most significantly, they suggest that in TLS= , both peers should at all times know

exactly what type of message to expect next. Perhaps= this is what is meant by a ladder diagram?

When a server receives a ClientHello, it should know= the full shape of the upcoming handshake,

and the same goes for a client after the ServerHello= . 

 

Best,

Karthik

 

 

 

 




Regardless of whether we call this a ladder diagram or state machine,
the issue is that optional messages are actually required depending on
what ciphersuite was selected. I don't see how this requirement goes
away if a ladder diagram is used. (What is a ladder diagram anway? How
does one implement it without writing a state machine?)  In
particular, accepting a Server Key Exchange when the negotiated cipher
doesn't require one is exactly the FREAK attack: unless you condition
accepting the Server Key Exchange on the selected cipher suite somehow
you have the problem.

Sincerely,
Watson Ladd



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




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

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

 



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_D11F2A651E15Frrosariofive9com_-- From nobody Fri Mar 6 10:12: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 B45C91A09C9 for ; Fri, 6 Mar 2015 10:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLnjtKIsE3oG for ; Fri, 6 Mar 2015 10:12:14 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 006B91A0151 for ; Fri, 6 Mar 2015 10:12:13 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t26ICCNi071431 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Mar 2015 11:12:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <54F9E61A.1040508@nthpermutation.com> Date: Fri, 6 Mar 2015 10:12:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> <54F9E61A.1040508@nthpermutation.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:12:14 -0000 On Mar 6, 2015, at 9:38 AM, Michael StJohns = wrote: > Until the RFCs can incorporate better diagrams than ASCII art, I think = moving to a state diagram is off the table. If a WG wants to have non-ASCII art for things like better diagrams, = they can do so *today* with external references. This has already been = done by at least one other WG. I can describe this more fully if needed, = but if the WG thinks that one of our documents would be significantly = better with real art instead of ASCII art, just do it. --Paul Hoffman= From nobody Fri Mar 6 10:55: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 719031A1B6D for ; Fri, 6 Mar 2015 10:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHmMOswbYCyP for ; Fri, 6 Mar 2015 10:55:01 -0800 (PST) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (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 1B3EB1A1BDF for ; Fri, 6 Mar 2015 10:55:01 -0800 (PST) Received: by qgfh3 with SMTP id h3so14852694qgf.13 for ; Fri, 06 Mar 2015 10:55:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SqqC1QlcCsXLdaUidRhGWOcXr4gAsrIaGAfU3RWMkvk=; b=alL5AQ4T5MdJiBw+4Rw68mTzvj+zUgZm8PryxwTDcTRbl7vSxyV7F33y18qBD60LUy kDwGcrlu1V3HkezYgq+p0QEQw3ANyBOefRIdDdSTw/BGYheuI3zmRGV0k3ar8xv0mhIv IG9K6ybcVd35XeAsZaAA6FHYKIJ1baTFeslgKZXDzLHW2+feJ/+1EUpcIwvhsLa9M2Xb zdSjSwNAx0uzwANZGxLvfjZJ7Ks5tGPL3iir4ScV1GqhcEnupr9hJ/l/t54DqcyOS39m QTI+kawRkW/GNwJCSeXV+QfFZ3scl2r48xXefpXhsV6r2Dm1aTBOBrZNR/RUv7aO7bQS GIMQ== X-Gm-Message-State: ALoCoQnKN5iHHzlP4Y7F4IsFe1Wju9OcDpgeBu+TSh5h8Gv/+nWAF3RHUNxCHBXR5I9U2Q1xwauR MIME-Version: 1.0 X-Received: by 10.55.31.71 with SMTP id f68mr26403974qkf.7.1425668100292; Fri, 06 Mar 2015 10:55:00 -0800 (PST) Received: by 10.96.121.104 with HTTP; Fri, 6 Mar 2015 10:55:00 -0800 (PST) X-Originating-IP: [50.206.82.175] In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> <54F9E61A.1040508@nthpermutation.com> Date: Fri, 6 Mar 2015 10:55:00 -0800 Message-ID: From: Joseph Salowey To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a114782dcaf9e4c0510a338f8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:55:03 -0000 --001a114782dcaf9e4c0510a338f8 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 6, 2015 at 10:12 AM, Paul Hoffman wrote: > On Mar 6, 2015, at 9:38 AM, Michael StJohns > wrote: > > Until the RFCs can incorporate better diagrams than ASCII art, I think > moving to a state diagram is off the table. > > If a WG wants to have non-ASCII art for things like better diagrams, they > can do so *today* with external references. This has already been done by > at least one other WG. I can describe this more fully if needed, but if the > WG thinks that one of our documents would be significantly better with real > art instead of ASCII art, just do it. > > [Joe] +1 There are several examples of this including an EAP state mahttp:// tools.ietf.org/pdf/rfc4137.pdf. ASCII format should not stand in the way of providing better documentation for analysis. > --Paul Hoffman > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114782dcaf9e4c0510a338f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 6, 2015 at 10:12 AM, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:
On Mar 6, 201= 5, at 9:38 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> Until the RFCs can incorporate better diagrams than ASCII art, I think= moving to a state diagram is off the table.

If a WG wants to have non-ASCII art for things like better diagrams,= they can do so *today* with external references. This has already been don= e by at least one other WG. I can describe this more fully if needed, but i= f the WG thinks that one of our documents would be significantly better wit= h real art instead of ASCII art, just do it.


[Joe] +1

There are several exampl= es of this including an EAP state mahttp://tools.ietf.org/pdf/rfc4137.pdf.=C2=A0 ASCII format sh= ould not stand in the way of providing better documentation for analysis.

=C2=A0
--Paul Hoffman
___________________________= ____________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a114782dcaf9e4c0510a338f8-- From nobody Fri Mar 6 11:11: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 AEC861A3BA6 for ; Fri, 6 Mar 2015 11:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLAuFkFcEJ5q for ; Fri, 6 Mar 2015 11:11:50 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::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 092091A3BA7 for ; Fri, 6 Mar 2015 11:11:47 -0800 (PST) Received: by yhzz6 with SMTP id z6so9583743yhz.3 for ; Fri, 06 Mar 2015 11:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4CE9+MdWeDonfxbUD3a+azsm7C8lzliA6UyyCRUZ/KQ=; b=Nyh5wpDLIR77KLwh9mpBENzgVJttCzbBCId9NyrCvlBTB2C3fyM0kNWnhL5V3rV8xJ jGNdmm8Npq0Q2b96iuPeQBaOL5z8K9TIevuH81S8b+u/8Amjv++4atDVJuqzwOp3RI8s vT0Kdn+RMVIkWie9svyGBTGzbWYS7RQLFS5r4bkmECYU0UFJb+sMIXCDXZC473IdRep5 cGVUby0yZpnRb7v/PtZM7pqOjzkRZYQ6axSWJtmXX5UBFDXlJJCVJJSboo+bXSrYsRx5 0NNT0zKx2n4LagRJ9dmTYTDFJXrEFwkOcC63vuRERoI9lNHU62QACpfmlmMsEKe/CX+V 0RUw== MIME-Version: 1.0 X-Received: by 10.236.63.6 with SMTP id z6mr14236409yhc.65.1425669106323; Fri, 06 Mar 2015 11:11:46 -0800 (PST) Received: by 10.170.58.198 with HTTP; Fri, 6 Mar 2015 11:11:45 -0800 (PST) Received: by 10.170.58.198 with HTTP; Fri, 6 Mar 2015 11:11:45 -0800 (PST) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73AAF98127@uxcn10-5.UoA.auckland.ac.nz> <54F9E61A.1040508@nthpermutation.com> Date: Fri, 6 Mar 2015 11:11:45 -0800 Message-ID: From: Watson Ladd To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01294ff0a657af0510a374d5 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:11:54 -0000 --089e01294ff0a657af0510a374d5 Content-Type: text/plain; charset=UTF-8 On Mar 6, 2015 10:12 AM, "Paul Hoffman" wrote: > > On Mar 6, 2015, at 9:38 AM, Michael StJohns wrote: > > Until the RFCs can incorporate better diagrams than ASCII art, I think moving to a state diagram is off the table. > > If a WG wants to have non-ASCII art for things like better diagrams, they can do so *today* with external references. This has already been done by at least one other WG. I can describe this more fully if needed, but if the WG thinks that one of our documents would be significantly better with real art instead of ASCII art, just do it. A state machine can always be specified by a set of states and transition functions. That can be done in text. Notice how TCP does this, with an ASCII art result worthy of the Pope's ceiling. Part of the issue is that the TLS spec splits all sorts of details off into extensions in very undisciplined ways. Many of the bugs result from hooking into the state machine in ways that original authors didn't expect, and not being explicit about forbidden transitions. The gap between spec and code is too large. Sincerely, Watson Ladd > > --Paul Hoffman > _______________________________________________ > TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --089e01294ff0a657af0510a374d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 6, 2015 10:12 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> On Mar 6, 2015, at 9:38 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> > Until the RFCs can incorporate better diagrams than ASCII art, I = think moving to a state diagram is off the table.
>
> If a WG wants to have non-ASCII art for things like better diagrams, t= hey can do so *today* with external references. This has already been done = by at least one other WG. I can describe this more fully if needed, but if = the WG thinks that one of our documents would be significantly better with = real art instead of ASCII art, just do it.

A state machine can always be specified by a set of states a= nd transition functions. That can be done in text. Notice how TCP does this= , with an ASCII art result worthy of the Pope's ceiling.

Part of the issue is that the TLS spec splits all sorts of d= etails off into extensions in very undisciplined ways. Many of the bugs res= ult from hooking into the state machine in ways that original authors didn&= #39;t expect, and not being explicit about forbidden transitions. The gap b= etween spec and code is too large.

Sincerely,
Watson Ladd

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

--089e01294ff0a657af0510a374d5-- From nobody Fri Mar 6 16:28:45 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 B95D51ACE44; Wed, 4 Mar 2015 12:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVld_GinK0Qy; Wed, 4 Mar 2015 12:15:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2761ACE4B; Wed, 4 Mar 2015 12:15:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "spt" , "Joseph Salowey" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304201503.5794.96931.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 12:15:03 -0800 Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 16:28:45 -0800 Cc: Kathleen Moriarty , Christian.Groves@nteczone.com, Transport Layer Security Discussion List Subject: [TLS] =?utf-8?q?New_Liaison_Statement=2C_=22LS/r_on_TLS_and_DTLS_?= =?utf-8?q?terminology_=E2=80=93_Follow-up_comments_and_further_questions_?= =?utf-8?q?for_clarification_=28Ref=3A_IETF_No=2E_1379=29_=5Bto_IETF=2C_3G?= =?utf-8?q?PP=5D=22?= 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: Wed, 04 Mar 2015 20:15:09 -0000 Title: LS/r on TLS and DTLS terminology – Follow-up comments and further questions for clarification (Ref: IETF No. 1379) [to IETF, 3GPP] Submission Date: 2015-03-04 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1381/ Please reply by 2015-06-08 From: ITU-T Q3/16 (Christian Groves ) To: Transport Layer Security (spt , Joseph Salowey ) Cc: Stephen Farrell ,Kathleen Moriarty ,Transport Layer Security Discussion List Response Contact: Christian.Groves@nteczone.com Technical Contact: Purpose: For action Body: ITU-T Q3/16 thanks you for your reply on our LS request (IETF No. 1379, our TD284/Gen). We would like to summarize our understanding by providing definitions and indicating some follow-up questions, which are related to (D)TLS protocol handling from the perspective of a decomposed gateway. The text in italics relates to your reply. Follow-up questions are inserted: Thanks for your questions about (D)TLS. What follows is a response to your questions; questions proceeded by Q# and answers by A#. If you have additional question please let us know. Q1. [What is] the distinction between (D)TLS session and (D)TLS connection (which implies a definition for each term, beyond the available descriptions / glossary from RFC side). A1. A TLS session is shared cryptographic state established by a full TLS handshake between two peers. The session's cryptographic state is used to establish the cryptographic key material for a TLS connection. A TLS connection is a transport relationship established between two peers that contains the cryptographic state to cryptographically protect data sent and received on the connection established through a full or abbreviated (session resumption) TLS handshake. A TLS session may span one or more TLS connections. Every TLS connection is associated with one TLS session. If session resumption (abbreviated handshake) is not used then the TLS session and TLS connection will essentially be the same. A TLS session is identified by a Session ID in the client and server hellos. A TLS connection is usually identified by a host addresses and port numbers. Reply 1 (ITU-T): a) TLS session: Thus, there is a "TLS session cryptographic state" object, which is shared by the two TLS session endpoints at client and server side. In our understanding the TLS client session endpoint state and the TLS server session endpoint state information largely overlaps (i.e., identical parameter-value pairs), but there is one additional parameter (the "server address") at client side. Is this correct? Our understanding is that based on your description above "resumable TLS session" could be defined as follows Resumable TLS session: The pair of a resumable TLS client session endpoint state and a resumable TLS server session endpoint state, coupled by the TLS full handshake procedure which was executed across the associated TLS connection. b) TLS connection: the TLS connection endpoints at client and server side could be described by a n-tuple if the TLS connection represents a "transport relationship" according to your description. c) TLS connection identifier: the following definition could be established based on your explanation ("A TLS connection is usually identified by a host addresses and port numbers"): TLS connection endpoint identifier: The local IP transport address and indication of "TLS/L4" protocol stack, i.e., the 4-tuple of {AL, PL, T, "TLS"} from the TLS connection endpoint. NOTE 1 – Parameter "L4" is required because TLS is a L4 independent protocol. d) Ratio between TLS session to TLS connection: there is a ratio of 1:N. e) TLS session resumption: according to your explanation, resumption is a) correlated with an abbreviated handshake and b) affecting the TLS connection, hence we might define: TLS session resumption: A TLS session level concept which represents the execution of a TLS abbreviated handshake procedure on an existing TLS session, i.e., a semi-permanent TLS session, for the purpose of either deriving a further TLS connection or updating of an existing TLS connection. Q2. The DTLS association concept, e.g., is it equivalent to a DTLS session or DTLS connection or something in addition? A2. The DTLS association is the same as a DTLS connection Reply 2 (ITU-T): Thanks for confirmation. We had the same interpretation based on the TLS related RFCs. Q3. The TLS renegotiation procedure: what is the definition and at which level (TLS session or TLS connection level) does this procedure occur? Q4. The TLS resumption procedure: what is the definition and relation to TLS renegotiation? A3 and A4: Resumption refers to the use of the state from an existing TLS session to establish a new TLS connection using an abbreviated handshake. During resumption the cryptographic parameters (algorithms etc.) remain the same. TLS renegotiation is the process of executing a new TLS handshake to establish new cryptographic parameters for a TLS connection (effectively a new TLS connection using the same host addresses and ports as the previous one). If the handshake is a full handshake then both a new session and a new connection are established and the renegotiated session may have different parameters. Please note that session resumption and renegotiation are optional features; though TLS 1.2 recommended support for renegotiation; renegotiation was also updated by RFC 5746. Please note that TLS 1.3 is currently under development and these features are being reviewed. Reply 3/4 (ITU-T): In order to emphasize the difference between TLS session resumption and TLS session renegotiation, we would summarize your description as follows: TLS session renegotiation: A TLS session level concept which leads, - by the execution of a TLS handshake procedure (full or abbreviated) -, to the update of TLS protocol status information of an already established TLS connection, for the purpose of the establishment of new cryptographic parameters. Could you please confirm or clarify our understanding? Q3/16 is appreciative for your cooperation. Attachments: LS/r on TLS and DTLS terminology – Follow-up comments and further questions for clarification (Ref: IETF No. 1379) [to IETF, 3GPP] https://datatracker.ietf.org/documents/LIAISON/liaison-2015-03-04-itu-t-q3-16-tls-lsr-on-tls-and-dtls-terminology-follow-up-comments-and-further-questions-for-clarification-ref-ietf-no-1379-attachment-1.pdf From nobody Sun Mar 8 07:01: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 5398C1A8712 for ; Sun, 8 Mar 2015 07:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wioj1e8PvrrL for ; Sun, 8 Mar 2015 07:01:22 -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 E4E5F1A8711 for ; Sun, 8 Mar 2015 07:01:20 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 7AF9F4050; Sun, 8 Mar 2015 16:01:18 +0200 (EET) Date: Sun, 8 Mar 2015 16:01:17 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150308140117.GA7643@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] While we're patching X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 14:01:24 -0000 On Thu, Mar 05, 2015 at 07:37:00PM -0800, Watson Ladd wrote: > Dear all, > > Consider https://www.smacktls.com/. It's clear that the implementors > of TLS libraries attempt to minimize codesize by sharing code between > various exchanges but in doing so often mis-implement the state > machine. As we decide to further complicate, not simplify, the state > machine in TLS 1.3, we should strongly consider making the description > of the state machine more formal, and simplifying the flows: mo' code, > mo' problems. Goal: Remove as much redundancy as possible, since redumdancy is _infamous_ source of (security) bugs[1]. Idea: Make all handshake message types implicit[2], forcing implementations to do the right thing and track message types properly (obviously no message can be optional afterwards, but situation-dependent messages are possible). Also, instead of restarting the handshake (turns out this won't work as well as initially seems) just have client send exchange blob (with no group identifier, since the correct one was already sent). This will also narrow the gap between minimal workign and minimal secure complexity (and seemingly not increase actual complexity)[3]. Potential downside is handling extensions (especially if multiple are used at once) that want to send their own messages (besides just the two extension negotiation blobs). [1] It is also the cause of the SMACK-like bugs found in _multiple_ TLS stacks. [2] For backwards compatiblity ClientHello has to have 1 where the type field goes and ServerHello has to have 2 where the type goes. [3] Difference between minimum working complexity and minimum secure complexity should be as small as possible, since it is another name for implementation pitfalls, and have that be big enough and a lot of implementations WILL (not may) fall into those (this has been shown plenty of times already). -Ilari From nobody Sun Mar 8 10:39: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 016241A0060 for ; Sun, 8 Mar 2015 10:39:53 -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 h7oJ2cwwRC9g for ; Sun, 8 Mar 2015 10:39:50 -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 1D5DD1A005B for ; Sun, 8 Mar 2015 10:39:50 -0700 (PDT) Received: by qgea108 with SMTP id a108so23651335qge.8 for ; Sun, 08 Mar 2015 10:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:user-agent:mime-version:to:content-type :content-transfer-encoding:message-id; bh=ovE5nl8i1PNGCoSw1lbpsiHhEmCzrrKqYyA+CqrC3/o=; b=cGyW7N8oihhAasghH5qnuuRVnnrYYrVfX+isSu5KrnHk0HJpPWdf1MX5iaND0FGgLJ D4swWdN3Qo/ZriaX8SiZJ6vMatbWFjCCfzMaN+M6b/th4+sESL6BmXadaaBejiju76au DawqEA6bju399oVl6bbaRJ3eZqjCFpUwx7EsWy+OqriC0pCOZaZThnK1QjaJPmigicEh Uj0Vm7YV7X0I2pwgwkvt8jkM1bTRSUC3cFgYmkDhME/WRCZFLUCqJFPaDSyjoLTCvgb1 eIlgXxmqSeo5qgT7liCbBCBq98/vjnlqzPeTOYmPtOatmSiIiP1o7kI5mZGjWMROXncG huFg== X-Received: by 10.140.147.131 with SMTP id 125mr32036374qht.81.1425836389354; Sun, 08 Mar 2015 10:39:49 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 38sm9955194qgt.43.2015.03.08.10.39.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Mar 2015 10:39:48 -0700 (PDT) From: Dave Garrett Date: Sun, 8 Mar 2015 12:39:47 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 To: "tls@ietf.org" , Eric Rescorla Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201503081339.47927.davemgarrett@gmail.com> Archived-At: Subject: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 17:39:53 -0000 A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+. It'll be needed to handle draft implementations, if desired, and I think it might just be wanted for all negotiation. TLS 1.3 version intolerance is currently surveyed to be in the ~1.5% range [1]. The simplest method is to do so via a new mandatory extension, as has been suggested by people before. Here's a straightforward outline to get the ball rolling. Versions would be negotiated with a new "Extended TLS Version Negotiation" extension with the following contents: struct { uint8 versions<0..2^8-1>; } SupportedVersions; where versions contains an ordered list of the supported TLS minor versions. A block of numbers would be reserved for draft versions. (e.g. ID 32+ for drafts) ClientHello would include the extension with its supported versions list. IFF a server receives the extension, then it would include its corresponding set in its ServerHello. (if no version is negotiated, this would make error reporting/diagnosis much better) The ServerHello.version would still be set to the version picked by the server, now the highest supported version from the client's set that the server supports. The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2. Clients could set this to {0,0} to force only the new mechanism with no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are all undesirable). The set of valid values for this field would be limited to exactly 5. Additionally, I propose dropping the TLSCiphertext.version field entirely. (needs PR #51 [2] or similar; PR #51 primarily proposes encrypting ContentType, also a good idea) It's a waste of 2 bytes per record. TLSPlaintext.version would have to stay for backwards compatibility (see PR #51). Version handling would be restricted to just the hellos. Why? 1) Too many implementations botched the existing version negotiation mechanism. This one requires nothing new for existing implementations to handle. (transparent fallback to TLS 1.2) 2) This method allows for non-continuous version support to be negotiated. (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4) 3) Draft implementations would be easily negotiable using the same method as release. (HTTP/2 benefited from widespread testing of drafts; doing so here could be helpful too) 4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+. 5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment. 6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not supported. Why not? 1) Kinda ugly to freeze a hello field and hack in a new negotiation method. 2) Some people don't like advertising all supported versions openly. (TLS 1.0-1.2 could be left out of the list to force only old implementations to consider them) 3) Failing to connect to the broken ~1.5% of servers that can't negotiate correctly is the "Right Thing To Do". 4) A few extra bytes in the hello messages. (though, far fewer overall if record layer is changed as proposed) I would prefer to get PR #107 [4] committed prior to a brand new mechanism, if possible. [1] http://www.ietf.org/mail-archive/web/tls/current/msg15141.html [2] https://github.com/tlswg/tls13-spec/pull/51 [3] http://www.ietf.org/mail-archive/web/tls/current/msg15391.html [4] https://github.com/tlswg/tls13-spec/pull/107 Comments? Dave From nobody Sun Mar 8 11:03: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 778901A0097 for ; Sun, 8 Mar 2015 11:03:15 -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_50=0.8, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sDhALOveYYR for ; Sun, 8 Mar 2015 11:03:13 -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 AC1A91A0087 for ; Sun, 8 Mar 2015 11:03:12 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 6033869968 for ; Sun, 8 Mar 2015 20:03:10 +0200 (EET) Date: Sun, 8 Mar 2015 20:03:10 +0200 From: Ilari Liusvaara To: "tls@ietf.org" Message-ID: <20150308180310.GA10911@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: Subject: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 18:03:15 -0000 On Tue, Mar 03, 2015 at 04:06:22PM -0800, Joseph Salowey wrote: > > The agenda for the interim is available here: > > http://www.ietf.org/proceedings/interim/2015/03/10/tls/agenda/agenda-interim-2015-tls-1 Since I won't be participating, here are some comments and thoughts about items on the agenda: Backwards compatibility: ------------------------ Is this about what is needed for compatiblity with past TLS versions? If so, the things that I think need preserving are: - ClientHello record header, message header and overall format. - ClientHello being the only mandatory message in its flight. - ServerHello record header, message header and version field (first two bytes). - Signature TBS must not cause undesirable interactions with signature TBS in past versions. - The first byte of record header needs to remain subprotocol id (for muxing TLS with other stuff) - If finished messages get removed or changed to be just markers, deriving replacement TLS-unique value. - Having drop-in replacement for TLS-Extractor. The first three are about downnegotiation being possible without delay, the fourth is about cross-protocol interactions, and the last three are about application compatiblity. Other than theses, I don't see much backwards compat concerns. In practicular, the handshake changes tend to screw everything that isn't aware of TLS 1.3 but tries to interpret it. Or is this about dealing with the 1%+ TLS 1.3 intolerance? 0-RTT: ------ Although basic 0-RTT is essentially just strapping AEAD cipher to IES (asymmetric encryption using DHFs) using parameters preprovisioned by the server (or just plain AEAD if resuming), there are more subtle things: - Can replay protection be realistically provoded? - If replay protection can't be provoded, authenticating the early data is just plain dangerous. - Authentication here is very easy to get wrong, even if one somehow gets replay protection. - Even without authentication, this could be useful for protocol banner exchange, speeding up protocol startup (and replaying protocol banners does not seem to be useful for attackers). Tickets/Resumption/PSK: ----------------------- - Tickets or resumption should not compomise FS (by storing MS). - Can resumption be ratcheded even for re-resumptions (so re-resumption doesn't put resumed sessions at risk)? - Tying resumption to PSK might cause issues with PSK identity selection. - PSK identity selection can require 2RTT in some cases supported by TLS 1.2 (plus new messages and changes to messages). - PSK adds a fair chunk of complexity. OPTLS: ------ OPTLS can be viewed as two-level key scheme. The usual benefits of two-level key schemes: 1) Potential for speed enhancement by quickly rotating weaker keys (weaker crypto is usually faster). 2) Better isolation of higher key. 3) Allowing quick rotation of lower key. The drawbacks are that now one has a key that can sign quite damaging things, and this mechanism increases complexity (by having second certificate mechanism that works in different way). However, the higher-level key might be more protectable than sole key (it may be possible to apply more checks). If attacker just steals the higher key, you are as screwed as currently. As for revocation of lower key, it should be noted that in present WebPKI, realistic revocation times are a day or two. Of course, trying to push validity period down, one runs into issues with clock skew (no secure time protocol!). Also, if one tries to enhance performance, OPTLS inherently ties the lower key strength with encryption strength, so if one uses weak key, the encryption will also be weak (encryption strength and strength of upper key are decoupled like with sole keys, in contrast to the usual myth). Also, I am not seeing solid peformance advantages (without HECC, which currently is not usable). In short, the worst downsides I see are: - Extra complexity - Revocation/expiry of lower-level keys. - More things to potentially go wrong in development. - Does not seem to provode solid peformance advantages. Update/Rekey: ------------- Rekeying needs to be stateless, so not to cause too much extra complexity to TLS stacks and especially to applications. In practicular, this means: - Simultaneous rekeys are handled properly. - ACKs can be delayed by an arbitrary amount (since no extra flights can be added). - Rekey must not cause race conditions with TLS-Extractor. Authentiation via update is very hairy due to application-level issues it can cause (even if restricted to happen only once per connection). Key hierarchy/derivation: ------------------------- - Handshake master secret [hMS] - Application CtS master secret [cMS] (derives from hMS) - Application StC master secret [sMS] (derives from hMS) - Extractor master secret [eMS] (derives from hMS) - Resumption Premaster Secret [rPMS] (derives from hMS) The earliest possible points of derivation (any earlier runs into known problems): - hMS: After Hellos&Shares - cMS: After Hellos&Shares - sMS: After Hellos&Shares - eMS: After EncryptedExtensions - rPMS: After entiere handshake However, it might be better to derive cMS and sMS at respective finished messages (or placeholders thereof), since that is just before messages with those keys should start appearing (any earlier is an error). Signature format/orthogonal negotiation: ---------------------------------------- Is orthogonal negoiation about decoupling encryption, key exchange and signatures from each other? If so, recently I have heard of quite nasty comments about inability of TLS to do that (these choices seem independent enough, to avoid the "chinese menu problems"). Regarding signature format, isn't the current rule that the key specifies the signature format (and then there is capability advertisment)? Any reason that doesn't still work? OHOH, CFRG might come up with some new signature format (e.g. something based on EdDSA), should prepare for that. I think the changes to add new signature format are: - Codepoint for signature negotiation - Format identifier for signature+hash combo (OID in case of X.509 or RPK). MTI cipher suites: ------------------ I see there being only two realistic AEAD ciphers: - AES-GCM (if you have hardware support) - Chacha20-Poly1305-AEAD (no need for hardware support) Regarding key exchanges: ECDHE: * NIST curves available (but violate crypto best practices) * Brainpool curves available (but are slow) * CFRG curves are not yet available (missing details, but I would be surprised if one isn't Curve25519 as-is) DHE: * Very slow. Scales badly. Regarding signatures: ECDSA: * Quite crappy (behind the times even when invented, for apparently classified reasons). RSA: * Slow to sign. Scales badly. : * Not yet. -Ilari From nobody Sun Mar 8 11:24: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 337C91A00B6 for ; Sun, 8 Mar 2015 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI1gCdsCUgzy for ; Sun, 8 Mar 2015 11:24:27 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::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 F07521A00B5 for ; Sun, 8 Mar 2015 11:24:26 -0700 (PDT) Received: by qcvp6 with SMTP id p6so338465qcv.5 for ; Sun, 08 Mar 2015 11:24:26 -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=Hx3LANKaRqu4rhmkFsBpL/53iicnije8cR2wJ1BRUyM=; b=DCPmWpjPBZtb2LTdeJwRD2D9dCAka1WpvVX581+XGB+8rJG9DWJLZFGpCPufhhuU4e +dcOIX1pSekQ4riI42O6Ea9DO2VvPUeXxv6V4BFwX1nAhKif0Fs0vTsf8Fs4dweypMOJ Awxb5SDNc0TRagmp+4A2oE01lHrWsICns9FODu+IQTjynFS1SE5Btfk0ho45OHfTYlGm VOgsXZnkTqVSvlSU9IFn402H3kB0wwIZLA43LrF0FV28vZxGF+Ko99YOG2di8fuO/jRc Eo4XygZq7UrO4ZjD7mDVXt+gGFsLNxxBv3MVk44ZK/+wrAw3o/rH8f8WHY+wIEK73ked IxEw== X-Received: by 10.140.98.146 with SMTP id o18mr30059244qge.70.1425839066282; Sun, 08 Mar 2015 11:24:26 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id p46sm10023838qgd.22.2015.03.08.11.24.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Mar 2015 11:24:25 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 8 Mar 2015 14:24:24 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <20150308180310.GA10911@LK-Perkele-VII> In-Reply-To: <20150308180310.GA10911@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503081424.24976.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 18:24:28 -0000 On Sunday, March 08, 2015 02:03:10 pm Ilari Liusvaara wrote: > MTI cipher suites: > ------------------ > I see there being only two realistic AEAD ciphers: > > - AES-GCM (if you have hardware support) > - Chacha20-Poly1305-AEAD (no need for hardware support) On this topic, a thought to consider: If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly increase roll-out of the new cipher. AES-GCM could be listed as SHOULD support. Existing TLS 1.2 implementations generally support it already, so this would most likely provide two cipher suites that most can be expected to have available. On the other hand, if AES-GCM were chosen as MTI, then we would have to rely on merely encouraging implementations to consider alternatives. Dave From nobody Sun Mar 8 11:36: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 ECD971A00CA for ; Sun, 8 Mar 2015 11:36: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 zCwkHkyPTsuh for ; Sun, 8 Mar 2015 11:36:56 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.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 730781A00C7 for ; Sun, 8 Mar 2015 11:36:56 -0700 (PDT) Received: by wevl61 with SMTP id l61so4638578wev.10 for ; Sun, 08 Mar 2015 11:36:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EuGAq5NadhYcWBO7xeEGJgas48DjyIoR/NWq+4Rpi/w=; b=gJLfXwau+aU5/h2xxAs0ot/a0xGA1N65rJOnFU+O2tohcRo9fqIdjMeErnqASFxfq5 bcNr4ys06NudnC0detnbwJe5pLVw8ZG1tk34RM3O3qB72tt0Cs7jiDFaFq8M0YGQ6EzX ZbLJwfHvGLTlSCPcgDv/wlO/1eCIFE6sDb8NUIuZ31w6tnQzFXch1HDEZTmlDiJFPDzS 2Sxm/fE6fudsu1BeBgIX49aeSpzY11fNH8lm1NLQEKdl6141xQIL5ONIPRwVLxB1x/gE d1rA3ennQVkJUr++uqy+QvVeHf5kKXPxk0twbTO7TZrHw6zjG15xNCBAB0MpyVKzD5w1 L8EQ== X-Gm-Message-State: ALoCoQmHwVVq8sjrdVnlW2WXwne+vQTZB6NoML6nNS1t9z0Eampd6k7OfOK3lgdG/aXWwQhQxdjn X-Received: by 10.180.21.162 with SMTP id w2mr36160159wie.66.1425839815264; Sun, 08 Mar 2015 11:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 8 Mar 2015 11:36:15 -0700 (PDT) In-Reply-To: <201503081424.24976.davemgarrett@gmail.com> References: <20150308180310.GA10911@LK-Perkele-VII> <201503081424.24976.davemgarrett@gmail.com> From: Eric Rescorla Date: Sun, 8 Mar 2015 11:36:15 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b875080b222f70510cb3347 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 18:36:58 -0000 --047d7b875080b222f70510cb3347 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 8, 2015 at 11:24 AM, Dave Garrett wrote: > On Sunday, March 08, 2015 02:03:10 pm Ilari Liusvaara wrote: > > MTI cipher suites: > > ------------------ > > I see there being only two realistic AEAD ciphers: > > > > - AES-GCM (if you have hardware support) > > - Chacha20-Poly1305-AEAD (no need for hardware support) > > On this topic, a thought to consider: > If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly > increase roll-out of the new cipher. AES-GCM could be listed as SHOULD > support. Existing TLS 1.2 implementations generally support it already, so > this would most likely provide two cipher suites that most can be expected > to have available. On the other hand, if AES-GCM were chosen as MTI, then > we would have to rely on merely encouraging implementations to consider > alternatives. I tend to take the opposite attitude. The purpose of MTI is to provide a guaranteed minimum for interoperabilty, and given that GCM is generally supported, that seems like the natural choice. -Ekr > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7b875080b222f70510cb3347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 8, 2015 at 11:24 AM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Sunday, March 08, 2015 02:03:10 pm Ilari Liusvaara wrote:
> MTI cipher suites:
> ------------------
> I see there being only two realistic AEAD ciphers:
>
> - AES-GCM (if you have hardware support)
> - Chacha20-Poly1305-AEAD (no need for hardware support)

On this topic, a thought to consider:
If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly inc= rease roll-out of the new cipher. AES-GCM could be listed as SHOULD support= . Existing TLS 1.2 implementations generally support it already, so this wo= uld most likely provide two cipher suites that most can be expected to have= available. On the other hand, if AES-GCM were chosen as MTI, then we would= have to rely on merely encouraging implementations to consider alternative= s.

I tend to take the opposite attitude. Th= e purpose of MTI is to provide a guaranteed
minimum for interoper= abilty, and given that GCM is generally supported, that
seems lik= e the natural choice.

-Ekr




Dave

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

--047d7b875080b222f70510cb3347-- From nobody Sun Mar 8 11:50: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 82AEB1A00D8 for ; Sun, 8 Mar 2015 11:50: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 f456vn6k8AIs for ; Sun, 8 Mar 2015 11:50:07 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::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 104071A00CA for ; Sun, 8 Mar 2015 11:50:06 -0700 (PDT) Received: by qcyl6 with SMTP id l6so3842671qcy.13 for ; Sun, 08 Mar 2015 11:50:06 -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=0P33BYa3XVVm/hlyts3oGNhtPIAxjKbthjVhB3flTrQ=; b=0BXxRlzdEl2oGHk4C37FvULbHdTKBOuneAhUSBd3FXwcuofLURx6futSepdFrnZdHd kLpq+E1CjnGYvDon9A4+79rt6CKccnRpqdfnOd6tUy6S3T/mF2gUelDA3AqBVPlK1KnB qHFw1nzfm3PAtZUNmjGHAd574tDh7wjpf/rmS2AMuo6V/+alkk91pQiCnCTm5P+XNLr/ fEJ7v1XJrathy4FT9NGVY18Bwbu3h4SPd2XPY/PFzNRbrZCWgecIzIyePSKvmKZfddEB h0eu/cZJBhYKEQ4En3d6NXpu1p4yJ4JbQIBjP1HKTTqWNKYuzF4Ptco0Y8m5F/fy7ZOc ZI2w== X-Received: by 10.55.24.160 with SMTP id 32mr31338819qky.23.1425840606289; Sun, 08 Mar 2015 11:50:06 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q193sm10056690qha.14.2015.03.08.11.50.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 08 Mar 2015 11:50:05 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sun, 8 Mar 2015 14:50:04 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081424.24976.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503081450.04610.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 18:50:08 -0000 On Sunday, March 08, 2015 02:36:15 pm Eric Rescorla wrote: > On Sun, Mar 8, 2015 at 11:24 AM, Dave Garrett > wrote: > > On Sunday, March 08, 2015 02:03:10 pm Ilari Liusvaara wrote: > > > MTI cipher suites: > > > ------------------ > > > I see there being only two realistic AEAD ciphers: > > > > > > - AES-GCM (if you have hardware support) > > > - Chacha20-Poly1305-AEAD (no need for hardware support) > > > > On this topic, a thought to consider: > > If Chacha20-Poly1305-AEAD were made MTI for TLS 1.3, that would greatly > > increase roll-out of the new cipher. AES-GCM could be listed as SHOULD > > support. Existing TLS 1.2 implementations generally support it already, so > > this would most likely provide two cipher suites that most can be expected > > to have available. On the other hand, if AES-GCM were chosen as MTI, then > > we would have to rely on merely encouraging implementations to consider > > alternatives. > > I tend to take the opposite attitude. The purpose of MTI is to provide a guaranteed > minimum for interoperabilty, and given that GCM is generally supported, that > seems like the natural choice. It is of course the obvious choice, which is why I'm speaking up to encourage an alternative. TLS 1.3 is on track to have a one-true-cipher of AES-GCM, with alternatives slowly coming into play. This is something many would like to avoid, so a different decision here could affect that. ChachaPoly also has the benefit of playing nice with hardware, making MTI potentially easier on some. It's not a bad decision if AES-GCM is picked as MTI, but I do think it is very much worth considering the total end result and not just the minimum interop. Dave From nobody Sun Mar 8 13:01: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 20CBD1A011E for ; Sun, 8 Mar 2015 13:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjmdGxX6CDux for ; Sun, 8 Mar 2015 13:01:37 -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 A2D4A1A0111 for ; Sun, 8 Mar 2015 13:01:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 46E0BBEDC; Sun, 8 Mar 2015 20:01:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXR_24OkL61e; Sun, 8 Mar 2015 20:01:35 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.19.237]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3EE36BED9; Sun, 8 Mar 2015 20:01:35 +0000 (GMT) Message-ID: <54FCAA9E.4000208@cs.tcd.ie> Date: Sun, 08 Mar 2015 20:01:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Garrett , Eric Rescorla References: <201503081424.24976.davemgarrett@gmail.com> <201503081450.04610.davemgarrett@gmail.com> In-Reply-To: <201503081450.04610.davemgarrett@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2015 20:01:39 -0000 On the question of MTIs... I've no strong opinion on whether this would be good or bad, but there is a perhaps-minor but real "rift" between devices supporting GCM and those supporting CCM, and I've heard it postulated that a cha-cha based ciphersuite could be the common denominator that provides interop between those classes of device. I guess that's an argument for making both ciphersuites MTI (note: I'm not claiming it's a winning argument, but it is a thing to consider). S. From nobody Sun Mar 8 16:47:43 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 AAD0B1A0275; Sun, 8 Mar 2015 16:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbQkte_YHRxQ; Sun, 8 Mar 2015 16:47:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A33E1A0204; Sun, 8 Mar 2015 16:47:41 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308234741.6711.37327.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 16:47:41 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-18.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: Sun, 08 Mar 2015 23:47:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-18.txt Pages : 19 Date : 2015-03-08 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-18 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 Sun Mar 8 16:54: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 4B64C1A0275 for ; Sun, 8 Mar 2015 16:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, 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 IT0_NiVsnX7f for ; Sun, 8 Mar 2015 16:54:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 1A9341A0222 for ; Sun, 8 Mar 2015 16:54:53 -0700 (PDT) Received: from [217.140.96.140] by 3capp-gmx-bs34.server.lan (via HTTP); Mon, 9 Mar 2015 00:54:51 +0100 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: tls@ietf.org Content-Type: text/html; charset=UTF-8 Date: Mon, 9 Mar 2015 00:54:51 +0100 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:oeAXfvy7OQBgSlTBiqOW/GEWQR37V9McquxPGoWGqi0 SzGgh3Xf51N3P+Qt4YidvZSaX9IO0UylxBmL1Xt/9afqY1eZ2c EJDdomeIIc3FyityiCXl41jhUDYyZ6EPwL2AH3JClM40Kav4KK MKq3jdVa6ePWRRZiYrLRhp52CdAYSLjQmSXTELGDr9SO3J/1VQ mfmAh0rxYB/mfiH/uoP7ZUqMllXP73KpaxG8rHsvS1BZOeuGPZ DU93dzR1+Xd/a62GxLDCce4mc0K5IHoVPI1cIKui5JVJusBFvh k7e63g= X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: [TLS] draft-ietf-tls-cached-info-18.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 23:54:54 -0000
Version -18 of the TLS Cached Info document addresses review comments from Sean and Joe. 
I would like to use the interim meeting to discuss the caching of the client provided certificate (a feature that is not included in the spec). 
 
Ciao
Hannes
 
From nobody Sun Mar 8 19:26: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 C22261A03E1 for ; Sun, 8 Mar 2015 19:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK_qObfMMJMd for ; Sun, 8 Mar 2015 19:26:28 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.41.245.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D7D1A01F4 for ; Sun, 8 Mar 2015 19:26:28 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id CFED53110B9B5; Sun, 8 Mar 2015 21:26:27 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id C00B23110B966 for ; Sun, 8 Mar 2015 21:26:27 -0500 (CDT) Received: from [96.231.226.227] (port=53584 helo=[192.168.1.8]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YUnOl-0003cl-Aj for tls@ietf.org; Sun, 08 Mar 2015 21:26:27 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF8F424-6E55-4418-A8C5-16B6894B146C@ieca.com> Date: Sun, 8 Mar 2015 21:27:38 -0400 To: "TLS@ietf.org (tls@ietf.org)" 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.226.227 X-Exim-ID: 1YUnOl-0003cl-Aj X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [96.231.226.227]:53584 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] March 2015 TLS interim remote participation details X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 02:26:29 -0000 All, The March 2015 TLS interim meeting is scheduled for: 2015-03-10 - 9am-5pm 2015-03-11 - 9am-5pm Please note that this is PDT =3D Pacific Daylight Time All participants are bound by the note well: http://www.ietf.org/about/note-well.html The proceedings (agenda, minutes, proceedings) can be found here (look = for the 2015-03-10 tls row): https://www.ietf.org/meeting/interim/proceedings.html =20 For those participating remotely, a TLS jabber room is available as well = as a Webex session; details follow: 1) Jabber tls@jabber.ietf.org Will will draft a jabber scribe to make sure remote questions/comments = are channeled into the room. The scribe will likely not provide a = transcription of the conversations at the interim but will make sure = remote participants are at a minimum kept abreast of what topic/slide is = being discussed. NOTE: The jabber room logs are archived. 2) Webex NOTE: If you are not speaking please *MUTE* your phone to minimize the = chance for disruptions during the call. NOTE: Webex has a chat facility too, but it=92s probably best to use the = tis@jabber.ietf.org room instead. IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with Joe or I prior to the start of the recording = or do not join the session. Please note that any such recordings may be = subject to discovery in the event of litigation. Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=3Dm2a1e7a45ba891c92046696a82cba33d1= Meeting number: 643 214 287 Meeting password: 1234 spt= From nobody Mon Mar 9 06:42: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 AD37C1A891D for ; Mon, 9 Mar 2015 06:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7fGoanbP7JVh for ; Mon, 9 Mar 2015 06:42:21 -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 D0BD01A8783 for ; Mon, 9 Mar 2015 06:41:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id EFD7B874202B8 for ; Mon, 9 Mar 2015 13:41:37 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t29Dfe2O003083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 14:41:40 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 14:41:40 +0100 From: "GUBALLA, JENS (JENS)" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: draft-guballa-tls-terminology-00.txt Thread-Index: AdBabsQr/duhNwM3QrKauCX1hG6RZg== Date: Mon, 9 Mar 2015 13:41:39 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A33AF99@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B1_01D05A77.2624AC10" MIME-Version: 1.0 Archived-At: Subject: [TLS] draft-guballa-tls-terminology-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 13:42:25 -0000 ------=_NextPart_000_00B1_01D05A77.2624AC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Based on the study of TLS- and DTLS-related RFCs we defined a set of (D)TLS terminology terms (http://tools.ietf.org/id/draft-guballa-tls-terminology-00.txt). We put the focus on key terms which were causing some controversy so far (other IETF-WGs, outside of IETF). The purpose of this document is to provide a central place of key terms as used in TLS and DTLS RFCs. We are appreciating any feedback. Thanks, Jens and Juergen ------=_NextPart_000_00B1_01D05A77.2624AC10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWSTCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIGfTCCBWWgAwIBAgIKRWwXQQAAAACdHDANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTMwOTE3MTQ1MjM4WhcNMTUwOTE3 MTQ1MjM4WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrjfAo1dzqvHuB AwJhoRVC3mbaCowaDmd9WFkrzoOfDaqDlkEmHeDq46udrYiIHkF6OE61T54M225lLXjD9CylO6jK b+WsZ/84tTzYCy36qeg8JUD7vTeMJG581LiXw8XMBaMBkBqKg/sR0ZkCqCSsi8aCrhQys8+6Tr4O pJFz5QIDAQABo4IDszCCA68wCwYDVR0PBAQDAgeAMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcV CIW9xVmD47E5h6WBKoa/w0KFlJgZgQuE0LRahcPhRAIBZAIBDDAdBgNVHQ4EFgQUiJYaL8Km8mUp QxwCyGv/p+vMVQAwHwYDVR0jBBgwFoAU2exrvZZYIvfYpnfN/k2B77qXvRIwggFcBgNVHR8EggFT MIIBTzCCAUugggFHoIIBQ4aB2WxkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUyMEludGVybmFs JTIwU3ViJTIwQ0EsQ049dXNuYXZzcGtpMDNwLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNv bT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0 aW9uUG9pbnSGK2h0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0 dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIB YAYIKwYBBQUHAQEEggFSMIIBTjCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBM dWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA3 BggrBgEFBQcwAoYraHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBE BggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BL SS9zdWJDQS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEF BQcDBDAqBgNVHREEIzAhgR9qZW5zLmd1YmFsbGFAYWxjYXRlbC1sdWNlbnQuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCj2G+kebCkeR0vqSqzEqskEkd5IGr32c/FF4VsMFatUJsh03GCg93zpN0MBxWI /zoKbn+Y/5FWcBzgjNKhG3FI9ZGj4EhDsoGgYBIEeP0JLwPJXg0e3P/+meH94acUIH/7EfzKoJpz yvuAGXZ7mTS5WPoI+/EYN8+iK0N/h/sWrBbIFUnOgbTJqNJyqt9/VyNSS57g5OeaxzqHLHyRimT4 1OY5jKRc2n83Tm6rkMmAd54N4ImXE7oUt8QcCkGvfiD1X5KLHDwUHRTW9P9vASHtCzgWoUIHPSig 8ky5BH3OdJ6BKN8zqNRX81RLZpqmvHEqSWejhYXKy0nxDeixLaEXMIIHLjCCBhagAwIBAgIKRWzH hgAAAACdHTANBgkqhkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT 8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVj ZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTMwOTE3MTQ1 MzIzWhcNMTUwOTE3MTQ1MzIzWjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9q ZW5zLmd1YmFsbGFAYWxjYXRlbC1sdWNlbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDItuRpLIiez2JpW/GzSRS+hC0F0hFQ2X+BpGP+rINA9Y+unUUsAY1/B+xBX+qFaJ8XxmG3BRme R/V4cI4ixge0IaSkilImt3GiAMrPH5dfQhFkwv4fkOSdIa0vrAhQXbhDH9zk/phurPInp/bTYtBg uT5/Jd2ie3YHRAJuiDFJAwIDAQABo4IEZDCCBGAwCwYDVR0PBAQDAgUgMD4GCSsGAQQBgjcVBwQx MC8GJysGAQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQuCupMPhOrffgIBZAIBDTCBlAYJKoZI hvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYI KoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEARYwCwYJYIZIAWUD BAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFJheKnT4HqkKlFoz5GqZ0AkX lAXVMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXAYDVR0fBIIBUzCCAU8wggFL oIIBR6CCAUOGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hitodHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JshjhodHRwOi8vc2Vy dmljZXMuc3VwcG9ydC5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybDCCAWAGCCsGAQUF BwEBBIIBUjCCAU4wgcwGCCsGAQUFBzAChoG/bGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIw SW50ZXJuYWwlMjBTdWIlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y0FDZXJ0 aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwNwYIKwYBBQUH MAKGK2h0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYBBQUH MAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0Eu Y3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQBgjcVCgQcMBowCgYI KwYBBQUHAwQwDAYKKwYBBAGCNwoDBDAqBgNVHREEIzAhgR9qZW5zLmd1YmFsbGFAYWxjYXRlbC1s dWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDYFkloLQX9D6GLlsqWsAKnOLYIpanp0MxnxZdX 5Q1yePq+XEnwBmBNnv1Tgo5tgrZlva4QPX2INU7eNkfuyKy384TJLrNPrv05LcdvgkLaNcA093ud zsOsCfP8WnJGS0FF8PKI/ihLH3HdgtiyXVflvwWywmE+jGmG/8i82chowoRgiEI8pqwtBX5NWXqr /S7d8RwgWf3SIE2iUeGedQhnECuN0xpGC4P0TfqoB8xmWdtUev/jj63w+mGGTwfH3ESYS3jcqeek OQQGtlLmV4hcmJPnTXC4i7Ou2jDV3Xbg5zhz0ZeUQsLTRLcDy+k6ANFtBlr3Y8NPC9MJIMUSc9G9 MYIDqDCCA6QCAQEwgZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZs dWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUG A1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBAgpFbBdBAAAAAJ0cMAkGBSsOAwIa BQCgggJpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMwOTEz NDEzOFowIwYJKoZIhvcNAQkEMRYEFGgLvuP4O4X4T4U4HcvusvDlcv+4MIGlBgkrBgEEAYI3EAQx gZcwgZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxj YXRlbCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBAgpFbMeGAAAAAJ0dMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIG CgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCkVsx4YAAAAAnR0wgbcGCSqGSIb3DQEJDzGBqTCB pjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUwDQYJ KoZIhvcNAQEBBQAEgYB4oVcn3P/hUtp3Qje+mfRt7EFWOYjEjKRsZcwQOO17vSE0rmEJeEv4mPVz g6XOVbDjmvSaum/cQz9Fx4OMNyospX6uiBMJPoO1UIwE217uEFZd9UdHNmyT5Z16DQ7krpsdAGrI QgcEHO3ceaQOjaJ47fQrxjLde4CyKzQQuKI0YAAAAAAAAA== ------=_NextPart_000_00B1_01D05A77.2624AC10-- From nobody Mon Mar 9 09:54: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 39F511A888B for ; Mon, 9 Mar 2015 09:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=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 n3VBMCVZTO6D for ; Mon, 9 Mar 2015 09:54: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 B521A1A886B for ; Mon, 9 Mar 2015 09:54:02 -0700 (PDT) Received: by wibbs8 with SMTP id bs8so22986805wib.4 for ; Mon, 09 Mar 2015 09:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=yI5Wa2q44u5LCa/HDUYbu7dJwfp3XSUix2kBuY04sMU=; b=R0+NS7pLF6stbww9qB8htL4yKyOBwrg89YecIeLVq5JVZAgfnCTOkxC+A3bzZrTLq9 NXK2nCEsUmADpDQLCkFLW78WBc46NL+nDc5r8GfH9EaW++6ML5YCD/cl+UhMay5OXB0m oy1LOigOrC6dENunU+/MKH47NDqKhkzyCslIouzMmvfq7cbnrIYM0j9gGf7rBUd5rEgB Zvp/Rhhk+y8stZzzDAGpfUU0Y1ZFsfWrJL/gyUO35hvbgIrYL88Nm3qbELkK/MVA4niz tuctVAvPPF4d5xLaNg5u0+eNRP/9zChT1Fmmm/8t0iXVIVHVYBJdTxZr8QfK5oLsM/+R 6Gbg== X-Gm-Message-State: ALoCoQlvfpSrzKxAxM00bGV00WL6vNiI5syN+131s3+culErQ6Im91DR3K3BXjSd5e/C35kczGJj X-Received: by 10.194.237.34 with SMTP id uz2mr58572799wjc.157.1425920041414; Mon, 09 Mar 2015 09:54:01 -0700 (PDT) Received: from [192.168.111.52] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by mx.google.com with ESMTPSA id q10sm27483684wjr.41.2015.03.09.09.53.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 09:53:59 -0700 (PDT) Message-ID: <54FDD024.3080309@azet.org> Date: Mon, 09 Mar 2015 17:53:56 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201503081424.24976.davemgarrett@gmail.com> <201503081450.04610.davemgarrett@gmail.com> In-Reply-To: <201503081450.04610.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig48E3B0646CEB9DF8004A8DD9" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:54:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig48E3B0646CEB9DF8004A8DD9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Dave Garrett wrote: >=20 > It is of course the obvious choice, which is why I'm speaking up to enc= ourage an alternative. TLS 1.3 is on track to have a one-true-cipher of A= ES-GCM, with alternatives slowly coming into play. This is something many= would like to avoid, so a different decision here could affect that. Cha= chaPoly also has the benefit of playing nice with hardware, making MTI po= tentially easier on some. It's not a bad decision if AES-GCM is picked as= MTI, but I do think it is very much worth considering the total end resu= lt and not just the minimum interop. >=20 There's also my draft for AES-OCB. We're currently working out the IPR situation (rogaway, IBM, etc.). I still think it's a viable option (more than CCM) that should be considered /if/ there're no patent restrictions. In the end CCM was developed because OCB was patented back then. On MTI: - AES-GCM should be MUST not SHOULD. - ChaCha20/Poly1305 should MUST as well. =2E.IMHO. Aaron --------------enig48E3B0646CEB9DF8004A8DD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU/dAlAAoJEOTbZJL9ubXVgdkP/jqiK87TZ/djko//IAG/EiBi 1WsFqPMKKFOTzpYEYRXp/FypoaWKl7goNOGpZNGegTZMjLIGGulY/DdJGe5pWIjp SmTzwExG9C2Q1SYk1TK32+C/to4LYy0mLyRb7CfnDbZcQwJEhrgJsoVIDw5EP/8D CCz+4m5foq0fH7VqFdFgOjbGvR6CT1jmIaWhKeWT65RHzl9vdEbkZagoqEnnub5W KkNy9I/lKg+dczGMIAfwEr6PX1MkWuBiRkdqwADWnZGY6FUlPNXASJBGzIWTYw4q la/AZl1P9I9RvjA9oBMWPv01S4tfwMU4PQ/sr/Ai4LsNs1/cLFCD5YGs6sKpDa07 YpD0fMpnX6GP/JMcVqJLEzM6pmblvHdkPaSgkDJOAyZFQ/jx4WQ7sbh2avEREsC5 g0ZV21Abcf/srdWyravWO0UzdWc5kTdAlR3FkXIhMrMYjcvy9E0iLcL93g6ujrXQ Qq4EykDrOFenOkVlAAMGKmuG2yQp9+MwiHDp8FlrhqTERJV/B+WPnku2qLTIHhXk GAfA2Hdt+Dq301KLMq96m3DhiBN02Tn5ZHuDTzv/WBZytoHwm9S9nhr4nSQQA+jt cdj0UzVaxttK/hD+I6NhLO+mYW7aOGJolEOPJLMBmffXvudPgvZWCmhuBa/aG+pu EQAV5EwlspFRgVv4avBE =Jvp6 -----END PGP SIGNATURE----- --------------enig48E3B0646CEB9DF8004A8DD9-- From nobody Mon Mar 9 11:19: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 18F5C1A9152 for ; Mon, 9 Mar 2015 11:19: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 EJC0bHrL-o5y for ; Mon, 9 Mar 2015 11:19:33 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 17A911A9150 for ; Mon, 9 Mar 2015 11:19:33 -0700 (PDT) Received: by qgfh3 with SMTP id h3so30603218qgf.2 for ; Mon, 09 Mar 2015 11:19:32 -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=tStr51sA3ocow8qZKhYCt0X1nGrERlJO4clOr4Z/sK8=; b=cFszQvoP166h7eG/+CyACAO2EALMRA7PAl1eGWY93UsCKiSsrFVugUC2vE0oYUIuhb sprtle9XqLpFyDL0YBXaCQup3IQXn6cj4kgxXHAO9pELVLhk/DtqnjKr2D+I0uxZsGUj sTkvV7cEoATot01oru39HQ8G0gZQaeq0w9twCr/NSVxmmt+vBGREDQrYHTXy45fQhcWS M7Z0oEn3Q2fGvf08/Pp9jZHur6qzVWcdE9UqpW4Lc/T+P1Z2W6BKBHP4h1DLkDbLfYdy u45fRoTHoJOJS73551mNLwiOfH0wV3gZSy727veQyY5e0pWkqF9Wp5emLNKaU7UtyzlN hUEA== X-Received: by 10.55.42.39 with SMTP id q39mr40296137qkh.99.1425925172367; Mon, 09 Mar 2015 11:19:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 4sm6926210qky.7.2015.03.09.11.19.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 11:19:31 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Mon, 9 Mar 2015 14:19:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081450.04610.davemgarrett@gmail.com> <54FDD024.3080309@azet.org> In-Reply-To: <54FDD024.3080309@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503091419.30893.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:19:38 -0000 On Monday, March 09, 2015 12:53:56 pm Aaron Zauner wrote: > There's also my draft for AES-OCB. [...] > > On MTI: > - AES-GCM should be MUST not SHOULD. > - ChaCha20/Poly1305 should MUST as well. > ..IMHO. Oh, I'd like to MUST all the things too, but I doubt that'd get consensus. Generally specs get exactly one MTI. One way to do things would be do do the following: ChaCha20/Poly1305 MUST implement AES-GCM SHOULD implement; MUST implement if TLS 1.2 backwards compatible AES-OCB RECOMMENDED or SHOULD implement TLS 1.3 implementations should be required to attempt better security when using old versions, so requiring AES-GCM to do so seems perfectly reasonable. Dave From nobody Mon Mar 9 11:32: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 DA4351A923A for ; Mon, 9 Mar 2015 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwDDyL0dWQTm for ; Mon, 9 Mar 2015 11:32:20 -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 0E5421A9233 for ; Mon, 9 Mar 2015 11:32:15 -0700 (PDT) Received: by widem10 with SMTP id em10so9101234wid.2 for ; Mon, 09 Mar 2015 11:32:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=jubk0Mdqv8HrX1UX87OhIBKPTca/PSTmX2eB9hq6oNk=; b=i+Kwaaa9F+Nda38l5VTaykV2QFlt/A3u1VELNKBWmqwXdJTcK1uHL94M3lhGHrUmNI PU3ezRZz9vrPI7a/co8rs3RCzgTSVwEO3pbnhPMv/SmBOi2YeInHCZTqtbHmO42qHSuy N14J4BiFQIkOjKA74Imb0D+gSCASycBN+oujEs1v3rI/7mEd7gjJgtSo/AnIGxYeNdDE 0PwPxXI0DkDon4SUpenoN3z+rJtiUK5pnNefiY2r+g4zBxQn8AFmoTxJjGNHSht8rpUi CTYjgIZGNljVJFwHqoJYHHW+w+Ik8kDjugUp4/AF1GdLQuiUWs1GwA2PqwwX/ZS0AfL5 QyyA== X-Gm-Message-State: ALoCoQm4hD6oI/O/Gl1soEWBWheIIy1pxoWtslZV6TnvF8BKUQ9w/NeaJua7IJURy/XGvkWEOa8A X-Received: by 10.194.80.40 with SMTP id o8mr59505451wjx.34.1425925933819; Mon, 09 Mar 2015 11:32:13 -0700 (PDT) Received: from [172.20.10.4] (089144198067.atnat0007.highway.a1.net. [89.144.198.67]) by mx.google.com with ESMTPSA id hv5sm29351866wjb.16.2015.03.09.11.32.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 11:32:12 -0700 (PDT) Message-ID: <54FDE727.5040607@azet.org> Date: Mon, 09 Mar 2015 19:32:07 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <201503081450.04610.davemgarrett@gmail.com> <54FDD024.3080309@azet.org> <201503091419.30893.davemgarrett@gmail.com> In-Reply-To: <201503091419.30893.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig3B2DC404655BAAE353AB3A6F" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:32:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B2DC404655BAAE353AB3A6F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, Dave Garrett wrote: > Oh, I'd like to MUST all the things too, but I doubt that'd get consens= us. Generally specs get exactly one MTI. One way to do things would be do= do the following: >=20 Wouldn't it make sense in the case of TLS to have more than a single MTI ciphersuite? Given that there are problems with AES-GCM on mobile devices and ChaCha20 seems to be the contender for multi-plattform ideally both would be mandatory? AES-GCM has huge performance benefits on plattforms that do have AESNI instructions so having ChaCha as MTI will cause implementors to implement both. That's good; but also a bit confusing instead of having both as MTI. Is there a strong reason why there _must_ be only one ciphersuite as MTI? > TLS 1.3 implementations should be required to attempt better security w= hen using old versions, so requiring AES-GCM to do so seems perfectly rea= sonable. >=20 Exactly. Aaron --------------enig3B2DC404655BAAE353AB3A6F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU/ecnAAoJEOTbZJL9ubXVcxUP/iB67yWNKJKiRlg5GA4iMBz3 VdWORdpLTe52FTTnKV4fPATmDA7BZWitGY7SieRX8JPGlWamfOqhU5PgAVG8MLBf o1f5pZfiSrvruUD3cXZbWdauGN4cuYwTOSjFEHbyF9GebV6YX0dOuKJWLQv8wB3u UyDiWEWB/WP0PIE2tpg9Wgb22sbkqe391caAnNMCYh7vT3wsjPO+uU2W/rzUAYfl G6zweckof/KWt4rbXI5+djUKF8p2BWm9kuCDQtujOhOwBox0RDns5Ec4yeLGP5LG T3WppRMBNkrg5JWsSBIs3fcRZr9iZClBSX0B4JtnM+iHRDP4FGsKm7F2n0VjXEC6 CKnEX+evn2W1W/lH6PUO7runthx5LaKeFNkY0Xj6cCAkNAadIur7jmoh5xststqO bv0mT8n3Cs7gn1p2VsaK64RRO3WIHbI6mEymNgRcWCMSOhlJ1XGpo5eUi/5jDkqd kG5je9Vedkd68EfPepiZl6BCND/nMaR8ljT7WoOn+3hhevI/Hf9r6IwkGBK+AeS6 wJyweJEFZ1oEWfcMWQKXU/RCbTQzKeKYaQkGUureLdnvX3U0WdvPzKgJID3242Xa nJsBnTchBX9f4daRclWpNMmqv8P1w9/a9s5hv2d+UBum6OW6Zdi5HMs9JMdqEscu +f+atKalmtcTQZWIv/tJ =4YcJ -----END PGP SIGNATURE----- --------------enig3B2DC404655BAAE353AB3A6F-- From nobody Mon Mar 9 12:27: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 4B1CD1A00FB for ; Mon, 9 Mar 2015 12:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaBvQTx75-qE for ; Mon, 9 Mar 2015 12:27:30 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.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 DC56A1A8AD7 for ; Mon, 9 Mar 2015 12:27:22 -0700 (PDT) Received: by qgdz107 with SMTP id z107so31125986qgd.3 for ; Mon, 09 Mar 2015 12:27:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NFfEhuwpiMQgmFeqsXA8GaUzgpftla6Xn5dhcnNVNM0=; b=f4MjrETTNUOKAqDM28tPWoAA0nDgxuKN9kjlOydQkSWBO654PRP9/zUBkvY2GRLOSD kpmXujLtgFWiRJaA3/42jhHCrcLYQITABDwlTewMCeY13fWdUsRssjco/VVFsdBWL6y9 ujUsF4dsHxJjBHHjkR56oBwAhoIQBhvT3SoUpInjsfNP6fKltLBIuJygKL36d75u1BV5 9viYHe63/cC9HS3vZsqXLeI9CFPR58UXrOnMNFplEU+OUPoODqjkssjF386JyuZfvBoT QyI8wQuT9yHZxiDomK9Sv2Xmzju1cytQCZTI1QYhQzN65CmGk/k5wi2YSxuxLctubYeI cSdQ== X-Gm-Message-State: ALoCoQnUMHFNNM0aaIObghaR9kXpViZqQPx2Dtg17v6J9VNwwNe5dBw7AHZogj8Cr1FVAN7ZwUz8 X-Received: by 10.55.26.2 with SMTP id a2mr41503654qka.100.1425929242120; Mon, 09 Mar 2015 12:27:22 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id c199sm10338339qka.21.2015.03.09.12.27.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 12:27:20 -0700 (PDT) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 1D79BAC2868; Mon, 9 Mar 2015 15:27:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <201503091419.30893.davemgarrett@gmail.com> Date: Mon, 9 Mar 2015 15:27:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201503081450.04610.davemgarrett@gmail.com> <54FDD024.3080309@azet.org> <201503091419.30893.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:27:31 -0000 On Mar 9, 2015, at 2:19 PM, Dave Garrett wrote: > Generally specs get exactly one MTI. We should reevaluate that. Having a single MTI leads to situations like = IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI. --=20 Stephen Checkoway From nobody Mon Mar 9 12:44: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 1F3721A88A5 for ; Mon, 9 Mar 2015 12:44:14 -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 WHtPL1KDFZIa for ; Mon, 9 Mar 2015 12:44:12 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 416071A0072 for ; Mon, 9 Mar 2015 12:44:11 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t29Ji95L015594 for ; Mon, 9 Mar 2015 15:44:09 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'tls@ietf.org'" Thread-Topic: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) Thread-Index: AQHQWcooJvnLMNcQI0u+qod0K8sAVZ0TKa4AgAADUICAAAPcAIABceIAgAAX6ACAABLrAP//wa1g Date: Mon, 9 Mar 2015 19:44:08 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-09_04:2015-03-09,2015-03-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503090195 Archived-At: Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:44:14 -0000 +1 -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Stephen Checkoway [mailto:s@pahtak.org] Sent: Monday, March 09, 2015 03:27 PM=0A= To: Dave Garrett Cc: tls@ietf.org Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Inter= im - update and agenda) On Mar 9, 2015, at 2:19 PM, Dave Garrett wrote: > Generally specs get exactly one MTI. We should reevaluate that. Having a single MTI leads to situations like IMA= P's STARTTLS (RFC 3501) which makes RC4 the only MTI. --=20 Stephen Checkoway _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Mar 9 12:56:34 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 BE6BC1AC3F3; Mon, 9 Mar 2015 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbzGXnwaIgHw; Mon, 9 Mar 2015 12:56:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7171AC3AE; Mon, 9 Mar 2015 12:56:29 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309195629.7516.46362.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 12:56:29 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:56:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-04.txt Pages : 14 Date : 2015-03-09 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 13:00: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 9A4E91AC420; Mon, 9 Mar 2015 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2uYmMt9GQ0c; Mon, 9 Mar 2015 13:00:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6D21AC40B; Mon, 9 Mar 2015 13:00:17 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309200017.7516.45761.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 13:00:17 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-tls13-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:00:26 -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-05.txt Pages : 92 Date : 2015-03-09 Abstract: This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-tls13-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 13:10: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 49F731A9245 for ; Mon, 9 Mar 2015 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSiv4L25OTUX for ; Mon, 9 Mar 2015 13:10:25 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::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 7FF1B1AC3CF for ; Mon, 9 Mar 2015 13:10:25 -0700 (PDT) Received: by qcyl6 with SMTP id l6so11617675qcy.10 for ; Mon, 09 Mar 2015 13:10:24 -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=V9LpwERPHKPn0M5GacTbanes7fBUDE7L8N6/U20Igr8=; b=oRiFUhQoN5muGmsD5gkop5RsN1Aw0jxDAbmH0Hcm/18y0HLGJyTSHZvjJn20mf7+KW dJ+KSPngO1FmiVeLrmeaVIZZei0vh8ps71RN79S3zTDVRV3jsYBylPC5D2GdYCJskKGZ yz2gFcv0Y3sE9VbeME1NfGyXec+Y/+/eJo0xLxwawexxpD1l2lFppfKcCu9rBMACpuBP 4Z7KIfHs9FkGrngHrK2cR980voesD/Ox3/G6O+0XJgwm+saJuekJcJP2Z2jil+qh104R O4GoWKHZFUX+jW42VUutXS2z7+WhIpYnyNIO7/VaK9lkWQwi5PsozRRbGT6yd333sj9X QmcA== X-Received: by 10.55.31.83 with SMTP id f80mr12963558qkf.57.1425931824791; Mon, 09 Mar 2015 13:10:24 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id d19sm12216393qhc.42.2015.03.09.13.10.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 13:10:24 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, "Blumenthal, Uri - 0558 - MITLL" , Stephen Checkoway , Eric Rescorla , Aaron Zauner Date: Mon, 9 Mar 2015 16:10:22 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503091610.23008.davemgarrett@gmail.com> Archived-At: Subject: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:10:27 -0000 On Monday, March 09, 2015 03:27:12 pm Stephen Checkoway wrote: > On Mar 9, 2015, at 2:19 PM, Dave Garrett wrote: > > Generally specs get exactly one MTI. > > We should reevaluate that. Having a single MTI leads to situations like IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI. Honestly, I don't believe the existing policy is unreasonable. If implementers could actually be compelled to implement both, great, but RFCs can get ignored and in practice you could end up with only one... and no interop. A bigger problem is that just specifying MTI isn't enough in practice. It would be better to have an MTI and a separate MTD (MTI + mandatory to deploy). For example, with RC4 being phased out I've actually got a report from someone who has a host that uses TLS 1.2 but with their MTI suite (AES-CBC) disabled, and only RC4 and Camellia supported. This shouldn't be a thing we have to worry about. If we picked an MTD and an MTI, that would be far more reliable. Both would of course be subject to revision in a future RFC, and it should probably state that up front. (instead of pretending that everything will be fine forever) So, with this in mind, I'd suggest for TLS 1.3: MTD: ECDHE ChaCha20/Poly1305 AEAD MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth) Also specifying MTI curves is probably a good idea at this point. Dave From nobody Mon Mar 9 14: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 B73DE1A90F5 for ; Mon, 9 Mar 2015 14:13:21 -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 qCbvuhf2XnKI for ; Mon, 9 Mar 2015 14:13:19 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.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 92F8D1A916B for ; Mon, 9 Mar 2015 14:12:18 -0700 (PDT) Received: by wevl61 with SMTP id l61so13421540wev.10 for ; Mon, 09 Mar 2015 14:12:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=U0ys+LRcrKbzUV39GYkaLOHKaccJNguFVm6EeMFArwg=; b=dWWpQXl0vpfb/oPLf1536HgAc72dCFnNazpcpFIM38UtLgCvE0e4buzBrXTBHt3FgH 4dCmiPx65s3ub11EaDXEy5vRKeJaHDXZ7YD4EYCFKUyVViLC/wk1voQULf5u14hhwD2q 8zmRG/YPr0tGGFI+aVNVShaVpvv73trgDU2HykKAhZZ3IeZd8fM4vHlGUmh331XNdUG0 dNluKPDz83LdH0icaRMARhW/8XWAN5zp9dPj1Klo0afRtQNywQSlBjAOGHVOuteblzqX hLe775fS12EGDhWD1/X/jHYcdJOd/raUEi8UuQU7DcZp0CF51UI8CNQKwSLclvpOli7r /zIQ== X-Gm-Message-State: ALoCoQnFlBs68G+TwfSkuwQGzGEfnbsMY22riZH0dJzWwSd1y/ekguD5sAbiMHg0X4PEHkBVKo1q X-Received: by 10.180.75.233 with SMTP id f9mr34618135wiw.5.1425935537360; Mon, 09 Mar 2015 14:12:17 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id hl15sm10119040wib.3.2015.03.09.14.12.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 14:12:16 -0700 (PDT) Message-ID: <54FE0CAC.1040504@azet.org> Date: Mon, 09 Mar 2015 22:12:12 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091610.23008.davemgarrett@gmail.com> In-Reply-To: <201503091610.23008.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0CABAF90E43C38454BF63772" Archived-At: Cc: Stephen Checkoway , tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:13:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0CABAF90E43C38454BF63772 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave, et al., Dave Garrett wrote: > Honestly, I don't believe the existing policy is unreasonable. If imple= menters could actually be compelled to implement both, great, but RFCs ca= n get ignored and in practice you could end up with only one... and no in= terop. I don't see why having only one MTI ciphersuites would change that outcome? If the RFC gets ignored anything could happen. A TLS implementation that is unable to speak to other implementations is pretty useless; that would probably also be the observation by the implementers. > A bigger problem is that just specifying MTI isn't enough in practice. = It would be better to have an MTI and a separate MTD (MTI + mandatory to = deploy). For example, with RC4 being phased out I've actually got a repor= t from someone who has a host that uses TLS 1.2 but with their MTI suite = (AES-CBC) disabled, and only RC4 and Camellia supported. This shouldn't b= e a thing we have to worry about. If we picked an MTD and an MTI, that wo= uld be far more reliable. Both would of course be subject to revision in = a future RFC, and it should probably state that up front. (instead of pre= tending that everything will be fine forever) >=20 I get why some implementers (e.g. embedded people) would only want to have to implement one ciphersuite. My concern is also for deployment. I do believe (possibly naively) that most implementers will know what their users need. But then again -- maybe I'm just confused by the term (which should be defined in more detail, in case) -- but doesn't mandatory to deploy also mandate that implementations do support the specified ciphersuites in practice? I don't think that just because something has been 'convention' for some time it's always the best option (see postel's law). It might make sense to reevaluate as others have also stated in this thread. Again; are there serious concerns why there should not be more than one MTI ciphersuite in the TLS 1.3 spec.? > MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth) That would be again more than one ciphersuite. So why not have more than one but with different AEAD constructions? BTW: I'm not convinced ECDSA is the best path to take [0]. AFAIK from deployments most commercial CAs do not issue ECDSA certificates either, unless that has changed significantly over the last year or so. >=20 > Also specifying MTI curves is probably a good idea at this point. >=20 AFAICT it'll take CFRG some more time until a recommendation can be made. I don't believe it'd be a good idea for TLS-WG to specify a curve before there is consensus within CFRG. Thanks, Aaron [0] djb explains this in more detail over here: http://blog.cr.yp.to/20140323-ecdsa.html --------------enig0CABAF90E43C38454BF63772 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU/gytAAoJEOTbZJL9ubXVvREP+wemjB2MZunJ56lnupNxH83l eut6inI0y6JKGBJA+qxnMb4i2IzK63qFdBu/NLPutwbq+KiD711dwAxEZ41XHCYu XpC10w/+VM8YEiydTGns2GUE+UNuA5vIOv1OTOAr9OHBHxulkLb0/KvhlN8fbP9H EN9TXH1bN6i6lyVq8J6RhsqRnARiy0S2h2OG/pmU5i31iUL3ZRLcbyyroAEMlV0Y Prj3KrpV/hXUWK5gEh6UHA67kkS4g8VMwe1FTzaM/bryxq/JjYBa44ZrBzCqbaR4 qHUbF37DYgamnWfVKxNioJYgbmA816nRXpFuvtzd6msEGsNPMIZGwBTO5c23TfXj KSHdLEuebo5ORDD6/C/Oc5Dw7imRZENt3iC4YFvKC3vCFcbGu2/ZKryE1zPbGdNn iTsds3DrJ+jblv2tkNKmPQQiwWNTwO79eeZx43uouV3p4xsMQrpUVvrDEzj5doVo skxgPubee4utx+DEDOepYuJwqRgxkdG4IcrEQZXCl1AkS4aw+PKWu1ZsiwwWJq/q ldNv6BQfYRqjtZ76yM/ZO9i1ZyzF8uxHwJrVyN64bXxWECoBTppQe47TjbRvaXrI TbWSTFwkYPThiQjlz6hcY7y7GcnPyYI5A6XRQRUmxQDLP6NudHKpv4nQGhdVmqJA Q/Tmw9AOlx0zfMD+oYfx =poFG -----END PGP SIGNATURE----- --------------enig0CABAF90E43C38454BF63772-- From nobody Mon Mar 9 14:23: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 19CFB1AC3D1; Mon, 9 Mar 2015 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gGdRG_dIwUN; Mon, 9 Mar 2015 14:23:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A241A886B; Mon, 9 Mar 2015 14:23:39 -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: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309212339.6861.62405.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:23:39 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-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, 09 Mar 2015 21:23:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Author : Yoav Nir Filename : draft-ietf-tls-rfc4492bis-02.txt Pages : 30 Date : 2015-03-09 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-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 Mar 9 14:40: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 E906F1A901F for ; Mon, 9 Mar 2015 14:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ULGx5CEkuLl for ; Mon, 9 Mar 2015 14:39:57 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d: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 3C7851AC41E for ; Mon, 9 Mar 2015 14:39:48 -0700 (PDT) Received: by qgea108 with SMTP id a108so32047246qge.8 for ; Mon, 09 Mar 2015 14:39:47 -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=kmHrPjTzxSAIZXJYVJT0IKLy8jiec9SzMd4mYECftOQ=; b=rF8oezrVK5ZS72/iiYsZV/MtLYYeFs4/n5YRsB+nz3QclbkQnLAzE214ktlx+dNJaa DU/oVmmFI/fsyJLpK6yoIOfPsiyfa7VkENc0iBQuquOv0D2reNzt06igie+oUnY6PPyh /5GT/jH/P6d5hcjPM3kvTbSSvePVPKAfdY3FzHHI4ZXwFbTHOLxcgWXK488WRVRfY8iu w1U4DzbqyDDvNV+uFWRbWL6U3wJt/eKN85aZMSLz2NreYl/eF/vd7Buk2Y4jz00tWJXH QePgpkLRxtXaIpkByL15JnlHhllV0b3hyQTbbIw4CUwNuL81G15u4Z3LO1oDgZyRN4SS thDw== X-Received: by 10.140.150.15 with SMTP id 15mr38619280qhw.46.1425937187518; Mon, 09 Mar 2015 14:39:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 29sm8972475qkq.35.2015.03.09.14.39.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 14:39:46 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Mon, 9 Mar 2015 17:39:44 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091610.23008.davemgarrett@gmail.com> <54FE0CAC.1040504@azet.org> In-Reply-To: <54FE0CAC.1040504@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503091739.45205.davemgarrett@gmail.com> Archived-At: Cc: Stephen Checkoway , tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:40:02 -0000 On Monday, March 09, 2015 05:12:12 pm Aaron Zauner wrote: > I get why some implementers (e.g. embedded people) would only want to > have to implement one ciphersuite. My concern is also for deployment. I > do believe (possibly naively) that most implementers will know what > their users need. But then again -- maybe I'm just confused by the term > (which should be defined in more detail, in case) -- but doesn't > mandatory to deploy also mandate that implementations do support the > specified ciphersuites in practice? It's the difference between an implementation supporting the cipher and the deployment enabling the cipher. A connection proposing a cipher list without the MTI is still considered valid. One proposing without an MTD is essentially a protocol error. We have three decision sets in TLS: 1) IETF TLS WG RFC -> The Specification 2) Software implementing #1 -> The Implementation 3) Administrators configuring #2 on their servers -> The Deployment Unless it gets through all three, it doesn't actually end up on the Internet. The notion of MTI only covers us to #2. The notion of MTD gets to #3. Essentially, it's #1 telling #2 that they may not even provide an option to #3 to override the MTD decision by #1 (short of rewriting #2). The HTTP/2 spec process also had discussions about being specific when referring to implementations vs. deployments, or being more general. > I don't think that just because something has been 'convention' for some > time it's always the best option (see postel's law). Very much so. > Again; are there serious concerns why there should not be more than one > MTI ciphersuite in the TLS 1.3 spec.? What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MTD, regardless of what's negotiated (but that has risks if the MTD needs revoking). > > MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth) > > That would be again more than one ciphersuite. So why not have more than > one but with different AEAD constructions? Not a bad idea. However, the more that is proposed, the higher risk of some implementation deciding to ignore something. (though, this assumption may not be true anymore) > BTW: I'm not convinced ECDSA is the best path to take [0]. AFAIK from > deployments most commercial CAs do not issue ECDSA certificates either, > unless that has changed significantly over the last year or so. If it's not used enough, then yeah, RSA only there. I only suggest it as an option. > I don't believe it'd be a good idea for TLS-WG to specify a curve > before there is consensus within CFRG. I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing. Dave From nobody Mon Mar 9 14:42: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 8568F1ACD17 for ; Mon, 9 Mar 2015 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZoOEdj7xq84 for ; Mon, 9 Mar 2015 14:42:08 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::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 921221A90BE for ; Mon, 9 Mar 2015 14:42:08 -0700 (PDT) Received: by wghk14 with SMTP id k14so24646714wgh.3 for ; Mon, 09 Mar 2015 14:42: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=6U68dQCWA2JSJf5v2jFG7zhw2qCm2VH5YSXwL7DDUUY=; b=aNGoFz199a7+mhFZuot8DlBH1tfPvIChqVAAGT2JQcRk/4vXRbSb2hs41u1JCZY7QR HX2UHievehJHZZ5iail3+8qWR+wM4cnIflDAETUAQjGgkngF75W2sY+9d2B+YO9E9bQg TK7hfeZbSnR9Ysrd8/4RVbtKhGnYNccYfLkEXq5eT/FlvSyXSw770r6+Ak2oIFBZF7OE IU6tN2a6FlZbivKC3xLve7geuO5+rSySioTP5q8K5vXhNKzSbzMKvN0U6OITR7v41Qp7 yfmXM/oYpBAkuOfvSyZQN0PJIT/FCoYdr/TG7QQcPG2x8HX1fI8leDtLkVd7E/wk6G31 dx/g== X-Received: by 10.194.21.137 with SMTP id v9mr61032357wje.140.1425937327401; Mon, 09 Mar 2015 14:42:07 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id fu1sm958622wic.2.2015.03.09.14.42.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 14:42:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 9 Mar 2015 23:42:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00420E03-362D-4A04-B7A1-C757838E0560@gmail.com> References: <201503081450.04610.davemgarrett@gmail.com> <54FDD024.3080309@azet.org> <201503091419.30893.davemgarrett@gmail.com> To: Stephen Checkoway X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:42:13 -0000 > On Mar 9, 2015, at 9:27 PM, Stephen Checkoway wrote: >=20 >=20 > On Mar 9, 2015, at 2:19 PM, Dave Garrett = wrote: >=20 >> Generally specs get exactly one MTI. >=20 > We should reevaluate that. Having a single MTI leads to situations = like IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI. How many IMAP clients and servers support only RC4? If I configured my = client or server to work with some popular ciphersuites (like AES-CBC = 128-bit with SHA and either RSA or RSA_ECDSA) would I get failures? The problem with >1 MTI is that it raises the bar for minimum-sized = codebase, same as the old =E2=80=9Call IPv6 implementations MUST have = IPsec=E2=80=9D. It=E2=80=99s not a problem for a server, a personal = computer or even a phone to have two algorithms, but will that work for = smartobjects? I guess DICE or a successor might create a profile for = smartobjects that has only one MTI despite what the TLS 1.3 document = might say, just as previous working groups excused smartobjects from = supporting IPsec. Do we really want to go there? Yoav From nobody Mon Mar 9 14:52: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 24D241A0196 for ; Mon, 9 Mar 2015 14:52: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 NqaPmaf9AjxD for ; Mon, 9 Mar 2015 14:52:27 -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 7F7341A8AAB for ; Mon, 9 Mar 2015 14:52:27 -0700 (PDT) Received: by wivr20 with SMTP id r20so25262886wiv.5 for ; Mon, 09 Mar 2015 14:52:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=UchZMKOixMum/tW6Q/iRTa59syUSnsyQ6FB69/3XCnM=; b=ZLNelKRvP6vUU65QGihVeiAHl8oF5ZMmC16mbGe0KzDp89vHBehAWVFFwlzh0M9IWc pkfisi6RCgihZvlLTgIglgeGynU+sVLuN2JvUiLF7TKmdz6ZoKeHXUIC5Nxv/ums37/i nnlqQ4B7UgCru1D+ci+oOBCUcnkAsGvV39kUvM5ZsAmw1DosJpP+IvnfWiBxdTgBkhoq tVdN/i3jyUxlmp0YvB3TQMUHZ7ge4g60Fupkq1ixajd3Kxnm2izGEKDMmyFHoSw0HRQx n0mgPu5u45TgiYU0haGdilsBvcExRHStsAnFDaLNCXiXKO8vpQPcqyZlZ0rTnjxIthff fT1Q== X-Gm-Message-State: ALoCoQnV0ZEzAJpWOK+f3JcJgEtkdGx22x2Bjc07XICWCfqbE9BvFf0+KkgVV7NJgaNt8F2HUsAH X-Received: by 10.180.77.19 with SMTP id o19mr42331903wiw.90.1425937946353; Mon, 09 Mar 2015 14:52:26 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id nd15sm977040wic.8.2015.03.09.14.52.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 14:52:25 -0700 (PDT) Message-ID: <54FE1615.7070002@azet.org> Date: Mon, 09 Mar 2015 22:52:21 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dave Garrett References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091610.23008.davemgarrett@gmail.com> <54FE0CAC.1040504@azet.org> <201503091739.45205.davemgarrett@gmail.com> In-Reply-To: <201503091739.45205.davemgarrett@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4C674EBC43FEFDD39D21BFE9" Archived-At: Cc: Stephen Checkoway , tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:52:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4C674EBC43FEFDD39D21BFE9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave, Dave Garrett wrote: > It's the difference between an implementation supporting the cipher and= the deployment enabling the cipher. A connection proposing a cipher list= without the MTI is still considered valid. One proposing without an MTD = is essentially a protocol error. >=20 > We have three decision sets in TLS: >=20 > 1) IETF TLS WG RFC -> The Specification > 2) Software implementing #1 -> The Implementation > 3) Administrators configuring #2 on their servers -> The Deployment Thanks for clearing this up. This should be explained in case it ends up in the I-D. >=20 > What I'm proposing is essentially two MTI, with one that implementation= s are not allowed to disable. If you want to be really strict, endpoints = could reject connections that do not propose the MTD, regardless of what'= s negotiated (but that has risks if the MTD needs revoking). >=20 I'm fine with that. > Not a bad idea. However, the more that is proposed, the higher risk of = some implementation deciding to ignore something. (though, this assumptio= n may not be true anymore) I think the crypto community is pretty confident in AES. That being said, different AEAD constructions would make sense in case there is new research suggesting security issues with one of both. Be it MTI or MTD. > I think finalizing the TLS 1.3 spec prior to finalized CFRG specificati= ons would be a bad idea. Hopefully they're almost done arguing. >=20 :) Aaron --------------enig4C674EBC43FEFDD39D21BFE9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU/hYWAAoJEOTbZJL9ubXVv70QAKuTMrmh7dFEhpqDtgs2Am46 fZWnPasEiiUoIJxkFGHCzNuhO6DZIfdn1O73Gw/yfiUoQ8BUqtjQx+FKArcP0O4a Ug+bfh1poLV00RBnEUsdw8PCYLsPSME51d4XfEo9FDc2LFDasOKhTuwBs19HZWsN 9HbYJMm1td9pMx3FGOkI/SXyvzsvYfCK+9aywuhlYFFpXw5+zhMx5pQKrtg2bqqv b7N18sBgVNd1f3mn+jWss+91QFmVOoZJ5L1RLdzoMJT4m/kNXrN6OzHt7Z9liQnr d46zVNXmSTNJsCfvkbuIIb5xaRIEgTFuWHRNguPvW0U1osvuEVkqHb64Zfmj9OBH wO0JDOJxXgpYuVK/FLqJb6XmQpsMvo6B7DOY9aaLY66H49zLBE1Exr7FxwR/dl+X bTAJHr5qcjUVVCl6LCqqQOFMcpe+RqYaNKL6dt3LmSntBRLvWEtK9J+g7r28Yj/b XgahThdKo9AYf8Muc5KyV0zf6EdaBj783kyWaR8MPg5a4aplncewHgBaPzVYuXzV 1R/I2meTRnGzMxqbZnmAmiVRw4WTYvWY7Lpc4/9qhFlKIknRSAE1XfInvR8woZZ2 zby1DGUni7odHvphGPjRr87HcCfeV4Wi3y+sORM+EM2alh6nFHtxXx9P4PjPlFlk mbns29kjViDuyDejRLts =VBxY -----END PGP SIGNATURE----- --------------enig4C674EBC43FEFDD39D21BFE9-- From nobody Mon Mar 9 15:21: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 DC87B1AC3D2 for ; Mon, 9 Mar 2015 15:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czikOOQynveK for ; Mon, 9 Mar 2015 15:21:47 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::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 BF86D1ACDCF for ; Mon, 9 Mar 2015 15:21:43 -0700 (PDT) Received: by qcwb13 with SMTP id b13so33034607qcw.12 for ; Mon, 09 Mar 2015 15:21:42 -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=VSffaWiC8uy0ORndbqGAy/FaBk/BRcREbxVtp6nnApw=; b=ZA1B7nz8NWH/mUiDD6H2GBmbMwaSO2T9XGDXe6+lPCKCtHKwhNAl4FsQfnY/4+kUI0 yDMjKSuMmCb7nUPeLW6aoGm2hDfJsY04rtG+soXZRMmatgOhzfp32lGv7S2u5Lp7rEYb WjfpVrrqV2ygyQARB6JMZBMhy59Lb1qgFa042duCG0LTVsPgAE05La10C5ozh1DTUtoA A3IzV00Yv2TY5l+ndZuiAOT42oT2wFs1dzRR3Rn0+lD/XeId2/79n0Hyw8Wk86v+7BR0 P8Mq+QKK/g7WYKv+H1tOhfuizNJQNm16JW+49QHajXCfNpNFX/Jcgw3BNbVDKlyt677+ 1znA== X-Received: by 10.141.23.208 with SMTP id z199mr38845713qhd.27.1425939702726; Mon, 09 Mar 2015 15:21:42 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id f102sm2104389qki.1.2015.03.09.15.21.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 15:21:42 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Mon, 9 Mar 2015 18:21:40 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091739.45205.davemgarrett@gmail.com> <54FE1615.7070002@azet.org> In-Reply-To: <54FE1615.7070002@azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503091821.41393.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:21:50 -0000 On Monday, March 09, 2015 05:52:21 pm Aaron Zauner wrote: > Dave Garrett wrote: > > It's the difference between an implementation supporting the cipher and the deployment enabling the cipher. A connection proposing a cipher list without the MTI is still considered valid. One proposing without an MTD is essentially a protocol error. > > > > We have three decision sets in TLS: > > > > 1) IETF TLS WG RFC -> The Specification > > 2) Software implementing #1 -> The Implementation > > 3) Administrators configuring #2 on their servers -> The Deployment > > Thanks for clearing this up. This should be explained in case it ends up > in the I-D. Sorry for not being clear enough. The way I worded it initially was interpretable in multiple ways. (which I guess is apt for this discussion ;) > > What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MTD, regardless of what's negotiated (but that has risks if the MTD needs revoking). > > I'm fine with that. The risks could be mitigated with some limit on when to bail entirely, though I don't know that could be specified in a way that won't cause interop problems. If we're confident that humans have finally figured out how to write cryptography in a way that won't have catastrophic failures anymore (stop laughing), then we'd just expect some minor interop breakage until implementations are updated after a deprecation/prohibition RFC for an MTD. In my opinion, everyone is too afraid of breakage. We should just agree on how to break in unison in a way that maintains the best possible result. > I think the crypto community is pretty confident in AES. That being > said, different AEAD constructions would make sense in case there is new > research suggesting security issues with one of both. Be it MTI or MTD. Setting CBC aside, I agree. We're pretty much down to just AES-GCM being fully trusted, and that really needs to be fixed with more variants as well as new ciphers and new versions of old ciphers, like Camellia and GOST. Single points of failure are not a good thing. > > I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing. > > :) For those that haven't checked the CFRG recently, they've agreed on Curve25519 & Ed448. How long it will take to agree on how to specify this is anyone's guess. Dave From nobody Mon Mar 9 15:38: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 2B34C1ACD6E for ; Mon, 9 Mar 2015 15:38: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, J_CHICKENPOX_52=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 cmvD9iy9eJQT for ; Mon, 9 Mar 2015 15:38:07 -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 094E61A9114 for ; Mon, 9 Mar 2015 15:38:05 -0700 (PDT) Received: by wiwl15 with SMTP id l15so25478118wiw.4 for ; Mon, 09 Mar 2015 15:38:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=eJy8s6qpL+hO566J0bvKa7ubDvcGa8KRLFC9aJgSmek=; b=NNNbesw9zYzYzQ/cGgqZ0AsyayKWuUCqDm99OrFSV0+M8QhJD+zUGRrLMqjkYosSFe vFZ/F6Fu2bCO5eel0k22wcIOJvG62e2vVArsKlbkKJ9EkZC0C2Lrf+jfbRLPI7dP/QCE EFUs3Gq3RHNft3c9I5T79E12H75xgAzRF6tGbtchbNW4BVFvwFGhzErIpYfGHzdxgTSg XO6AE8WLVxuDaqVgxM/rBEngonuyRlZVXO0TC3RaOX4Rgz9qkZKnFBLv9RobCdJUmqWk OoVWLY+ll+JFDq2ZK1uZllLrsztaUp/cPPtQopMSYMrZnWS59oNPM93G8Lpt4e/Z+tHO MYRA== X-Gm-Message-State: ALoCoQnGrqOFBxh8JDzWi7ppFzUw1Yhir9FVXt9fmDWJe3yPQXguIHZQX7gc17RusRBD1A9ZiXEE X-Received: by 10.180.24.65 with SMTP id s1mr63862427wif.30.1425940683845; Mon, 09 Mar 2015 15:38:03 -0700 (PDT) Received: from typhoon.azet.org (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id cf12sm30165155wjb.10.2015.03.09.15.38.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 15:38:02 -0700 (PDT) Date: Mon, 9 Mar 2015 23:38:08 +0100 From: Aaron Zauner To: Dave Garrett Message-ID: <20150309223806.GA3923@typhoon.azet.org> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091739.45205.davemgarrett@gmail.com> <54FE1615.7070002@azet.org> <201503091821.41393.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <201503091821.41393.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:38:09 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dave Garrett [09/03/2015 23:21:42] wrote: >=20 > Sorry for not being clear enough. The way I worded it initially was inter= pretable in multiple ways. (which I guess is apt for this discussion ;) >=20 :) > > I'm fine with that. >=20 > The risks could be mitigated with some limit on when to bail entirely, th= ough I don't know that could be specified in a way that won't cause interop= problems. If we're confident that humans have finally figured out how to w= rite cryptography in a way that won't have catastrophic failures anymore (s= top laughing), then we'd just expect some minor interop breakage until impl= ementations are updated after a deprecation/prohibition RFC for an MTD. >=20 Sorry. I should have quoted properly. That wasn't supposed to sound like 'fine with rejection'. I'm fine with having MTI and MTD, now that it's clear to me what MTD is supposed to bring to the table. > In my opinion, everyone is too afraid of breakage. We should just agree o= n how to break in unison in a way that maintains the best possible result. >=20 I concur. > Setting CBC aside, I agree. We're pretty much down to just AES-GCM being = fully trusted, and that really needs to be fixed with more variants as well= as new ciphers and new versions of old ciphers, like Camellia and GOST. Si= ngle points of failure are not a good thing. >=20 I don't know if that's still an issue in implementations, but a contributor and co-author of bettercrypto(.org) was told that there're issues (IIRC timing attacks) with AES-GCM on some mobile plattforms by Google people about a year ago. I just did a quick Google search for that and all I could find was a paper by Emilia Kaesper and Peter Schwabe from 2009 that apparently fixes this in OpenSSL -- so I'm not sure what exactly they meant (I wasn't at the conference myself). In any case, people do argue that algorithmic agility causes more problems than it's worth. I agree somewhat, but IMHO at least one backup is a good idea (although I prefer N+2; e.g. AES-GCM, AES-XXX and another cipher or the other way around) and I think we should make it as simple as possible for implementers that these actually end up deployed. +1 on MTD. Aaron --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU/iDOAAoJEOTbZJL9ubXV+30QAMmJpzeWvoEoiMJ7OvtWc0U+ O1Ce0ldjQF3dmKR/7Srf2vz9+H2hY/SnrU/1/V+XtuOrOnPyWuyeNXXASnz/Ea1P PD7CshnWKkjtwWoea96K5U3+Kg008QD3ZC1tzFFWsr1AZqv/wKQUK1caWxQkH7DX lflV9YowUL24P1Hgt3owcf7TaguHMc2Hia7B/mNzW6pkWxDms2jfT4m8Wx7XPYT2 ggL6ayZDBbsc4uOQ7ZcAFchGFFJFHkD6090w/yuYDfIovWIWC5cmkg1UWB2up3DI W8UVps5X4ArfaVLk8V8Jn5P4bUyGYCjyQzC1ztQ23huTsC6veJ8dLB8rJY2lEOHY eQ6SfSEzPCQR19b3KGLG2cSLIiOxEVkm0A9TtzHEPgvNybyRpk4BH8o59qZKs3dJ S/+pohJ1qeVkV+ZayayeP0KIy4BQKtPxEkb9YpTnKGT52KZhxp1mfNJUbLKPiCJ0 /LyCc2T16M3xT46E/EP4EksVpDEdwMqHu7z0mYhukCXKaRg6krpm3XT8HxsF631Z DUImRVCqFPXd62cr9R5e6LQILAvXXZnHWpSnusoKaSxSdhJMEAcmrCcv97x5rQro seeBh/TNc2nH0XLSoa/b+t5I+z+VCEpbY5WGBsrUdA9xN67S/v1MJLRGT8dxkUpP 8zxAgn/UpmtLq99EbvAv =wvXl -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From nobody Mon Mar 9 16:11: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 1B2F91A8892 for ; Mon, 9 Mar 2015 16:11: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 0TH7vnBYrnTL for ; Mon, 9 Mar 2015 16:11:21 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::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 48C211A8830 for ; Mon, 9 Mar 2015 16:11:20 -0700 (PDT) Received: by qcyl6 with SMTP id l6so12767697qcy.13 for ; Mon, 09 Mar 2015 16:11:19 -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=jgU/PNgXoMoyc/nOihHcqvQAuus9mf0e1ODMd2WqrA4=; b=ViUaGSlQfjVn62mpw4VUlS97JQf4r+HjV9Mlh5vclM7P5T+XzsXrSKfwe6xRJX+af2 D141BRkcUVx2wsfp8B5qDPFJKIR0VSrhWzHn3d7TObR2/JvmGa6eJ/IbM0i3G+P8ZJau 5CEbIO2MqE9Q4F8bC8ypcL6ybUwilp4U8syP/4SKsL7wcW7FNoVJEg/CE+Soixa01plY RAgpYy7ahd42OUwQKkYV7ZocpMPiM2YMvzfzSS0Yb+NcRC5qOfiE/k0wZO4f8ZYPYwwt F7gJdRO/ms7SXHuqTtWWSTIJK9Fe7gTgF1jgxIi12WIjGnphSQg1t8o0fNMNr9FErq2S /qvg== X-Received: by 10.140.238.139 with SMTP id j133mr39685032qhc.26.1425942679638; Mon, 09 Mar 2015 16:11:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id r195sm2964460qha.0.2015.03.09.16.11.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 16:11:19 -0700 (PDT) From: Dave Garrett To: Aaron Zauner Date: Mon, 9 Mar 2015 19:11:16 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091821.41393.davemgarrett@gmail.com> <20150309223806.GA3923@typhoon.azet.org> In-Reply-To: <20150309223806.GA3923@typhoon.azet.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503091911.17254.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:11:23 -0000 On Monday, March 09, 2015 06:38:08 pm Aaron Zauner wrote: > In any case, people do argue that algorithmic agility causes more > problems than it's worth. I agree somewhat, but IMHO at least one > backup is a good idea I'd much rather have three than two. (not counting deprecated ciphers/modes) I think of it in this way: if one were to vanish, there would still be a choice left. With only two chosen ones, then a fatal attack on one brings us all the way back to the one-true-cipher again. If you assume eventual failure, a secondary backup is very desirable. Dave From nobody Tue Mar 10 00: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 211641B2A22 for ; Tue, 10 Mar 2015 00:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDMUWEOW7_iD for ; Tue, 10 Mar 2015 00:54:06 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id B28BA1B2A20 for ; Tue, 10 Mar 2015 00:54:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-49-237-11-14.revip6.asianet.co.th; Message-ID: <54FEA30C.6080608@bouncycastle.org> Date: Tue, 10 Mar 2015 14:53:48 +0700 From: Peter Dettman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150309212339.6861.62405.idtracker@ietfa.amsl.com> In-Reply-To: <20150309212339.6861.62405.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 07:54:08 -0000 On the very last lineof "6. Cipher Suites", the list of cipher suites that SHOULD be supported includes TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 - is that a typo that should be ..._ECDHE_...? In that same list, should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA be ..._SHA256? Regards, Pete Dettman On 10/03/2015 4:23 am, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > Author : Yoav Nir > Filename : draft-ietf-tls-rfc4492bis-02.txt > Pages : 30 > Date : 2015-03-09 > > Abstract: > This document describes key exchange algorithms based on Elliptic > Curve Cryptography (ECC) for the Transport Layer Security (TLS) > protocol. In particular, it specifies the use of Ephemeral Elliptic > Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the > use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new > authentication mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 10 03:54: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 808601A879B for ; Tue, 10 Mar 2015 03:54:29 -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 A1ZkQ2sDRjsQ for ; Tue, 10 Mar 2015 03:54:26 -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 80B561A0111 for ; Tue, 10 Mar 2015 03:54:26 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 78C234019 for ; Tue, 10 Mar 2015 12:54:24 +0200 (EET) Date: Tue, 10 Mar 2015 12:54:23 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150310105423.GA1658@LK-Perkele-VII> References: <20150309200017.7516.45761.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150309200017.7516.45761.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 10:54:29 -0000 On Mon, Mar 09, 2015 at 01:00:17PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Author : Eric Rescorla > Filename : draft-ietf-tls-tls13-05.txt > Pages : 92 > Date : 2015-03-09 Looked over the diff, some comments: > [[OPEN ISSUE: This needs to be revised. See > https://github.com/tlswg/tls13-spec/issues/5]] I get a bad feeling about this... Also, I don't know a reason the problem (as far as I understand it) can't be fixed by just by internally changing the encryption primitives a bit in fully wire-compatible way (no protocol change required). I.e. treat initial "IVs" as sensitive as keying material, and have the encryptor/decryptor (which is obviously highly trusted due to having primary keys) internally expand the nonces (which is deterministic process). NamedGroup list: I would like weak groups (1-5 and 15-19) to be deprecated (MNU). Those look quite a bit weaker than anything else (with exception of MD5[1]). Additionally, the private-use block could be named private_use or somesuch (so it stands out from other reserved identifiers). Key derivation: The spec uses hMS for TLS-Extractor. I think this is cryptographically suspect, and TE should have its own MS, derived from hMS after EncryptedExtensions (but before ServerFinished). Also, if MS for data in both directions are split from each other (needed for update-rekey), I think keys for directions should be derived at respective Finished messages. - Allow server to send early data, even with pending authentication[2] (note: The client is _unidentified_, not just unauthenticated)[3] - Not having "not yet" keys around to potentially abuse[4]. Handshake protocol: Looks still to be SMACK-trap (duplicating information endpoint already needs to know and now also check). And yes, I think that recent events have shown that "what stupid things one can easily do with this?" is quite legimate concern (whitness multiple TLS implementations with the same types of issues as soon as anybody goes looking).[5] [1] I think MD5 should be deprecated (MNU) from HashAlgorithm and SHA-256 be promoted to default (AFAIK, currently SHA-1). [2] Useful for protocol banners and such (ALPN does not scale!) [3] Unidentified peer seemingly makes it quite a bit harder to do anything stupid than unauthenticated. [4] Deriving just before finished does create such "not yet" keys. [5] Also update-auth, even allowed just once can be accidentially used in very bad ways in certain kinds of protocols and environments. -Ilari From nobody Tue Mar 10 04:09: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 01DF51A8799 for ; Tue, 10 Mar 2015 04:09:20 -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 B5ux-rPs5Wgy for ; Tue, 10 Mar 2015 04:09:13 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 3955E1A8769 for ; Tue, 10 Mar 2015 04:09:13 -0700 (PDT) Received: by wibbs8 with SMTP id bs8so1921549wib.4 for ; Tue, 10 Mar 2015 04:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HZ+3epc4hb2rmR+dYFkuqOn3YLblKBA/fdHdv1EAWE4=; b=RGQgVv3WRl8lHfzhIk7aENmY9Lgox+PhyQCO5pspgtk7lxhOCcGCwvBwFx1TcKtsyI 2+y+rZdwjNrU/3X2u64iQPX3BT5ZFqTU/UxoVrWgXAhuc5YExCnzuMgY4mKKwNxhoui+ KmUgfCcmLaYmBAkxIRoG06PKS6WvqcSl8zdt4OJy2JQPdLEyl+yMoAmNSHolhAJcMvQG bmHOkMuDDkGW6eVJpgeA0lxSVxjplBapJlFBiPaq4fDcPK12535XZrk0uyNZduCKcTbW AseNlNJSVyi524oIlpQM69Xja9Eupf1unql3iEF9x0s/Vg/v3zZttlExOBuwTMnZ0NSJ S43g== X-Received: by 10.180.211.73 with SMTP id na9mr60468733wic.60.1425985751807; Tue, 10 Mar 2015 04:09:11 -0700 (PDT) Received: from [172.24.249.226] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id u16sm416699wjr.5.2015.03.10.04.09.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 04:09:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A9E26167-DCF9-4AC3-B4D4-61BBF2F7C362" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <54FEA30C.6080608@bouncycastle.org> Date: Tue, 10 Mar 2015 13:09:08 +0200 Message-Id: References: <20150309212339.6861.62405.idtracker@ietfa.amsl.com> <54FEA30C.6080608@bouncycastle.org> To: Peter Dettman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 11:09:20 -0000 --Apple-Mail=_A9E26167-DCF9-4AC3-B4D4-61BBF2F7C362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Actually only the last one has issues. Tthe full list should be: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA While there are _SHA256 versions for the second and forth ciphersuites, = these are pre-1.2 ciphersuites where the _SHA and _SHA256 refer to = HMAC-SHA1 and HMAC-SHA256 respectively as MAC functions. There is no = particular reason to switch to HMAC-SHA256, so we=92d rather stay with = the previous recommendation. Going forward (1.3+) only the GCM ciphersuites will be supported, so you = need those. Thanks. I=92ll fix it in the next version after the meeting. Yoav > On Mar 10, 2015, at 9:53 AM, Peter Dettman = wrote: >=20 > On the very last lineof "6. Cipher Suites", the list of cipher suites = that SHOULD be supported includes TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 = - is that a typo that should be ..._ECDHE_...? >=20 > In that same list, should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA be = ..._SHA256? >=20 > Regards, > Pete Dettman >=20 > On 10/03/2015 4:23 am, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Layer Security Working = Group of the IETF. >>=20 >> Title : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier >> Author : Yoav Nir >> Filename : draft-ietf-tls-rfc4492bis-02.txt >> Pages : 30 >> Date : 2015-03-09 >>=20 >> Abstract: >> This document describes key exchange algorithms based on Elliptic >> Curve Cryptography (ECC) for the Transport Layer Security (TLS) >> protocol. In particular, it specifies the use of Ephemeral = Elliptic >> Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and = the >> use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new >> authentication mechanism. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 --Apple-Mail=_A9E26167-DCF9-4AC3-B4D4-61BBF2F7C362 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Actually only the last one has issues. Tthe full list should = be:

   o =  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  =  o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   o =  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  =  o  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

While there are _SHA256 =  versions for the second and forth ciphersuites, these are pre-1.2 = ciphersuites where the _SHA and _SHA256 refer to HMAC-SHA1 and = HMAC-SHA256 respectively as MAC functions. There is no particular reason = to switch to HMAC-SHA256, so we=92d rather stay with the previous = recommendation.

Going forward (1.3+) only the GCM ciphersuites will be = supported, so you need those.

Thanks. I=92ll fix it in the next = version after the meeting.

Yoav

On Mar 10, 2015, at 9:53 AM, Peter Dettman = <peter.dettman@bouncycastle.org> wrote:
On the very last lineof "6. Cipher Suites", the list of = cipher suites that SHOULD be supported includes = TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 - is that a typo that should = be ..._ECDHE_...?

In that same list, = should TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA be ..._SHA256?
Regards,
Pete Dettman

On 10/03/2015 4:23 am, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the = on-line Internet-Drafts directories.
 This draft is a = work item of the Transport Layer Security Working Group of the IETF.

        Title   =         : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Author       =    : Yoav Nir
Filename       =  : draft-ietf-tls-rfc4492bis-02.txt
Pages =           : 30
Date =            : 2015-03-09

Abstract:
   This document describes = key exchange algorithms based on Elliptic
  =  Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the = use of Ephemeral Elliptic
   Curve = Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature = Algorithm (ECDSA) as a new
   authentication = mechanism.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/=

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-02

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-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/

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


= --Apple-Mail=_A9E26167-DCF9-4AC3-B4D4-61BBF2F7C362-- From nobody Tue Mar 10 07:08: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 5DBCC1A87E2 for ; Tue, 10 Mar 2015 07:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtpxYb7K8PXC for ; Tue, 10 Mar 2015 07:08:28 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.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 7BFDC1A87C4 for ; Tue, 10 Mar 2015 07:08:28 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so1702989obc.10 for ; Tue, 10 Mar 2015 07:08: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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WVY90A47R2TzROm6gS7jfR6tqj2Z3PzuBIdrZeqPQdA=; b=NfmlnXssg0LLMWnRslMJM7mzFUczjZmGrZuhxtHLDt/zvfV1LJ/ZiGMHKGTLjN4AIj bqpC88+iqdnJKfUrN5wGlMED1sa+HuWrYpmaplJ4gpJW1Lk4jXwP/W0c4D2Ed95imT7y Tw8XrECri/WG5jXZ7HK4KwQqHM0lyFZ1AybtH5IKPaZ9z1/9i60z8X4QYk3jnNFSd9sx HtMWcjsQ1lfaNL2kgkny3vKqG4/zJnt7HEneCTQAMh28o0fwJ/780sR2ERCc4GHBxloJ nSGU0396BA2qIpJuv+pbi1tawqOgSOsQjNlNgsCk+GY3sN1oNKsGznM63AZ+xIbobHQd 4r5g== X-Gm-Message-State: ALoCoQkLXfj3TgvMywYz80kZvLdQ6JtD7oUKpB3iHKe8pD1xfPsXNi6cjos5oCsYAsFw+hp7/cAz MIME-Version: 1.0 X-Received: by 10.182.24.202 with SMTP id w10mr26482942obf.9.1425996508009; Tue, 10 Mar 2015 07:08:28 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Tue, 10 Mar 2015 07:08:27 -0700 (PDT) In-Reply-To: <201503081339.47927.davemgarrett@gmail.com> References: <201503081339.47927.davemgarrett@gmail.com> Date: Tue, 10 Mar 2015 07:08:27 -0700 Message-ID: From: Brian Smith To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:08:33 -0000 Dave Garrett wrote: > A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+= . It'll be needed to handle draft implementations, if desired, and I think = it might just be wanted for all negotiation. TLS 1.3 version intolerance is= currently surveyed to be in the ~1.5% range [1]. The simplest method is to= do so via a new mandatory extension, as has been suggested by people befor= e. I agree that that seems like the best way forward. > struct { > uint8 versions<0..2^8-1>; > } SupportedVersions; > > where versions contains an ordered list of the supported TLS minor versio= ns. 1. Nit: It seems unnecessary to wrap a single data item in a struct. 2. I don't see why, for non-draft versions at least, the client needs to tell the server about any version it supports other than the newest version. It is not good to indicate support for older (worse) versions unnecessarily. Particularly for clients that support non-secure fallback, it is not good to tell the MitM the weakest version that the client would fall back to. I suggest that you change the definition of the client extension value to be just: ProtocolVersion client_version; which would be specified exactly like ClientHello.client_version is specifi= ed. > A block of numbers would be reserved for draft versions. (e.g. ID 32+ for= drafts) I don't think it is worth making the main version negotiation mechanism more complicated and error-prone just to support advertising draft versions. There could be a draft_subversion extension that could be used to indicate support for a draft revision of the version indicated in the client_version extension instead. > The ClientHello.version in this negotiation mechanism would be frozen to = {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2. I suggest also renaming ClientHello.client_version to ClientHello.always_0x03_0x03 to avoid confusion. > Clients could set this to {0,0} to force only the new mechanism with > no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are > all undesirable). { 0, 0 } would probably have even more issues with TLS intolerance than we've historically experienced. AFAICT, this "forcing" feature is not necessary so I suggest you just drop it. > Additionally, I propose dropping the TLSCiphertext.version field entirely= . I suggest doing that separately as its own proposal. > 2) This method allows for non-continuous version support to be negotiated= . > (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate= 1.3 instead of trying unsupported 1.4) We don't need this. > 3) Draft implementations would be easily negotiable using the same method= as release. That is a plus, but the added complexity on non-draft implementations is worse than the benefit. > 4) Client implementations are not encouraged to go back to the old habit = of insecure fallback, nor rely on SCSV for TLS 1.3+. Right. This is the primary motivation for moving ClientHello.client_version to an extension. > 5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Mic= rosoft could tolerate. They don't like SCSV as-is [3], and I tend to agree = with their sentiment. It doesn't seem worth making the protocol more complicated to facilitate performance optimizations of bad behavior. > 6) In the event of handshake failure due to an unsuitable version selecte= d by the server, the client will have received a SupportedVersions set from= the server to know exactly what is and is not supported. Only if the client is negotiating TLS 1.4 or later and the server supports at least TLS 1.3. IMO, not worth it. Anyway, I support your proposal, if it is simplified. Cheers, Brian From nobody Tue Mar 10 07:45: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 62A131A88D7 for ; Tue, 10 Mar 2015 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymc9lc59zQ-t for ; Tue, 10 Mar 2015 07:44:56 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id 978BF1A87ED for ; Tue, 10 Mar 2015 07:44:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-49-237-11-14.revip6.asianet.co.th; Message-ID: <54FF0359.1050906@bouncycastle.org> Date: Tue, 10 Mar 2015 21:44:41 +0700 From: Peter Dettman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150309195629.7516.46362.idtracker@ietfa.amsl.com> In-Reply-To: <20150309195629.7516.46362.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: [TLS] Comment on draft-ietf-tls-session-hash-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:45:03 -0000 Hi, I've mentioned this a while back, but I am still curious what is the reasoning to require the ServerHello in an abbreviated (accepted resumption) handshake to include the extended_master_secret extension? (see section 5.3, last bullet point). Searching the list for relevant comments, I found these: Myself (Aug 26): don't send the extension Yoav Nir (Nov 24): I would go for the less meaningless bytes option. Adam Langley (Nov 24): let's say that the server SHOULD NOT echo it Eric Rescorla (Jan 16): The server MUST NOT echo it? Martin Thompson (Jan 16): I think that I'd prefer to have the server echo the extension in this case too. Eric Rescorla (Jan 16): I could live with this as well. So, a bob each way, but there wasn't much in the way of discussion as to why (at least on-list). The only extension I am aware of that is normally required in the ServerHello of an abbreviated handshake is renegotiation_info (RFC 5746). There is justification for doing so, since "secure_renegotiation" is a connection-specific flag, not a session parameter. I don't really see any special justification for it in the case of extended_master_secret. If a client tries to resume a (EMS) session, and includes the extension in ClientHello as required, and the server resumes, then what's missing that is fixed by requiring the ServerHello extension as well? Also, why SHOULD resumption of an (EMS) session fail if the client doesn't include the extension? Section 5.3, second list item: If the new ClientHello does not contain the "extended_master_secret" extension, the server SHOULD fall back to a full handshake by sending a ServerHello that rejects the offered session but continues with a full handshake. If it continues with an abbreviated handshake the considerations in Section 5.4 apply. So the server SHOULD pick the (all else being equal) less-secure, more-expensive of the two options the client proposed? There are of course precedents for similar requirements, e.g. that the offered cipher_suites/compression_methods must contain the session-selected values in order for a session to be resumable, but again, there's a justification for that: the client can't resume the session if it doesn't support the algorithms needed to "run" it. That doesn't seem applicable to extended_master_secret. Regards, Pete Dettman On 10/03/2015 2:56 am, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension > Authors : Karthikeyan Bhargavan > Antoine Delignat-Lavaud > Alfredo Pironti > Adam Langley > Marsh Ray > Filename : draft-ietf-tls-session-hash-04.txt > Pages : 14 > Date : 2015-03-09 > > Abstract: > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > server certificate. Consequently, it is possible for an active > attacker to set up two sessions, one with a client and another with a > server, such that the master secrets on the two sessions are the > same. Thereafter, any mechanism that relies on the master secret for > authentication, including session resumption, becomes vulnerable to a > man-in-the-middle attack, where the attacker can simply forward > messages back and forth between the client and server. This > specification defines a TLS extension that contextually binds the > master secret to a log of the full handshake that computes it, thus > preventing such attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-session-hash-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 10 08:53: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 AC8211A06FD for ; Tue, 10 Mar 2015 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxT8kZa1WQGx for ; Tue, 10 Mar 2015 08:53:01 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7251A0027 for ; Tue, 10 Mar 2015 08:53:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,375,1422918000"; d="asc'?scan'208";a="125260069" Received: from 162.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.162]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 10 Mar 2015 16:52:59 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8BA99568-A0DB-4B57-9478-5F0FA65D7776"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Karthikeyan Bhargavan In-Reply-To: <54FF0359.1050906@bouncycastle.org> Date: Tue, 10 Mar 2015 16:52:57 +0100 Message-Id: <24375A0D-C419-4AEF-9CB7-9BC8E5D684D2@inria.fr> References: <20150309195629.7516.46362.idtracker@ietfa.amsl.com> <54FF0359.1050906@bouncycastle.org> To: Peter Dettman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Comment on draft-ietf-tls-session-hash-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:53:03 -0000 --Apple-Mail=_8BA99568-A0DB-4B57-9478-5F0FA65D7776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 These are good points. We went back and forth over when editing the = text. I would have been happy to say that if the original session uses an = extended_master_secret, then neither the ClientHello nor the ServerHello need to use the = extension. However, some might feel that it is bizarre for a client or server that = originally proposed the extension to not use the extension during resumption. Which is why I left it at SHOULD (to be, as you note, consistent with other resumption requirements like using the same cipher suite.) I=92ll let others weigh in on this choice. See and comment also on the related last paragraph of 5.4. On 10 Mar 2015, at 15:44, Peter Dettman = wrote: > Hi, >=20 > I've mentioned this a while back, but I am still curious what is the = reasoning to require the ServerHello in an abbreviated (accepted = resumption) handshake to include the extended_master_secret extension? = (see section 5.3, last bullet point). >=20 > Searching the list for relevant comments, I found these: >=20 > Myself (Aug 26): don't send the extension >=20 > Yoav Nir (Nov 24): I would go for the less meaningless bytes = option. > Adam Langley (Nov 24): let's say that the server SHOULD NOT echo it >=20 > Eric Rescorla (Jan 16): The server MUST NOT echo it? > Martin Thompson (Jan 16): I think that I'd prefer to have the = server echo the extension in this case too. > Eric Rescorla (Jan 16): I could live with this as well. >=20 >=20 > So, a bob each way, but there wasn't much in the way of discussion as = to why (at least on-list). >=20 > The only extension I am aware of that is normally required in the = ServerHello of an abbreviated handshake is renegotiation_info (RFC = 5746). There is justification for doing so, since "secure_renegotiation" = is a connection-specific flag, not a session parameter. >=20 > I don't really see any special justification for it in the case of = extended_master_secret. If a client tries to resume a (EMS) session, and = includes the extension in ClientHello as required, and the server = resumes, then what's missing that is fixed by requiring the ServerHello = extension as well? >=20 > Also, why SHOULD resumption of an (EMS) session fail if the client = doesn't include the extension? Section 5.3, second list item: >=20 > If the new ClientHello does not contain the > "extended_master_secret" extension, the server SHOULD fall back = to > a full handshake by sending a ServerHello that rejects the = offered > session but continues with a full handshake. If it continues = with > an abbreviated handshake the considerations in Section 5.4 apply. >=20 > So the server SHOULD pick the (all else being equal) less-secure, = more-expensive of the two options the client proposed? >=20 > There are of course precedents for similar requirements, e.g. that the = offered cipher_suites/compression_methods must contain the = session-selected values in order for a session to be resumable, but = again, there's a justification for that: the client can't resume the = session if it doesn't support the algorithms needed to "run" it. That = doesn't seem applicable to extended_master_secret. >=20 > Regards, > Pete Dettman >=20 > On 10/03/2015 2:56 am, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Layer Security Working = Group of the IETF. >>=20 >> Title : Transport Layer Security (TLS) Session Hash = and Extended Master Secret Extension >> Authors : Karthikeyan Bhargavan >> Antoine Delignat-Lavaud >> Alfredo Pironti >> Adam Langley >> Marsh Ray >> Filename : draft-ietf-tls-session-hash-04.txt >> Pages : 14 >> Date : 2015-03-09 >>=20 >> Abstract: >> The Transport Layer Security (TLS) master secret is not >> cryptographically bound to important session parameters such as = the >> server certificate. Consequently, it is possible for an active >> attacker to set up two sessions, one with a client and another = with a >> server, such that the master secrets on the two sessions are the >> same. Thereafter, any mechanism that relies on the master secret = for >> authentication, including session resumption, becomes vulnerable = to a >> man-in-the-middle attack, where the attacker can simply forward >> messages back and forth between the client and server. This >> specification defines a TLS extension that contextually binds the >> master secret to a log of the full handshake that computes it, = thus >> preventing such attacks. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-tls-session-hash-04 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-session-hash-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_8BA99568-A0DB-4B57-9478-5F0FA65D7776 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU/xNaAAoJEB/WSo9veuUKp/kIAIchvz56t6HXD1w9KRsYsjvY Nz19IN6qzTSlwT533luEnBfbwNeFTIsaoiREvavwptDWExR3tJ/gjDXzUJEPMr3U zsuDlhHF4bJzs6yi4iRI8ybVat6YY6NA6OwbpXoyWkCfzdxh/HXWiDmwS9wjWz9y 96B1ltcYcNQhAbqThBggu5hY9SIT6Ma6HIFzyxiy9fyG9OrIVftz5jVKkYdCuejc /LW5AeKa7MAxft+ewI0ujwmvmCyUJ+cYk1J9w9yWWrIiHbsoNLIuYiFGa94N0YvQ CeEqVdTvHkjT+pFwAhOEvzKecMpMoGySlqzo4IyFjM4KEoWxgaVv31W92MugUd0= =wfui -----END PGP SIGNATURE----- --Apple-Mail=_8BA99568-A0DB-4B57-9478-5F0FA65D7776-- From nobody Tue Mar 10 09: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 18B291A00E4 for ; Tue, 10 Mar 2015 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67UK-jYmabSC for ; Tue, 10 Mar 2015 09:43:18 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::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 C16B41A005B for ; Tue, 10 Mar 2015 09:43:17 -0700 (PDT) Received: by labge10 with SMTP id ge10so3016470lab.7 for ; Tue, 10 Mar 2015 09:43: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:content-transfer-encoding; bh=t20TzrA2xQF366vdBlWfM9vT8qbj7cbiZyxcCW8djGc=; b=lBnRcBNN9Jn51Xi6/gHtQG3rL7gyqyjpygou9wBEhbjLtysLVJ/MDsCuIvWo9x2VH3 jzwpC5q4Rg0oY+GI+c1WNzQa79vaj2raNVkKuPxHzFWPL1T1xKzwdC7M/sDu4EKcGqY/ 8Sc2/8VOqasbe21TAZJJ25J68IlBYa4Z5cnCzvC3AICWz1FZQPnTf4g9nctbSSSi0zl6 HDOCfgmaliVISeZf7+JgSVFSzqr2hlsLrcTVI3yqwjFBn8RiZoWhPE16eoz3QvMBKf4I 8QTYRBotx9jy00s2E3sSHOm65CdL8NSlYdtUB8Q6HCtMR43PfHvM+a+91AcA7LR9zafO gXrg== MIME-Version: 1.0 X-Received: by 10.152.5.6 with SMTP id o6mr31658866lao.59.1426005796105; Tue, 10 Mar 2015 09:43:16 -0700 (PDT) Received: by 10.112.204.5 with HTTP; Tue, 10 Mar 2015 09:43:16 -0700 (PDT) In-Reply-To: <54FF0359.1050906@bouncycastle.org> References: <20150309195629.7516.46362.idtracker@ietfa.amsl.com> <54FF0359.1050906@bouncycastle.org> Date: Tue, 10 Mar 2015 17:43:16 +0100 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: Peter Dettman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comment on draft-ietf-tls-session-hash-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:43:22 -0000 On Tue, Mar 10, 2015 at 3:44 PM, Peter Dettman wrote: > Hi, > > I've mentioned this a while back, but I am still curious what is the > reasoning to require the ServerHello in an abbreviated (accepted resumpti= on) > handshake to include the extended_master_secret extension? (see section 5= .3, > last bullet point). [...] > Also, why SHOULD resumption of an (EMS) session fail if the client doesn'= t > include the extension? Section 5.3, second list item: Because it is best practice to send the same extensions in an attempted resumption ClientHello as in a normal ClientHello. Consider the case where the server doesn't remember the session id. FYI: My server-side implementation of TLS performs the same extension handling and protocol selection for resumption attempts as for normal ClientHellos, and then validates that the resulting session parameters are equivalent with the cached session before actually deciding to resume the session. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Tue Mar 10 10:27: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 5F82D1A00F5 for ; Tue, 10 Mar 2015 10:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaWfanaRYQ6H for ; Tue, 10 Mar 2015 10:27:26 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::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 4A8801A0019 for ; Tue, 10 Mar 2015 10:27:26 -0700 (PDT) Received: by qcvs11 with SMTP id s11so3676548qcv.7 for ; Tue, 10 Mar 2015 10:27:25 -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=kih0wBKtuRl7SjX53kKGesJAgu+9vjXOJve/8mZR9qA=; b=A33ofX68k8AS/GzrCnIsva5ycCke8aWQCQ3CNYYKiyunaEJhuva8JtAriQByN7Vaob fmE9mpu9kT4lz6jsOafV0ZYD10j28BM0rpakl10bUMhkBfzZ0nEWvgHMFiIUQnz1RPf5 c5h+IG5qwR3jTImGHRmrKtRmtpbQyCpmIsXyP1yvghBtFt7v/IOcXeN2Y1DRrGuWlKj7 jGk25jjmvCSgxb5an7Y4eIH3IdKS1EV7osEppNZ1Xp+YH7Wl3jsD2ySAAvpLhwiZE/NG TDlifBPR5G180JVN5bvyXv4LBcNgfVJ+FCamJyyYVjjOO/BB9r+kn54W5POdCAP+QTdn PcYQ== X-Received: by 10.140.165.209 with SMTP id l200mr44207433qhl.84.1426008445593; Tue, 10 Mar 2015 10:27:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b52sm782267qgb.16.2015.03.10.10.27.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Mar 2015 10:27:25 -0700 (PDT) From: Dave Garrett To: Brian Smith Date: Tue, 10 Mar 2015 13:27:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081339.47927.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503101327.24072.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:27:28 -0000 Thanks for the feedback. On Tuesday, March 10, 2015 10:08:27 am Brian Smith wrote: > Dave Garrett wrote: > 1. Nit: It seems unnecessary to wrap a single data item in a struct. Just following the general style of some other extensions. Technically, each index of extension_data itself could be used as-is without wrapping, but specifying it generically seems best. > 2. I don't see why, for non-draft versions at least, the client needs > to tell the server about any version it supports other than the newest > version. It is not good to indicate support for older (worse) versions > unnecessarily. Particularly for clients that support non-secure > fallback, it is not good to tell the MitM the weakest version that the > client would fall back to. I did list that as one reason to consider against this. My argument is that: 1) If we're replacing the version negotiation, we should make it better instead of merely kludging around intolerance. 2) No TLS 1.3+ client should be supporting insecure fallback AT ALL. This is a hard requirement for this. 3) Using an entirely different mechanism for draft and release could be prone to mistake. Better to test early. > I don't think it is worth making the main version negotiation > mechanism more complicated and error-prone just to support advertising > draft versions. There could be a draft_subversion extension that could > be used to indicate support for a draft revision of the version > indicated in the client_version extension instead. My initial idea was to have two essentially identical extensions, but with a different ID for release and draft. However, as I said above, this feels more complicated than needed and I'd rather just use one consistent mechanism for everything. Reserving part of the ID space for draft is not that complicated. It'd just be essentially turning the field into an enum value. > > The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2. > > I suggest also renaming ClientHello.client_version to > ClientHello.always_0x03_0x03 to avoid confusion. Renaming fields for clarity makes sense. > > Clients could set this to {0,0} to force only the new mechanism with > > no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are > > all undesirable). > > { 0, 0 } would probably have even more issues with TLS intolerance > than we've historically experienced. AFAICT, this "forcing" feature is > not necessary so I suggest you just drop it. It's to deal with a specific issue I thought of just before sending the email. If a client considers TLS 1.0-1.2 to be unsafe and attempts a connection of TLS 1.3+, then TLS 1.2 servers will still respond with ServerHellos due to the frozen field. Clients would have to essentially fake offers and abort on TLS 1.2. Any new mechanism should not have oddities like this that can't be resolved properly. Server TLS version intolerance is essentially fine in the TLS 1.3+ only case. An abort instead of reject is fine. There could be issues with crap in the middle, though, yes. This is essentially just a contingency that I think needs to be stated, but might never be needed. > > Additionally, I propose dropping the TLSCiphertext.version field entirely. > > I suggest doing that separately as its own proposal. Yep. Just bringing it up here too. > > 2) This method allows for non-continuous version support to be negotiated. > > (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4) > > We don't need this. If TLS actually puts out more iterations, then we do, and this could make negotiating more frequent iterations easier. If TLS 1.3 or 1.4 is the final version, then we don't. For draft versions, though, it could really be useful. Think ALPN/NPN; HTTP/2 draft negotiation would not have worked very well without the ability to list multiple specific versions at once. > > 3) Draft implementations would be easily negotiable using the same method as release. > > That is a plus, but the added complexity on non-draft implementations > is worse than the benefit. Again, it depends on how long until TLS ends. If TLS intends to go up to 1.9+, then I think it's quite worth it. If TLS ends soon and everyone transitions to a TCP-replacement with a new security layer, then no, this could be too complex. To start, though, I decided to propose the full generic route. > > 4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+. > > Right. This is the primary motivation for moving > ClientHello.client_version to an extension. > > > 5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment. > > It doesn't seem worth making the protocol more complicated to > facilitate performance optimizations of bad behavior. > > > 6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not supported. > > Only if the client is negotiating TLS 1.4 or later and the server > supports at least TLS 1.3. IMO, not worth it. Again, it depends on how much further TLS actually goes. Draft versions could also benefit more. > Anyway, I support your proposal, if it is simplified. If simplified to just a move of the field, I'd be more likely to propose just coordinating a block of the ~1.6% of the Internet that can't negotiate properly and keep the old mechanism. The only reason I agree a simplified version of this could be needed is that I don't believe implementers have the guts to do this properly. :/ A notable part of the Web really does warrant breaking, but nobody wants to do it. Dave From nobody Tue Mar 10 17:33: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 E8B601A8AC2 for ; Tue, 10 Mar 2015 17:33: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 5sirmpfCW8wF for ; Tue, 10 Mar 2015 17:33:46 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::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 3D4B71A8940 for ; Tue, 10 Mar 2015 17:33:46 -0700 (PDT) Received: by yhzz6 with SMTP id z6so2766387yhz.3 for ; Tue, 10 Mar 2015 17:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WZwV1EnGDznVn0GvqKHcd6huAkdf7XsDAkSaV1GsQ54=; b=TPDoBPAVhwoo/B5Mt809vUv0qjIz+rKfFvyimKELEa62ny3lwGFkH531JJqhgzfMTJ TTPz3E5tKQKwR2HM+GVR8ePNBaXypzym2/fhX+nTsQUoAiwLbbbTm93P4dUhlUGEtJ99 wtyHes2FIgsuFlXmcajgM6WH43HRvWtscrMsM2MC5rJK57qABT+eDYHEps0YQL3afLKR nQPjPg4kPraS9/OtKfRgIvImnvOANBLRbQnSLVJjIrXEvQEriFglDoAgg74FB9dzUmQx Ewb6IJjPL3v1OFYThK2IBqTiuZyGkPLIxYlbeQx7WnQWhiaaTdJAZfsPnqyOzEBt0At5 KVQQ== MIME-Version: 1.0 X-Received: by 10.236.1.38 with SMTP id 26mr34413514yhc.163.1426034025637; Tue, 10 Mar 2015 17:33:45 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Tue, 10 Mar 2015 17:33:45 -0700 (PDT) In-Reply-To: <201503091911.17254.davemgarrett@gmail.com> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091821.41393.davemgarrett@gmail.com> <20150309223806.GA3923@typhoon.azet.org> <201503091911.17254.davemgarrett@gmail.com> Date: Tue, 10 Mar 2015 17:33:45 -0700 Message-ID: From: Watson Ladd To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1132e9ca892f2d0510f86b0c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:33:48 -0000 --001a1132e9ca892f2d0510f86b0c Content-Type: text/plain; charset=UTF-8 On Mar 9, 2015 4:11 PM, "Dave Garrett" wrote: > > On Monday, March 09, 2015 06:38:08 pm Aaron Zauner wrote: > > In any case, people do argue that algorithmic agility causes more > > problems than it's worth. I agree somewhat, but IMHO at least one > > backup is a good idea > > I'd much rather have three than two. (not counting deprecated ciphers/modes) I think of it in this way: if one were to vanish, there would still be a choice left. With only two chosen ones, then a fatal attack on one brings us all the way back to the one-true-cipher again. > > If you assume eventual failure, a secondary backup is very desirable. Both AES-CCM and AES-GCM have security reducing to that of AES as a PRP. So they aren't actually independent backups. The issue is that extremely limited hardware may only support AES-CCM. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1132e9ca892f2d0510f86b0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 9, 2015 4:11 PM, "Dave Garrett" <davemgarrett@gmail.com> wrote:=
>
> On Monday, March 09, 2015 06:38:08 pm Aaron Zauner wrote:
> > In any case, people do argue that algorithmic agility causes more=
> > problems than it's worth. I agree somewhat, but IMHO at least= one
> > backup is a good idea
>
> I'd much rather have three than two. (not counting deprecated ciph= ers/modes) I think of it in this way: if one were to vanish, there would st= ill be a choice left. With only two chosen ones, then a fatal attack on one= brings us all the way back to the one-true-cipher again.
>
> If you assume eventual failure, a secondary backup is very desirable.<= /p>

Both AES-CCM and AES-GCM have security reducing to that o= f AES as a PRP. So they aren't actually independent backups. The issue = is that extremely limited hardware may only support AES-CCM.

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

--001a1132e9ca892f2d0510f86b0c-- From nobody Tue Mar 10 18:12: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 662591A9124 for ; Tue, 10 Mar 2015 18:12: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 QOJxCEPVh3dQ for ; Tue, 10 Mar 2015 18:12:14 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::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 10F041A8782 for ; Tue, 10 Mar 2015 18:12:14 -0700 (PDT) Received: by qcwr17 with SMTP id r17so6762905qcw.2 for ; Tue, 10 Mar 2015 18:12:13 -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=BEYvyfE3MsrQ187wvJOVUHfGUH1MXDokcUblYlCom+c=; b=TYh406HW9LMQHO1Idwn0zqQPDsyFrvdOLsIlrSK9bX2OmfFQOMG6fYyU/pJnxT5+mO g6IhewnFsB2SVxOmBtghKDBBIy1nn3ZYD8oN+ADTUyI1pSpSM8mIDny0aMrg7foNgWAL ID7BrMK50/TCvRkPzh2+7pbpdV84kllAVm7qyZrWDaueFdguwYKlsNejKnv58Nco87sZ 0DgsVqakYTA+ii+0wl2iI0Dy9BLe3vv+TDdyCD/CTDKfIqpovqIpIoA5zhgoSk4OXxU4 nwwNdlFX11+B/ZskpVq9J6l8/lRR9hhT4dIXudE5LbfAPbeUvOAZbxU9NCECA36b+38r 5/Bg== X-Received: by 10.55.15.159 with SMTP id 31mr15446716qkp.29.1426036333199; Tue, 10 Mar 2015 18:12:13 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id a73sm1587257qka.0.2015.03.10.18.12.12 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Mar 2015 18:12:12 -0700 (PDT) From: Dave Garrett To: Watson Ladd Date: Tue, 10 Mar 2015 21:12:09 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local> <201503091911.17254.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503102112.09880.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:12:15 -0000 On Tuesday, March 10, 2015 08:33:45 pm Watson Ladd wrote: > On Mar 9, 2015 4:11 PM, "Dave Garrett" wrote: > > On Monday, March 09, 2015 06:38:08 pm Aaron Zauner wrote: > > > In any case, people do argue that algorithmic agility causes more > > > problems than it's worth. I agree somewhat, but IMHO at least one > > > backup is a good idea > > > > I'd much rather have three than two. (not counting deprecated > > ciphers/modes) I think of it in this way: if one were to vanish, there > > would still be a choice left. With only two chosen ones, then a fatal > > attack on one brings us all the way back to the one-true-cipher again. > > > > If you assume eventual failure, a secondary backup is very desirable. > > Both AES-CCM and AES-GCM have security reducing to that of AES as a PRP. So > they aren't actually independent backups. The issue is that extremely > limited hardware may only support AES-CCM. Yes, to be clear, I'm saying we'd ideally want an ecosystem with 3 ciphers, not 3 cipher suites. (the discussion drifted and the words are fuzzy) Too few results in failing back to a risky point, and too many risks fragmenting cipher support and interop too much. Referencing the whole zoo of newer AES AEAD modes in the TLS 1.3 spec is probably worthwhile, but picking just one for MTI probably means GCM. Hey, if we can do ~another~ MTI, we could go: Chacha/Poly + AES-GCM + one other AES mode, all MTI, with Chacha/Poly as MTD. Dave From nobody Tue Mar 10 22:19: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 979081A0121 for ; Tue, 10 Mar 2015 22:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6A8KnrF2OiV for ; Tue, 10 Mar 2015 22:19:22 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6BB1A01D5 for ; Tue, 10 Mar 2015 22:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426051162; x=1457587162; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HeWZTHaZyFzKS7eBi6uCZLu85UyFr4uXCnJNpK+HE7M=; b=hYeVqEbwhS/lr69+id7KpjNPJnb1HTVVJ0AWGjSiOAiKcYBFrh/ZWQOD NNGBz4b+V9wEPa3AagvHH7+slW8f0bqn8vDJbHtepNtcCT122rDZ8OdwK 1hM1j1T9O4oU32LMQz3eR3A6h8hIbCKYJMNUj8lSbPgo60p3b/hW7GrSh M=; X-IronPort-AV: E=Sophos;i="5.11,379,1422874800"; d="scan'208";a="312779946" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Mar 2015 18:18:56 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Wed, 11 Mar 2015 18:18:45 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) Thread-Index: AdBbutj/GQoOkX6CQ860U24KvSczcQ== Date: Wed, 11 Mar 2015 05:18:45 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 05:19:26 -0000 Ilari Liusvaara writes:=0A= =0A= >Backwards compatibility:=0A= >=0A= >Is this about what is needed for compatiblity with past TLS versions?=0A= =0A= TLS 1.3, which I've already pointed out several times has so little backwar= ds=0A= compatibility that it should be called TLS 2.0, doesn't need to be hamstrun= g=0A= with retaining stuff from the other TLS 1.x versions, for example the total= ly=0A= pointless:=0A= =0A= >- The first byte of record header needs to remain subprotocol id (for=0A= > muxing TLS with other stuff)=0A= =0A= (and many others). It's already so different even to TLS 1.2 that there's = no=0A= point in retaining some crufty old artefact of SSL 3.0 just because we've= =0A= always done it this way. If there's a feature that's useful or important t= o=0A= the functioning of the protocol then by all means include it, but there's n= o=0A= point in dragging along old protocol misfeatures "for backwards compatibili= ty"=0A= when so much else has changed incompatibly.=0A= =0A= Peter.= From nobody Wed Mar 11 02:15: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 EC46A1A6F3C for ; Wed, 11 Mar 2015 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0PJidv3i0DTT for ; Wed, 11 Mar 2015 02:15:18 -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 863A41A1A7D for ; Wed, 11 Mar 2015 02:15:18 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id DA47E1887BD; Wed, 11 Mar 2015 11:15:15 +0200 (EET) Date: Wed, 11 Mar 2015 11:15:15 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20150311091515.GA15123@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 09:15:21 -0000 On Wed, Mar 11, 2015 at 05:18:45AM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >Backwards compatibility: > > > >Is this about what is needed for compatiblity with past TLS versions? > > TLS 1.3, which I've already pointed out several times has so little backwards > compatibility that it should be called TLS 2.0, doesn't need to be hamstrung > with retaining stuff from the other TLS 1.x versions, for example the totally > pointless: Here by backwards compatiblity, I interpret: "Possiblity to securely downnegotiate to earlier versions without reconnect." This has the following implications: - TLS 1.2 servers have to be able to interpret the TLS 1.3 first flight in a sane way, so handshake can continue. - TLS 1.3 clients have to be able to interpret the TLS 1.2 first flight in a sane way, so handshake can continue. Not doing this is basically either a major security hole or serious deployment obstacle. > >- The first byte of record header needs to remain subprotocol id (for > > muxing TLS with other stuff) > > (and many others). It's already so different even to TLS 1.2 that there's no > point in retaining some crufty old artefact of SSL 3.0 just because we've > always done it this way. If there's a feature that's useful or important to > the functioning of the protocol then by all means include it, but there's no > point in dragging along old protocol misfeatures "for backwards compatibility" > when so much else has changed incompatibly. There actually are _protocols_ that _break_ if TLS ever generates first byte of record that isn't on certain range (20-63 / 0x14-0x3F), and that is the only non-abstract requirement (not easily re-definable by TLS). Radical handshake changes are OK. Or protocols that break if TLS ever starts the connection with byte that isn't 0x16 (but this is also required by "backward compatiblity" as defined above). E.g. Redefine what record type 0x17 (which is appdata in TLS 1.2) means? Sure, no problem. Drop 0x14 (ChangeCipherSpec)? No problemo. Enable encryption in the middle of hanshake? Ditto. -Ilari From nobody Wed Mar 11 08:17: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 D21DA1A8860 for ; Wed, 11 Mar 2015 08:16: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 nOTndFZ4Z8N8 for ; Wed, 11 Mar 2015 08:16:57 -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 44A351A877E for ; Wed, 11 Mar 2015 08:16:54 -0700 (PDT) Received: by ykr79 with SMTP id 79so4275572ykr.13 for ; Wed, 11 Mar 2015 08:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TWKsybH/VtHMRm0FpEa3CkARrD2mkpggYYgLiKwgJfE=; b=rIzB9kSlM4nwo20KOL5ilrLTRd4B+7P43ls1SzgEdQo9QjSARlInGDDap6YrC0smT4 qJ/EqQ/po9slsz8NbgoRuK9ep43m4RJ7pIR17iKUxMQwKYkemOe3UmQFgExrenWOKCBz umVHxuxYZ7VS6UBkZZQ/551QOZ5uxLkWxwZFhl1qpvYO+zvpCqm6aL06T9XPWVM/Snzv a6Y+If3WphyNUENRvqfw1/3Tec33eXpcLT5jZm9m85n5F2Jq0E8ESys+q6ac355WLZoT 1RiPH3XgTzoILlulykPYMulS5Ifc5ZB1cNGV/lQ+Kt/GaqFBvJ4WNQhuQF2yP7LVdi+1 tCmQ== MIME-Version: 1.0 X-Received: by 10.236.63.6 with SMTP id z6mr37688321yhc.65.1426087013539; Wed, 11 Mar 2015 08:16:53 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Wed, 11 Mar 2015 08:16:53 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 11 Mar 2015 08:16:53 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: multipart/alternative; boundary=089e01294ff0dc64f8051104c17c Archived-At: Cc: "" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:16:59 -0000 --089e01294ff0dc64f8051104c17c Content-Type: text/plain; charset=UTF-8 On Mar 10, 2015 10:19 PM, "Peter Gutmann" wrote: > > Ilari Liusvaara writes: > > >Backwards compatibility: > > > >Is this about what is needed for compatiblity with past TLS versions? > > TLS 1.3, which I've already pointed out several times has so little backwards > compatibility that it should be called TLS 2.0, doesn't need to be hamstrung > with retaining stuff from the other TLS 1.x versions, for example the totally > pointless: > > >- The first byte of record header needs to remain subprotocol id (for > > muxing TLS with other stuff) > > (and many others). It's already so different even to TLS 1.2 that there's no > point in retaining some crufty old artefact of SSL 3.0 just because we've > always done it this way. If there's a feature that's useful or important to > the functioning of the protocol then by all means include it, but there's no > point in dragging along old protocol misfeatures "for backwards compatibility" > when so much else has changed incompatibly. I agree. We should focus in simplifying implementations of TLS 1.3 and TLS 1.2, and it seems that this means assuming minimal (read none) code reuse, and focusing on simplifying TLS 1.3 on its own terms. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e01294ff0dc64f8051104c17c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 10, 2015 10:19 PM, "Peter Gutmann" <pgut001@cs.auckland.ac.nz&g= t; wrote:
>
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> >Backwards compatibility:
> >
> >Is this about what is needed for compatiblity with past TLS versio= ns?
>
> TLS 1.3, which I've already pointed out several times has so littl= e backwards
> compatibility that it should be called TLS 2.0, doesn't need to be= hamstrung
> with retaining stuff from the other TLS 1.x versions, for example the = totally
> pointless:
>
> >- The first byte of record header needs to remain subprotocol id (= for
> >=C2=A0 muxing TLS with other stuff)
>
> (and many others).=C2=A0 It's already so different even to TLS 1.2= that there's no
> point in retaining some crufty old artefact of SSL 3.0 just because we= 've
> always done it this way.=C2=A0 If there's a feature that's use= ful or important to
> the functioning of the protocol then by all means include it, but ther= e's no
> point in dragging along old protocol misfeatures "for backwards c= ompatibility"
> when so much else has changed incompatibly.

I agree. We should focus in simplifying implementations of T= LS 1.3 and TLS 1.2, and it seems that this means assuming minimal (read non= e) =C2=A0code reuse, and focusing on simplifying TLS 1.3 on its own terms.<= /p>


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

--089e01294ff0dc64f8051104c17c-- From nobody Wed Mar 11 09:23: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 5F48A1ACDB6 for ; Wed, 11 Mar 2015 09:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXWFLX8T9OJz for ; Wed, 11 Mar 2015 09:23:18 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.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 3DE991ACDA3 for ; Wed, 11 Mar 2015 09:23:13 -0700 (PDT) Received: by qcvs11 with SMTP id s11so11513843qcv.7 for ; Wed, 11 Mar 2015 09:23: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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=k87CM8RWtgqxPBmgSu2fJN2H8+M5HZRNP6ZMvBXtqlQ=; b=V6Z9//B+qfeIpMBZOrMQF1ws2WPjlKF1Pe3dSjiQ0W6vCODNHLd7A7fAsd9QyazXy5 miberg1wNDIWg6arA+jr8ih4JV9t/b4tDUSyFWTBpFsa1fnRMnBEyikCkDoIf3qc/3ft kD3CQJ5kKwBTkL9sbDEgbZZ1od5UFLeXza8SmHdzSUvubOoyct4w3ucBsxTZtOubRwn/ JK6Nbia8Ty5TiUFdpKMQosqJYGy9iB010Wx+PD4VKZYAx0OrTneUmofFMLTUeoROZ2KC hblXbrx3m86LYGzclJ6hQMKtYtOJeHz4Z1+QzloVbE33Zo0TzCgryx6VWIA5inIkWiJA zYfA== X-Gm-Message-State: ALoCoQmrh1aBtHsd4rFjQLEniqtMfar7QSpZq2nLdQXPnJsBmYl71SzjOqjSnh0OyLZK6u1gwTuG X-Received: by 10.55.41.80 with SMTP id p77mr45862687qkh.67.1426090992359; Wed, 11 Mar 2015 09:23:12 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id z67sm2863378qgz.10.2015.03.11.09.23.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 09:23:11 -0700 (PDT) Received: from mba.hsd1.md.comcast.net (router [192.168.1.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 1A2D1AC28A0; Wed, 11 Mar 2015 12:23:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <201503081339.47927.davemgarrett@gmail.com> Date: Wed, 11 Mar 2015 12:23:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201503081339.47927.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:23:23 -0000 On Mar 8, 2015, at 1:39 PM, Dave Garrett wrote: > Versions would be negotiated with a new "Extended TLS Version = Negotiation" extension with the following contents: >=20 > struct { > uint8 versions<0..2^8-1>; > } SupportedVersions; I think this is a bad idea for two main reasons. 1. As soon as we have multiple mechanisms for signaling versions, = implementations are going to have (more) bugs. I suspect bugs will arise = for ClientHello.version set to something other than 1.2 with this = extension present. 2. It's not clear that adding a second mechanism would actually improve = the situation. If implementors aren't handling a very simple version = negotiation correctly, then they are almost certainly not going to = handle a more complex version negotiation correctly. So why would we = suspect this won't lead to a new type of version intolerance? Version-intolerance became an issue because there were not all that many = versions. As protocol and performance issues have driven demand for TLS = > 1.0, version intolerance has dropped dramatically (although it clearly = still exists given the fallbacks some clients do). I expect this problem to get better over time and do not see a need to = add more complexity to solve what I hope will soon become a nonissue. Now it may be the case later down the road that with n versions of TLS, = implementors might choose to skip versions. Until that's a real concern, = I don't think we should add complexity to support what may not ever = become a real use case. --=20 Stephen Checkoway From nobody Wed Mar 11 09:52: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 99F281A0235 for ; Wed, 11 Mar 2015 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dutlK717uyer for ; Wed, 11 Mar 2015 09:52:26 -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 F36281A1A88 for ; Wed, 11 Mar 2015 09:52:25 -0700 (PDT) Received: by qgfh3 with SMTP id h3so11496331qgf.2 for ; Wed, 11 Mar 2015 09:52:25 -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=wpzh+2lQmlxRunGShnsQOQNpiMeXseg+gbLvpPIwU1c=; b=sO6D+maNkJZzYFQK9qq5w4UVI9no/TmU9IeSiWHeFiJzl4ddahlikKbZo8oCG3HQvd eMGqCKSZrwt7eU6cnOWGx8EAYsaIAnV8GsTXEXpEWKrDVn8Ri8zkZEQZUK9zDTIr9+Wd PGzlk6UVacTu8ntC6VXN54jvbCW+Jr4XvCpwONg56GYM1tCqbfyUHqU93HCiR0quafn7 QJAsikFf3yhiofF7f/4VJOZ1Mt9IEoHmU1nHm0qxS9nLg+76xsn+3kUuFizwe519Y+LO YLnBwzNql9uYHqXtxG0FC5zSqHPsvSGGxsmK/WzALHFRQhuPBfbkHLN1hzhp8ALbmbbB BA6Q== X-Received: by 10.140.93.199 with SMTP id d65mr46898654qge.104.1426092745242; Wed, 11 Mar 2015 09:52:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 11sm2909408qhh.7.2015.03.11.09.52.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 09:52:24 -0700 (PDT) From: Dave Garrett To: Stephen Checkoway Date: Wed, 11 Mar 2015 12:52:23 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081339.47927.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503111252.23754.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:52:27 -0000 On Wednesday, March 11, 2015 12:23:10 pm Stephen Checkoway wrote: > I think this is a bad idea for two main reasons. > > 1. As soon as we have multiple mechanisms for signaling versions, implementations are going to have (more) bugs. I suspect bugs will arise for ClientHello.version set to something other than 1.2 with this extension present. > > 2. It's not clear that adding a second mechanism would actually improve the situation. If implementors aren't handling a very simple version negotiation correctly, then they are almost certainly not going to handle a more complex version negotiation correctly. So why would we suspect this won't lead to a new type of version intolerance? The primary source of TLS version intolerance is the small portion of the Internet running junk they haven't upgraded in a decade and a half. Non-ancient implementations are generally fine in this area, and I (possibly naively) expect TLS 1.3 implementations to be notably better in dealing with this sort of thing. The primary reason why TLS version intolerance became a problem at all is that all browser vendors started doing insecure fallback and letting it slide. I am (possibly naively) expecting this to not be a bit of history we're likely to repeat as easily. An extension to systematically work around the existing junk makes this more likely to not regress into "yeah, sure, whatever" security again. Mandating SCSV support in the TLS 1.3 spec could be a band-aid to deal with this, but some have noted that they really dislike it (for valid reasons). > Version-intolerance became an issue because there were not all that many versions. As protocol and performance issues have driven demand for TLS > 1.0, version intolerance has dropped dramatically (although it clearly still exists given the fallbacks some clients do). > > I expect this problem to get better over time and do not see a need to add more complexity to solve what I hope will soon become a nonissue. If no strict coordination is done for TLS 1.3, it will stop getting better. TLS 1.3 intolerance is in the 1.5% range. (though, I suspect real-world testing might show that inability to deal with a TLS 1.3 handshake might be higher) Insecure fallbacks will be the norm again. ----- I'm going to reiterate, though: I would MUCH rather use the existing version negotiation method and have all vendors agree to completely forbid all insecure fallback in all browsers on the same day, in unison. (to the hour, preferably) A coordinated "Break the Web" day where all vendors cease support for this crap would be the correct solution. However, I have no confidence that this is capable of being organized and completed without a last minute bail by someone. I don't even think everyone could agree to coordinate an interstitial warning for this first. Anything I say in the context of proposing an alternate version negotiation mechanism should please be taken in the context that I agree with you that it's not the right way to do things. Any solution is better than no solution, though. :| Dave From nobody Wed Mar 11 11:14: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 CBD6C1A1B87 for ; Wed, 11 Mar 2015 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cINZMYs4ZDDE for ; Wed, 11 Mar 2015 11:14:06 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 0057C1A1B8B for ; Wed, 11 Mar 2015 11:14:05 -0700 (PDT) Received: by qgdz107 with SMTP id z107so12100636qgd.4 for ; Wed, 11 Mar 2015 11:14:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6dMrabX4Fa4BVe00bbgrE8uLHmOXbbcDy1aFoDPoERc=; b=Z2HE4widGEPCf1gyiDzxPi+gohgsOapDVkyrjLfxJQ/fkdPJzUhi43F9lszoL2f2z0 xBf8zOd9HDdDmhON0SPNwA+/+0ddrTM5WYTn30BbT8mpuw5hcTqGW4dih3xseHU+sNC2 PAsUXNy08gwqUBDGDxHnfuQgkb/fRvCbfz1nbx4kFu6TAIYiHxfn/bKr94/09ebidkp6 OupqU/f0akFSLmkgqfOoBzyZdGN//VqJghgS1ueI7YlcwO32ghsm8idhiNrI0n+nrg2h COFNMUMe1sqULGvntozno8GWoLx9owuYwDNIeVanhhVkh3NwRvRXr+HZoYJBbmEpxMOM RMeQ== X-Gm-Message-State: ALoCoQmuShR8yA7zzYNkHm8LRftplBshTl9/YnCo9X1pO3gxmBRWZFygBx9vTWiXq9S2/TAfzIe0 X-Received: by 10.55.33.41 with SMTP id h41mr69000564qkh.69.1426097645155; Wed, 11 Mar 2015 11:14:05 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id t8sm3051814qga.24.2015.03.11.11.14.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 11:14:03 -0700 (PDT) Received: from [128.220.247.217] (unknown [128.220.247.217]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 1384FAC28A0; Wed, 11 Mar 2015 14:14:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <201503111252.23754.davemgarrett@gmail.com> Date: Wed, 11 Mar 2015 14:13:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:14:08 -0000 On Mar 11, 2015, at 12:52 PM, Dave Garrett = wrote: > On Wednesday, March 11, 2015 12:23:10 pm Stephen Checkoway wrote: >> I think this is a bad idea for two main reasons. >>=20 >> 1. As soon as we have multiple mechanisms for signaling versions, = implementations are going to have (more) bugs. I suspect bugs will arise = for ClientHello.version set to something other than 1.2 with this = extension present. >>=20 >> 2. It's not clear that adding a second mechanism would actually = improve the situation. If implementors aren't handling a very simple = version negotiation correctly, then they are almost certainly not going = to handle a more complex version negotiation correctly. So why would we = suspect this won't lead to a new type of version intolerance? >=20 > The primary source of TLS version intolerance is the small portion of = the Internet running junk they haven't upgraded in a decade and a half. = Non-ancient implementations are generally fine in this area, and I = (possibly naively) expect TLS 1.3 implementations to be notably better = in dealing with this sort of thing. I'm not sure how this proposal helps here. Do you expect that there's a = significant fraction of servers that (a) tolerate 1.2; (b) don't = tolerate > 1.2; and (c) aren't maintained or can't be upgraded? I'd be = surprised by data showing this. I imagine that any server satisfying (b) = and (c), probably doesn't satisfy (a) so this proposal doesn't help. > Any solution is better than no solution, though. :| I don't agree. This is the "something must be done; this is something; = therefore it must be done" argument. --=20 Stephen Checkoway From nobody Wed Mar 11 11:43: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 7B95D1A0149 for ; Wed, 11 Mar 2015 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kdPuqX2c1_b for ; Wed, 11 Mar 2015 11:43:38 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:252::55]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1E21A0078 for ; Wed, 11 Mar 2015 11:43:36 -0700 (PDT) Received: from 236.168.251.212.customer.cdi.no ([212.251.168.236]:55116 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YVlbS-00013J-HW for tls@ietf.org; Wed, 11 Mar 2015 19:43:34 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> Date: Wed, 11 Mar 2015 19:43:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <201503111252.23754.davemgarrett@gmail.com> User-Agent: Opera Mail/12.17 (Win32) Archived-At: Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:43:40 -0000 Hi, On Wed, 11 Mar 2015 17:52:23 +0100, Dave Garrett wrote: > On Wednesday, March 11, 2015 12:23:10 pm Stephen Checkoway wrote: >> I think this is a bad idea for two main reasons. >> >> 1. As soon as we have multiple mechanisms for signaling versions, >> implementations are going to have (more) bugs. I suspect bugs will >> arise for ClientHello.version set to something other than 1.2 with this >> extension present. I agree that this is likely. >> 2. It's not clear that adding a second mechanism would actually improve >> the situation. If implementors aren't handling a very simple version >> negotiation correctly, then they are almost certainly not going to >> handle a more complex version negotiation correctly. So why would we >> suspect this won't lead to a new type of version intolerance? > > The primary source of TLS version intolerance is the small portion of > the Internet running junk they haven't upgraded in a decade and a half. At present, in my 530K server sample, 2.25% of servers are registered as failing if the Client Hello indicates 3.4 (TLS 1.3) as the version. 0.8% of servers are 3.4 intolerant and *not* patched for Renego, meaning 1.4% are renego patched (meaning that 60+% were updated in the last _5_ years, at least). And just to make the picture complete, 4.6% of servers are renego patched and intolerant for the 4.1 version indication, and 11.5% of all servers are intolerant for the 4.1 version. I'll note that The Renego spec reiterated the version negotiation requirements, and only 0.17% of servers are renego patched and intolerant in the 1.0-1.2 inclusive range. Maybe I am being pessimistic, but frankly I don't think using an extension will work for very long. If it doesn't break already when we deploy TLS 1.3, I would be highly, but pleasantly surprised if we have less than 0.1% of server intolerant for TLS 1.4 when it gets deployed. In fact, I doubt it will be less than 3%. BTW, 15.74% of servers are intolerant for the FALLBACK SCSV, 15.7% at the front, 11.1% at the end. Admittedly, only 0.01% are intolerant for both 3.4 and the SCSV, but if a 1.3 client have to rollback (e.g. due to a problem with an intermediate) and sends an SCSV, it is currently going to run into trouble with 1 out of every 9 servers. Keep in mind that direct intolerance is "just" 2.25%. Additionally, 0.6% of the servers were extension intolerant in the TLS 1.0-TLS 1.2 range, 65% of which are renego patched, and 2.7% of all servers are extension intolerant for TLS 1.3 > Non-ancient implementations are generally fine in this area, and I > (possibly naively) expect TLS 1.3 implementations to be notably better > in dealing with this sort of thing. At this time, it is not the TLS 1.3 server implementations we have to be worried about, it is the currently deployed servers. If one want to avoid such future interoperability concerns, the only way to avoid them is to create a exhaustive certification test suite that all implementations have to pass in order to call themselves TLS 1.3, 1.4, 1.5 etc. server/client. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From nobody Wed Mar 11 11:46: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 CCC4B1A0430 for ; Wed, 11 Mar 2015 11:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1UrFTiQzb46k for ; Wed, 11 Mar 2015 11:46:07 -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 5A13C1A6ED9 for ; Wed, 11 Mar 2015 11:46:06 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id F246E44849; Wed, 11 Mar 2015 19:46:03 +0100 (CET) X-purgate-ID: 152705::1426099564-00002D1E-C3CDDF9F/0/0 X-purgate-size: 785 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E65354468B; Wed, 11 Mar 2015 19:46:03 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DBDB21B21B; Wed, 11 Mar 2015 19:46:03 +0100 (CET) In-Reply-To: <201503111252.23754.davemgarrett@gmail.com> To: Dave Garrett Date: Wed, 11 Mar 2015 19:46:03 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150311184603.DBDB21B21B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Stephen Checkoway , "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism 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, 11 Mar 2015 18:46:08 -0000 Dave Garrett wrote: > > The primary source of TLS version intolerance is the small portion of > the Internet running junk they haven't upgraded in a decade and a half. Just FYI, all Servers that are running Microsoft Windows 2008R2, 2012& 2012R2 and have TLSv1.2 enabled, are de-facto version-intolerant to TLSv1.2 They will abort the connection when receiving an extension-less ClientHello with ClientHello.client_version = (3,3), while the handshake will succeed with ClientHello.client_version = (3,2) or when the server has TLSv1.2 disabled (the latter is the default for Win7/2008R2). > > Non-ancient implementations are generally fine in this area I'm not sure that everyone would agree to the determination that Windows 8 & 8.1 are "ancient". -Martin From nobody Wed Mar 11 11:56: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 416DC1A1B8A for ; Wed, 11 Mar 2015 11:56:17 -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 H5mpZUHXKtOE for ; Wed, 11 Mar 2015 11:56:15 -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 94FD71A003B for ; Wed, 11 Mar 2015 11:56:14 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 564D1188815; Wed, 11 Mar 2015 20:56:12 +0200 (EET) Date: Wed, 11 Mar 2015 20:56:12 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150311185612.GA25892@LK-Perkele-VII> References: <9A043F3CF02CD34C8E74AC1594475C73AAFAD5D2@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:56:17 -0000 On Wed, Mar 11, 2015 at 08:16:53AM -0700, Watson Ladd wrote: > On Mar 10, 2015 10:19 PM, "Peter Gutmann" wrote: > > > > (and many others). It's already so different even to TLS 1.2 that > there's no > > point in retaining some crufty old artefact of SSL 3.0 just because we've > > always done it this way. If there's a feature that's useful or important > to > > the functioning of the protocol then by all means include it, but there's > no > > point in dragging along old protocol misfeatures "for backwards > compatibility" > > when so much else has changed incompatibly. > > I agree. We should focus in simplifying implementations of TLS 1.3 and TLS > 1.2, and it seems that this means assuming minimal (read none) code reuse, > and focusing on simplifying TLS 1.3 on its own terms. The kind of backward compatiblity I am talking about: - Be able to do secure downnegotiation to TLS 1.2. - Don't break protocols using TLS. These would impose the following constraints: - The first flight can only have TLS 1.2-compatible ClientHello (unless server is known to be 1.3-capable and client is prepared to take heavy latencies otherwise). - The second flight has to be always distinguishable from TLS 1.2. (recordversion field should do here?) - Not using record types (first byte of record) outside 20-63 range. - TLS-Unique and TLS-Exporter APIs are still there. The following are examples of changes outside scope of backwards compat: - Removing recordversion from encrypted records. - Redefining recordtype values (within range, some of that already done). - Redefining TLS-Unique and TLS-Exporter internals. - Totally rearranging the handshake (already done) Also, to me the current TLS 1.3 draft looks to be much more hardened against cryptographic attacks than TLS 1.2 (even with session_hash). And the source of this resistance is precisely encrypting as much as possible together with CRK. -Ilari From nobody Wed Mar 11 11:56:43 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 6B2B71A017A for ; Wed, 11 Mar 2015 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWBZA8LzCZtu for ; Wed, 11 Mar 2015 11:56:40 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::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 505511A09C9 for ; Wed, 11 Mar 2015 11:56:40 -0700 (PDT) Received: by qcvs11 with SMTP id s11so12717368qcv.6 for ; Wed, 11 Mar 2015 11:56:39 -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=8qTvsd4lh6L5mDEXRBEz04pG2ADS2bpIQeZ2wpMjhPA=; b=czpe79Josapg3iH5hdqVjZM5KX3J9+1CJ+NYr7LWkVi3nq8kV0lFHaatK2zwhNLdAW nEkh9847Tuh79S59okeTkW++ILt+W/Q6cprlaV6zIRgY5m8wvWABnRXat2o/ZYzl0Sxh OPZF0TydqzUEKnfbRNWxMXTQcTrJvCFaQa0JOPKRlmTswexKZ9X0xl6r5pniR3akZyxa r7GeYXgRR81fZSI9v1HpuO+k2OEx9v+/lxPvycok8pF+FnUTMKMjcUfvb/PYMo9verFF kLjVT9M2J68Wj8K2jXynlz4Y0doWCM9Emeg6jYWlJvnN02UCOUstm5g7LnBV+lpIavTE lBQg== X-Received: by 10.140.108.116 with SMTP id i107mr47549805qgf.73.1426100199649; Wed, 11 Mar 2015 11:56:39 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g34sm3151034qgd.0.2015.03.11.11.56.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 11:56:39 -0700 (PDT) From: Dave Garrett To: Stephen Checkoway Date: Wed, 11 Mar 2015 14:56:37 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503111456.38308.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:56:42 -0000 On Wednesday, March 11, 2015 02:13:56 pm Stephen Checkoway wrote: > Do you expect that there's a significant fraction of servers that (a) tolerate 1.2; (b) don't tolerate > 1.2; and (c) aren't maintained or can't be upgraded? Yes. > I'd be surprised by data showing this. I imagine that any server satisfying (b) and (c), probably doesn't satisfy (a) so this proposal doesn't help. http://www.ietf.org/mail-archive/web/tls/current/msg15141.html On Tuesday, January 20, 2015 11:01:31 pm Xiaoyin Liu wrote: > For each site, I made at most four attempts with the following order to fallback: > (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> (TLS 1.0, TLS 1.0) > where the first is TLS record layer version, and the second is Client Hello version. > > Here is the result: > (1) Number of sites scanned: 1,000,001 > (2) Number of DNS Error: 45,402 > (3) Number of sites that refuse TCP connection on port 443 (RST, timeout): 289,334 > (4) Number of sites that fail sending ServerHello in all 4 attempts: 238,846 > (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%) > (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%) > (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%) > (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%) > > The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. TLS 1.2 intolerant sites are about 0.1%. Also it shows setting a lower record layer version does improve compatibility a lot. An example is https://paypal.com is intolerant to (TLS 1.3, TLS 1.3) but is tolerant to (TLS 1.0, TLS 1.3). Please note that I did not validate certificates nor check the integrity of handshakes. I closed the connection immediately after receiving ServerHello. Anecdotally, I am seeing TLS 1.3 intolerant servers that otherwise work popping up reports of servers breaking with the RC4 phase out. An arbitrary and not scientific survey of the sites currently listed in the Mozilla RC4-Dependence meta-bug shows the following: https://bugzilla.mozilla.org/show_bug.cgi?id=1138101 42 sites checked (popular enough to get reported there, at least) of those, 5 have fixed their RC4 dependence; the others have not (as of this email) 5 are TLS 1.1-1.3 intolerant 1 is TLS 1.2-1.3 intolerant 8 are TLS 1.3 intolerant, but not 1.2 or less 3 are even tolerant to TLS 1.98 & 2.98 tests (the others are not) (not bothering with percentages because the sample size is low and biased) The rough things learned here are: 1) TLS 1.3 intolerance is more common than TLS 1.2 intolerance 2) TLS 1.2 intolerance without TLS 1.1 intolerance is actually a thing that happens 3) It is seemingly rare for any server to fully implement version negotiation properly (the domain that runs the test I use is even intolerant to TLS 2.98) 4) It appears that TLS 1.3 intolerance is more common with servers that have other problems that should've been fixed by now, but aren't Again, this is anecdotal. I don't claim this is fully extrapolatable to the entire Internet, just that I'm seeing enough of it to be concerned. I argue that TLS should never formally change its ClientHello version to anything greater than 1.x, though a spec name with yet another hacky numbering that doesn't match the official version number would be fine. (e.g. Call it TLS2 but number it {3,4} still) I also argue that TLS 1.3 intolerance is something that must be addressed fully BEFORE attempting to get draft implementations out there and encouraging insecure fallback to deal with it. Dave From nobody Wed Mar 11 11:57: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 787FE1A09C9 for ; Wed, 11 Mar 2015 11:57: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 kekOfY16Efga for ; Wed, 11 Mar 2015 11:57:52 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 3E0991A003B for ; Wed, 11 Mar 2015 11:57:52 -0700 (PDT) Received: by qgfi50 with SMTP id i50so12426525qgf.10 for ; Wed, 11 Mar 2015 11:57: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=DrxgR7YIe127u47EQb9/Pym/DdkhnrkjIYk3v4TCI/w=; b=Cc5vJvmSuXg/gOwCUja7IZLy2C0Wg9q630kN2I9vHygaHCn1MfGGsdSVu2a3fHkMlE nt1SUnxq3kFm/RggFi/rWZIw93sWsqyqT2n4kFMLSzPbNsMJsufPv49xv9TTgR5/B7NM BI54wjZwbLEBLexkvG36RmTYa9g0LT55tP6r9wNgqrn5wfriRoKcfy3VLDQ31VWQfDRg cQTG0qFofuByCjlraAoVmmcMNMqTr+pxHZ9bucaAKYdjir83VMssfA8NJX+z4f0IlpjI BAyQO/x2HsD1mauskpuy7ippF2QaPHnanjfT15f7jMRPfgNLW+ZFxv0t0Fpg/GavxwEl JAhQ== X-Received: by 10.229.48.131 with SMTP id r3mr36747504qcf.29.1426100271568; Wed, 11 Mar 2015 11:57:51 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id a77sm3118802qkh.42.2015.03.11.11.57.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 11:57:51 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 11 Mar 2015 14:57:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503111457.50305.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:57:53 -0000 On Wednesday, March 11, 2015 02:43:20 pm Yngve N. Pettersen wrote: > If one want to avoid such future interoperability concerns, the only way > to avoid them is to create a exhaustive certification test suite that all > implementations have to pass in order to call themselves TLS 1.3, 1.4, 1.5 > etc. server/client. YES From nobody Wed Mar 11 16:43: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 8CF5A1A8925 for ; Wed, 11 Mar 2015 16:43:15 -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_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 GyhvGt2SsZo6 for ; Wed, 11 Mar 2015 16:43:13 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95A1A8920 for ; Wed, 11 Mar 2015 16:43:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,385,1422921600"; d="scan'208";a="152958514" X-IPAS-Result: A2CkBADo0QBV/+sKqMBchDbDa4d/AQEBAQEBfYQWgQsBgQAnBNJclDwFrXKBdC4fgVCCM38BAQE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 11 Mar 2015 23:43:13 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 11 Mar 2015 16:43:12 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1044.021; Wed, 11 Mar 2015 16:43:12 -0700 From: David Holmes To: "tls@ietf.org" Thread-Topic: TLS 1.3 - ignoring version values in record protocol header Thread-Index: AQHQXFUihw/4ytADb0u9ZC31Hgijrg== Date: Wed, 11 Mar 2015 23:43:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7357540892D7904084B09E28C54B01F1@F5.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS 1.3 - ignoring version values in record protocol header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:43:15 -0000 On day 1 of the Seattle TLS 1.3 working group, it was questioned what to do with the TLS version bytes in record protocol. Send but ignore seemed to be the consensus, with =B3pin to [3,4] forever" In draft 5, if the version bytes are still included in the AEAD computation, they shouldn=B9t be ignored, right? If we keep the record protocol version bytes, the most straightforward action is to [continue with the tradition of having them] match the version of TLS negotiated in the handshake. In this case [3,4]. 6.2.2 Record Payload Protection struct { ContentType type; ProtocolVersion version; uint16 length; opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque content[TLSPlaintext.length]; } fragment; } TLSCiphertext; =8A additional_data =3D seq_num + TLSPlaintext.type + TLSPlaintext.version =8A AEADEncrypted =3D AEAD-Encrypt(write_key, nonce, plaintext, additional_data= ) From nobody Wed Mar 11 17:24: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 E09E61A8998 for ; Wed, 11 Mar 2015 17:24: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 1DjAQs6XN0nQ for ; Wed, 11 Mar 2015 17:24:35 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::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 213B21A8981 for ; Wed, 11 Mar 2015 17:24:35 -0700 (PDT) Received: by qcwb13 with SMTP id b13so14759428qcw.9 for ; Wed, 11 Mar 2015 17:24:34 -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=x+EK4fhMCAiliWIKS0XdgXGJdVAHADu/QB4zDZ9F1a8=; b=rCZAVRNNAmPyimYfJB1glspujlxDnQ8hXvaWQGTAY0p0xcny2/kTlsuZrnXEHY7rXs re2hOz0aVht9wyL4YJErn7s/Wfygeq5mSamroxViBCY2LTNCWzRSMSDza4OTEgQA5UFs qQBv5azM79PqcSTz7iY2YVeiuEPSnE+FkCUixVV1CVdHnlvNEMw9G+A/bqFKJbluta+h PokkiLrRv5ReQt3SqRyWEq3ou/M6gzCDXCn2km9m7LD6cCn9mnFq2e/EZSK9LR40uO9d EIwty3IOznhUCFt3CnCz3HWDK8yJY7oxpVWbaEtWuj0TttePMfh+NBl8n5eZ7SQa0UmK V3sA== X-Received: by 10.140.145.9 with SMTP id 9mr50416158qhr.104.1426119874425; Wed, 11 Mar 2015 17:24:34 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 10sm3684361qha.38.2015.03.11.17.24.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 11 Mar 2015 17:24:33 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 11 Mar 2015 20:24:31 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201503112024.31950.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.3 - ignoring version values in record protocol header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:24:37 -0000 Record layer version number freezing & ignoring is in latest PR #107: https://github.com/tlswg/tls13-spec/pull/107/files Proposal to just remove the field from encrypted records is now issue #144: https://github.com/tlswg/tls13-spec/issues/144 Reviewing #107 is in EKR's work queue. #144 hasn't gotten much discussion yet. Dave From nobody Wed Mar 11 17:31: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 C00621A895A for ; Wed, 11 Mar 2015 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2tf6IFS_1_i for ; Wed, 11 Mar 2015 17:31:11 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 6B4721A88F4 for ; Wed, 11 Mar 2015 17:31:11 -0700 (PDT) Received: by oifz81 with SMTP id z81so11053753oif.0 for ; Wed, 11 Mar 2015 17:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9YqYrx0roZ5lYGebdNvFNVeXHZx37J8eXH5yIHT2LFg=; b=cVBwXpx0/3oSYiVXUwk7Vn+yB89nujOeqHdLjxg3nC+RQ7l3uBRQu3OemuI5wAcoIz XA3I2hfReC4cl6ksvSk6g4yhH4Wfdm30OU1mAuEvwY3coqW8un0rasb44pmGx2blC4DX M6Bej1Msat+3RpZcs3+eelqKj316agYYtUgWsWf/phR7+tOih4YwCwRCylmgENHBUdiN Pg0AaQnkcH3XrFFwsudzA4ljwA4NVOYBcHsbpJqUfL6ABJ0M7SS9seCSgxCq5I08jtyh aGXI4W+vpjTpi6hCHHTy+4Eykd7PSEtY2Sic6I6kv4qfDugU+JNHJldH7+78/V2c0W1m umiQ== MIME-Version: 1.0 X-Received: by 10.182.213.38 with SMTP id np6mr31622708obc.34.1426120270922; Wed, 11 Mar 2015 17:31:10 -0700 (PDT) Received: by 10.202.225.135 with HTTP; Wed, 11 Mar 2015 17:31:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2015 17:31:10 -0700 Message-ID: From: Martin Thomson To: David Holmes Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 - ignoring version values in record protocol header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:31:12 -0000 On 11 March 2015 at 16:43, David Holmes wrote: > In draft 5, if the version bytes are still included in the AEAD > computation, they shouldn=C2=B9t be ignored, right? This is largely conjecture without proper analysis, but would like to suggest the following: 1. We make the version number part of the PRF (HKDF) info string (i.e., "TLS 1.3" or something that is unique to this protocol is part of all expansion phases. That will make the keying material dependent on the version number. 2. Content type be moved from the AD to the actual data so that it is not just authenticated, but also encrypted. 3. And then, since the sequence number was agreed to comprise the entirety of the IV (the 5116 nonce) with zero pad to the requisite size, it too can be removed. ... that means that ALL of the AD can be removed. Yes, this could mess up middleboxes, but the sense I got was that we might try this out and see how much damage this really does. From nobody Wed Mar 11 22:01:34 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 551A71A8A5A for ; Wed, 11 Mar 2015 22:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk0JTAXaFFpe for ; Wed, 11 Mar 2015 22:01:32 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (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 042521A8A59 for ; Wed, 11 Mar 2015 22:01:31 -0700 (PDT) Received: by qgfi50 with SMTP id i50so15500488qgf.10 for ; Wed, 11 Mar 2015 22:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cfogcACjT4g5oBFlm2wKQYl1gjntpwQCUTqEQrBWWJ4=; b=WtVxjOY4scXfdJ7whaZKLvugXsjts45ufBcqVyHvzAb6GG2B/XQWAxYvP84y00YOqd Yr0P6zc1Eai4dIZy39r6R/De5V91OEcQIjGQk+ffYAYMY8IBEZz6190h11xZUTMsjo6X lF89OejCWTe16DlX64xb+KkMDIQ9Y6RZJ1W2vymTC+0Sm8xlU+GZn/AVAUTpnRmqaB7H xm52gw/bEMvCir8i4uw2iov23y4HrxUbFL5qnEd8kiRov5Q1twvvohqagDq7C8KF/n7S 7R2k/v+RBQId17lvVKIUdw5OW4EKilv+k9AtRjnOSKB8rH+RQocMS53VAPTZ4TN38Ix4 j43A== X-Gm-Message-State: ALoCoQmwn5ogLrNn1mUWsBgnls/r5W0jSgrmDJiK1yTYHqYrOyVi0ihuBuFR5m+9JK3BfLijW3Q+ X-Received: by 10.140.107.75 with SMTP id g69mr49981709qgf.103.1426136491137; Wed, 11 Mar 2015 22:01:31 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id f63sm4113703qkf.14.2015.03.11.22.01.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2015 22:01:29 -0700 (PDT) Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 44FA4AC28A0; Thu, 12 Mar 2015 01:01:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: <201503111456.38308.davemgarrett@gmail.com> Date: Thu, 12 Mar 2015 01:01:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> <201503111456.38308.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:01:33 -0000 On Mar 11, 2015, at 2:56 PM, Dave Garrett = wrote: > On Tuesday, January 20, 2015 11:01:31 pm Xiaoyin Liu wrote: >> For each site, I made at most four attempts with the following order = to fallback: >> (TLS 1.3, TLS 1.3) -> (TLS 1.0, TLS 1.3) -> (TLS 1.0, TLS 1.2) -> = (TLS 1.0, TLS 1.0) >> where the first is TLS record layer version, and the second is Client = Hello version. >>=20 >> Here is the result: >> (1) Number of sites scanned: 1,000,001 >> (2) Number of DNS Error: 45,402 >> (3) Number of sites that refuse TCP connection on port 443 (RST, = timeout): 289,334 >> (4) Number of sites that fail sending ServerHello in all 4 attempts: = 238,846 >> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 = (93.1%) >> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 = (5.3%) >> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 = (1.5%) >> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 = (0.1%) >>=20 >> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant = sites (7 and 8) are about 1.6%. Most of this is about the record layer version (which really seems silly = to change given that the record layer isn't changing). The real data here is that 1.5% of servers are intolerant of 1.3 but = tolerate 1.2. So that was (a) and (b) in my list but it's pretty hard to = measure (c): servers that aren't maintained or can't be upgraded. I remain unconvinced, but others can weigh in. --=20 Stephen Checkoway From nobody Thu Mar 12 00:26:43 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 9A3871A8A9E for ; Thu, 12 Mar 2015 00:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvkDgZeLIJpO for ; Thu, 12 Mar 2015 00:26:41 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d: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 1E65F1A8A87 for ; Thu, 12 Mar 2015 00:26:41 -0700 (PDT) Received: by qgfh3 with SMTP id h3so15962574qgf.13 for ; Thu, 12 Mar 2015 00:26:40 -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=Bqfy8SMccLZaFZLm0zchA16J+yA2GGisZvmekhFenxk=; b=nm8ja3u4GUQRObVTjmzfuz4K7U/0By7w6MW78M0PIVgISML111d/bXGddofX8mLk3Y O7aC3nd7NvmCaEtoOERMYa/oPK2HhM3VfBUBYgcAyGCWcrpBWgk4pMuSfSFhz6ifYf9/ wDnbn11VGIXY/KzYXOYiWXSpBN9N5SEsBn6jUL5WSa1J4FBSEGqljmk9rQK5hI16qdcN NgnFwOX+2SWCR3PLVuWBVF52VN9O/e/FqJVA8b3/MfIXZcj5eWJcUPD9wPL/XSwS8QEV sxrKMc5TxUms+fJOozitMFbVE1ruAyxcrbj0qymu8b/JwZ0JCzLs1QKgekJsbcA5ibe3 EvAg== X-Received: by 10.140.165.209 with SMTP id l200mr53881389qhl.84.1426145200455; Thu, 12 Mar 2015 00:26:40 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 91sm4276403qkw.13.2015.03.12.00.26.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 00:26:39 -0700 (PDT) From: Dave Garrett To: Stephen Checkoway Date: Thu, 12 Mar 2015 03:26:38 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503081339.47927.davemgarrett@gmail.com> <201503111456.38308.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503120326.38588.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:26:42 -0000 On Thursday, March 12, 2015 01:01:27 am Stephen Checkoway wrote: > > On Mar 11, 2015, at 2:56 PM, Dave Garrett wrote: > > > On Tuesday, January 20, 2015 11:01:31 pm Xiaoyin Liu wrote: > >> (5) Number of sites that are tolerant to (TLS1.3, TLS1.3): 397,152 (93.1%) > >> (6) Number of sites that need to fallback to (TLS1.0, TLS1.3): 22,461 (5.3%) > >> (7) Number of sites that need to fallback to (TLS1.0, TLS1.2): 6,352 (1.5%) > >> (8) Number of sites that need to fallback to (TLS1.0, TLS1.0): 454 (0.1%) > >> > >> The total number of TLS enabled sites is 426,419. TLS 1.3 intolerant sites (7 and 8) are about 1.6%. > > Most of this is about the record layer version I just wanted to post the full data set here so it wasn't out of context. > The real data here is that 1.5% of servers are intolerant of 1.3 but tolerate 1.2. So that was (a) and (b) in my list but it's pretty hard to measure (c): servers that aren't maintained or can't be upgraded. > > I remain unconvinced, but others can weigh in. Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant and browser vendors are STILL having trouble dropping insecure fallback, if they are attempting it at all. The TLS 1.3 intolerance problem is over an order of magnitude worse. To be precise, most of these servers are likely considered maintained and can technically be upgraded, but that doesn't mean they actually will. Starting out with this untamed mess could discourage TLS 1.3 adoption and will encourage browsers to do insecure fallback for TLS 1.3. For a marginally less hacky route, we could basically just make a better version of SCSV and mandate its use in the TLS 1.3 spec. Simply have a max supported version extension which has nothing other than the max client TLS version in it, include it in every ClientHello, and use the normal version negotiation. If a 1.3 ClientHello fails, an insecure fallback to 1.2 can be done, however a 1.3 server can doublecheck versions and know the first attempt merely failed and 1.3 can actually be negotiated instead. The client would get a 1.3 ServerHello and could continue the connection normally, but note an error somewhere. (whatever dubious security UI indicator the browser uses) This is essentially the existing system with an extension as a backup method, but it enshrines downgraded fallbacks as valid. (we might be ok with that if this is done properly) It does have the benefit of shining a spotlight on broken implementations, though. Dave From nobody Thu Mar 12 00: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 6D7E91A1A15 for ; Thu, 12 Mar 2015 00:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OO9ecEJn9kWS for ; Thu, 12 Mar 2015 00:28:46 -0700 (PDT) Received: from BLU004-OMC3S6.hotmail.com (blu004-omc3s6.hotmail.com [65.55.116.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2159F1A1B40 for ; Thu, 12 Mar 2015 00:28:46 -0700 (PDT) Received: from BLU177-W18 ([65.55.116.73]) by BLU004-OMC3S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 00:28:45 -0700 X-TMN: [B5G3JTVQRi25upL/ikfo9/KwT1OLZdne] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Dave Garrett , Stephen Checkoway Date: Thu, 12 Mar 2015 00:28:45 -0700 Importance: Normal In-Reply-To: <201503120326.38588.davemgarrett@gmail.com> References: <201503081339.47927.davemgarrett@gmail.com>, <201503111456.38308.davemgarrett@gmail.com>, , <201503120326.38588.davemgarrett@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2015 07:28:45.0636 (UTC) FILETIME=[2C920040:01D05C96] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:28:47 -0000 > On Thursday=2C March 12=2C 2015 01:01:27 am Stephen Checkoway wrote:=0A= >>=0A= >> On Mar 11=2C 2015=2C at 2:56 PM=2C Dave Garrett = wrote:=0A= >>=0A= >>> On Tuesday=2C January 20=2C 2015 11:01:31 pm Xiaoyin Liu wrote:=0A= >>>> (5) Number of sites that are tolerant to (TLS1.3=2C TLS1.3): 397=2C152= (93.1%)=0A= >>>> (6) Number of sites that need to fallback to (TLS1.0=2C TLS1.3): 22=2C= 461 (5.3%)=0A= >>>> (7) Number of sites that need to fallback to (TLS1.0=2C TLS1.2): 6=2C3= 52 (1.5%)=0A= >>>> (8) Number of sites that need to fallback to (TLS1.0=2C TLS1.0): 454 (= 0.1%)=0A= >>>>=0A= >>>> The total number of TLS enabled sites is 426=2C419. TLS 1.3 intolerant= sites (7 and 8) are about 1.6%.=0A= >>=0A= >> Most of this is about the record layer version=0A= >=0A= > I just wanted to post the full data set here so it wasn't out of context.= =0A= >=0A= >> The real data here is that 1.5% of servers are intolerant of 1.3 but tol= erate 1.2. So that was (a) and (b) in my list but it's pretty hard to measu= re (c): servers that aren't maintained or can't be upgraded.=0A= >>=0A= >> I remain unconvinced=2C but others can weigh in.=0A= >=0A= > Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant an= d browser vendors are STILL having trouble dropping insecure fallback=2C if= they are attempting it at all. The TLS 1.3 intolerance problem is over an = order of magnitude worse.=0A= >=0A= > To be precise=2C most of these servers are likely considered maintained a= nd can technically be upgraded=2C but that doesn't mean they actually will.= Starting out with this untamed mess could discourage TLS 1.3 adoption and = will encourage browsers to do insecure fallback for TLS 1.3.=0A= Personally=2C I'd be actually fine with insecure fallback with a deadline (= of maybe a year) to drop it.=0A= =0A= Yuhong Bao=0A= = From nobody Thu Mar 12 01:25: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 ADCBC1A1A22 for ; Thu, 12 Mar 2015 01:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 74SUqgkvK2zw for ; Thu, 12 Mar 2015 01:25:34 -0700 (PDT) Received: from BLU004-OMC3S3.hotmail.com (blu004-omc3s3.hotmail.com [65.55.116.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EF71A8AEB for ; Thu, 12 Mar 2015 01:25:33 -0700 (PDT) Received: from BLU177-W50 ([65.55.116.72]) by BLU004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 01:25:32 -0700 X-TMN: [z/1TxeGPaYqqxlOF9We7C1e5RkvLhjoC] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "mrex@sap.com" , Dave Garrett , "maray@microsoft.com" , "andrei.popov@microsoft.com" Date: Thu, 12 Mar 2015 01:25:32 -0700 Importance: Normal In-Reply-To: <20150311184603.DBDB21B21B@ld9781.wdf.sap.corp> References: <201503111252.23754.davemgarrett@gmail.com>, <20150311184603.DBDB21B21B@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2015 08:25:32.0732 (UTC) FILETIME=[1B5B97C0:01D05C9E] Archived-At: Cc: Stephen Checkoway , "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 08:25:35 -0000 > Dave Garrett wrote:=0A= >>=0A= >> The primary source of TLS version intolerance is the small portion of=0A= >> the Internet running junk they haven't upgraded in a decade and a half.= =0A= >=0A= > Just FYI=2C all Servers that are running Microsoft Windows 2008R2=2C 2012= & 2012R2=0A= > and have TLSv1.2 enabled=2C are de-facto version-intolerant to TLSv1.2=0A= > They will abort the connection when receiving an extension-less=0A= > ClientHello with ClientHello.client_version =3D (3=2C3)=2C while the hand= shake=0A= > will succeed with ClientHello.client_version =3D (3=2C2) or when the=0A= > server has TLSv1.2 disabled (the latter is the default for Win7/2008R2).= =0A= =0A= As a side note=2C does the March updates includes any fixes to SChannel oth= er than FREAK and the Cisco OneConnect bug?=0A= =0A= Yuhong Bao=0A= = From nobody Thu Mar 12 03:45: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 597081A9152 for ; Thu, 12 Mar 2015 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_gDxIkCtAlM for ; Thu, 12 Mar 2015 03:45:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 E8B271A8742 for ; Thu, 12 Mar 2015 03:45:07 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CAj7w7009835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 06:45:07 -0400 Received: from pintsize.usersys.redhat.com (dhcp-0-213.brq.redhat.com [10.34.0.213]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2CAj4N1001915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 06:45:05 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 12 Mar 2015 11:44:57 +0100 Message-ID: <2049861.qxnQDrsdPa@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.18.7-100.fc20.x86_64; KDE/4.14.4; x86_64; ; ) In-Reply-To: References: <201503081339.47927.davemgarrett@gmail.com> <201503111252.23754.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1677618.yIMdKo3UC0"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:45:09 -0000 --nextPart1677618.yIMdKo3UC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 11 March 2015 19:43:20 Yngve N. Pettersen wrote: > If one want to avoid such future interoperability concerns, the only = way > to avoid them is to create a exhaustive certification test suite that= all > implementations have to pass in order to call themselves TLS 1.3, 1.4= , 1.5 > etc. server/client. I'd say it's surprising that there isn't something like that yet. =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 --nextPart1677618.yIMdKo3UC0 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 iQIcBAABAgAGBQJVAW4vAAoJEJKo0bgB0vX1cNkP/1uLcaIH/sr9tmqqF0Dbb+ht yHK1piBSxQN2Mql6U51FgxIqOLbDIYd2zIGBnJl0Szk9yQn2sU0Sk99Uwa21RWUV 9kPKLFU5pDuMDHTdOpdKJiMeqWUYOyM3BT996KyYkhXPfOlsBYbVRcv6273Zwffu eQJgKD1sXK9tBbTb26AEHCBTCtPOXKWehX3zQ+TqM8vXitnhUnvVnWjsqEsTH9Mq WmOed8Zl/PuwJcnC7uxromqbKnGYp+Ke5EF6GwGyl3+O4dl5wwjtbMDA1+dbtTE2 A8wK/NIJDcVDpq37bc3uaSnDAsudHr2I08CKBoB4lEHxZFVZeps3OdscBF5Wu03h YmZCR42EJlLhrTF+ZX0WE4tq03rOd6jT0/kglYdzSE+n8/v/SYPw7Q12KDOlZKTC r/jqzfeN/kqyQUZCsj07cKv/xQj0d+ogDOR1kWU+7VQHkGESvEK4X/JVI+ONrW0O 3VxTCWT8C/m1BGNOBAscM5EhV7VnMqo6N8qlT/kCTYxvU4hFylave2WLZOdz51lA cZ1U3lKAGVjBUY8VBK4mUiC7ao0C5Z8/yOhgk9zngPagy1WkttTlKkjTwfBD6AlP tdweieHOmz4dLDpR0VZwzklJeAAmcexJ1bCCr7a8LDZ2ayu1iHRSRDaWzJ22d/jv ItUypKsAxNPsGdbrMhSn =cUJq -----END PGP SIGNATURE----- --nextPart1677618.yIMdKo3UC0-- From nobody Thu Mar 12 07:42: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 71D151A1BCC for ; Thu, 12 Mar 2015 07:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfckmONS2O1H for ; Thu, 12 Mar 2015 07:42:43 -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 C97551A1B19 for ; Thu, 12 Mar 2015 07:42:43 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CB2BC2853B; Thu, 12 Mar 2015 14:42:42 +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 B8E9028537; Thu, 12 Mar 2015 14:42:42 +0000 (GMT) Received: from bos-mp1wn.kendall.corp.akamai.com (unknown [172.19.41.235]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A82F28004B; Thu, 12 Mar 2015 14:42:42 +0000 (GMT) From: Brian Sniffen To: Dave Garrett , Aaron Zauner In-Reply-To: <201503091419.30893.davemgarrett@gmail.com> References: <201503081450.04610.davemgarrett@gmail.com> <54FDD024.3080309@azet.org> <201503091419.30893.davemgarrett@gmail.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Thu, 12 Mar 2015 10:42:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:42:45 -0000 Dave Garrett writes: > ChaCha20/Poly1305 MUST implement > AES-GCM SHOULD implement; MUST implement if TLS 1.2 backwards compatible > AES-OCB RECOMMENDED or SHOULD implement Does that imply that servers should prefer AES-OCB, AES-GCM, ChaCha20, in that order? If any other order, what's the point of including the later ciphers? I expect that implementations that have to use FIPS-only crypto will not implement ChaCha20 no matter what is said here. -Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somewhere along the spectrum from insufficiently nuanced through ill-informed to dead wrong." From nobody Thu Mar 12 08:39:34 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 009311A88EE for ; Thu, 12 Mar 2015 08:39: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 exZy-KWs4fgI for ; Thu, 12 Mar 2015 08:39:31 -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 B7F601A88EA for ; Thu, 12 Mar 2015 08:39:31 -0700 (PDT) Received: by qgdq107 with SMTP id q107so18962778qgd.7 for ; Thu, 12 Mar 2015 08:39:31 -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=KdL5i00KNQ92VUKF/W4dJEbJpZ5bP8hH7PDdUVbVsCc=; b=Tl+/VPo97p/0WW/LPJY0PKpEqMiYQMGyiPCon3Zt6UulpVqP3fjDYi7hBXZ1TzAYH8 gR303tmbDpaWyL+iQ0+pGE475ruEDrBTviGy7Bxztw1bO35TxGFPu00Hpn7nFnUI88p3 cYTc0eJpKHOTMLsGbL78wyzgdyiSy+/DUm2o5uXcCDP/cdHnZzWRFkw2byKb4IeHpesL hUXxKpzVhul4xYUQbIUStloJxp5cSHnBkNZdnq9397FT/6Y2nOkWQt9UyAAPu43tsbvw w4jcbGz97gD3HTvAy4J7ajIMk85DzQW54yuUIQoJzTTM3eAKtLRXHOqmSVJ08af8EIPx U+Gg== X-Received: by 10.55.16.159 with SMTP id 31mr36779785qkq.80.1426174771079; Thu, 12 Mar 2015 08:39:31 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id a92sm4986260qgf.11.2015.03.12.08.39.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 08:39:30 -0700 (PDT) From: Dave Garrett To: Brian Sniffen Date: Thu, 12 Mar 2015 11:39:29 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503091419.30893.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503121139.29631.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:39:33 -0000 On Thursday, March 12, 2015 10:42:42 am Brian Sniffen wrote: > Does that imply that servers should prefer AES-OCB, AES-GCM, ChaCha20, > in that order? If any other order, what's the point of including the > later ciphers? I don't see any need to require implementations to prefer an order. The point is to have choices for different use cases, and to have backups in the event of one of them turning out to be broken. Dave From nobody Thu Mar 12 15:24: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 3BD5D1A8795 for ; Thu, 12 Mar 2015 15:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCU6BWHw450C for ; Thu, 12 Mar 2015 15:24:18 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.185.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FAF1A701A for ; Thu, 12 Mar 2015 15:24:18 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 72DC910FE11FA; Thu, 12 Mar 2015 17:24:17 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 6286E10FE117C for ; Thu, 12 Mar 2015 17:24:17 -0500 (CDT) Received: from [96.231.226.227] (port=58620 helo=[192.168.1.8]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YWBWa-0003cm-Qp for tls@ietf.org; Thu, 12 Mar 2015 17:24:17 -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: <20150308180310.GA10911@LK-Perkele-VII> Date: Thu, 12 Mar 2015 18:24:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <661509F2-ABBA-4D9B-9AC2-7A56E328742A@ieca.com> References: <20150308180310.GA10911@LK-Perkele-VII> To: "tls@ietf.org" 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.226.227 X-Exim-ID: 1YWBWa-0003cm-Qp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.8]) [96.231.226.227]:58620 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 22:24:19 -0000 On Mar 08, 2015, at 14:03, Ilari Liusvaara = wrote: > MTI cipher suites: I=92m going to start a thread specific to what was discussed in Seattle = wrt algorithms.* Not going to happen until at least tomorrow though. spt * Obviously, what we settled on will be confirmed on list and I have no = doubt discussed in Dallas.= From nobody Thu Mar 12 16:58: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 57B821A885D for ; Thu, 12 Mar 2015 16:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ol_iAyQs0j7w for ; Thu, 12 Mar 2015 16:58:37 -0700 (PDT) Received: from BLU004-OMC3S35.hotmail.com (blu004-omc3s35.hotmail.com [65.55.116.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C503A1A8850 for ; Thu, 12 Mar 2015 16:58:36 -0700 (PDT) Received: from BLU177-W17 ([65.55.116.72]) by BLU004-OMC3S35.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 16:58:35 -0700 X-TMN: [d+w+RdSYNmujj0MAKSwRJblccWI3Xvby] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Dave Garrett , Stephen Checkoway Date: Thu, 12 Mar 2015 16:58:35 -0700 Importance: Normal In-Reply-To: <201503120326.38588.davemgarrett@gmail.com> References: <201503081339.47927.davemgarrett@gmail.com>, <201503111456.38308.davemgarrett@gmail.com>, , <201503120326.38588.davemgarrett@gmail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2015 23:58:35.0735 (UTC) FILETIME=[73D3EE70:01D05D20] Archived-At: Cc: "rdugal@certicom.com" , "tls@ietf.org" Subject: Re: [TLS] A new TLS version negotiation mechanism X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 23:58:38 -0000 > On Thursday=2C March 12=2C 2015 01:01:27 am Stephen Checkoway wrote:=0A= >>=0A= >> On Mar 11=2C 2015=2C at 2:56 PM=2C Dave Garrett = wrote:=0A= >>=0A= >>> On Tuesday=2C January 20=2C 2015 11:01:31 pm Xiaoyin Liu wrote:=0A= >>>> (5) Number of sites that are tolerant to (TLS1.3=2C TLS1.3): 397=2C152= (93.1%)=0A= >>>> (6) Number of sites that need to fallback to (TLS1.0=2C TLS1.3): 22=2C= 461 (5.3%)=0A= >>>> (7) Number of sites that need to fallback to (TLS1.0=2C TLS1.2): 6=2C3= 52 (1.5%)=0A= >>>> (8) Number of sites that need to fallback to (TLS1.0=2C TLS1.0): 454 (= 0.1%)=0A= >>>>=0A= >>>> The total number of TLS enabled sites is 426=2C419. TLS 1.3 intolerant= sites (7 and 8) are about 1.6%.=0A= >>=0A= >> Most of this is about the record layer version=0A= >=0A= > I just wanted to post the full data set here so it wasn't out of context.= =0A= >=0A= >> The real data here is that 1.5% of servers are intolerant of 1.3 but tol= erate 1.2. So that was (a) and (b) in my list but it's pretty hard to measu= re (c): servers that aren't maintained or can't be upgraded.=0A= >>=0A= >> I remain unconvinced=2C but others can weigh in.=0A= >=0A= > Let me put it to you this way: ~0.1% of servers are TLS 1.2 intolerant an= d browser vendors are STILL having trouble dropping insecure fallback=2C if= they are attempting it at all.=0A= Many of them seems to be caused by older versions of the Certicom TLS stack= used in older versions of Oracle Application Server for example.=0A= It seems that renego patched versions will tolerate TLS 1.2 if TLS 1.0 is u= sed in the record layer:=0A= https://www.ssllabs.com/ssltest/analyze.html?d=3Dwindecare.wind.it=0A= https://www.ssllabs.com/ssltest/analyze.html?d=3Dservice.oneaccount.com=0A= (Notice that IE/Java fails but Firefox/Chrome works)=0A= =0A= Yuhong Bao=0A= = From nobody Fri Mar 13 01:24: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 3E6761A19FA for ; Fri, 13 Mar 2015 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-VFda3-l3cu for ; Fri, 13 Mar 2015 01:23:57 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50981A19F7 for ; Fri, 13 Mar 2015 01:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1426235037; x=1457771037; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KGPnp7EFvt/3qOf/ADbYr3C4MUUt5UGd2LTl0zGF7JM=; b=VB4OTcQBojGQu50mhB8KocuKCCgxwTCVOxUl60A5qyzDsVgwA79eFMOj fC26L1yqvefmpRYysd2HUxNLK6VShKjEjFqVqh/GVYQ1KA1nqfW/ZBfuA lRe7TPY2/BA0ZAG5R12m1r9MNXvGRsmmjhXeLkJ6/JzmbwRUwx0bp+pzP o=; X-IronPort-AV: E=Sophos;i="5.11,393,1422874800"; d="scan'208";a="313514349" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Mar 2015 21:23:54 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0174.001; Fri, 13 Mar 2015 21:23:54 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) Thread-Index: AdBdZwrud4g/YNomR6yPQ0pyNFsy4w== Date: Fri, 13 Mar 2015 08:23:54 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFB046F@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Comments on various things on agenda (Was: Re: TLS Interim - update and agenda) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 08:24:05 -0000 Ilari Liusvaara writes:=0A= =0A= >Here by backwards compatiblity, I interpret:=0A= >=0A= >"Possiblity to securely downnegotiate to earlier versions without reconnec= t."=0A= =0A= Ah, I see. In that case why not just have a TLS 1.x-compatible client hell= o=0A= for TLS 2.0, in the same way that we had the SSLv2-compatible client hello = for=0A= SSLv3 and TLS 1.x? That means you get backwards compatibility without havi= ng=0A= to drag a large amount of TLS 1.x baggage around in TLS 2.0.=0A= =0A= Peter.= From nobody Fri Mar 13 07:43: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 B136C1A89F1 for ; Fri, 13 Mar 2015 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rZIckxESF9_z for ; Fri, 13 Mar 2015 07:42:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 24FF11A8A11 for ; Fri, 13 Mar 2015 07:42:28 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3CE7A48B3120A for ; Fri, 13 Mar 2015 14:42:24 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2DEgLsF012418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Mar 2015 15:42:26 +0100 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; Fri, 13 Mar 2015 15:42:23 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "GUBALLA, JENS (JENS)" Thread-Topic: draft-guballa-tls-terminology-00.txt Thread-Index: AdBabsQr/duhNwM3QrKauCX1hG6RZgDLMmTw Date: Fri, 13 Mar 2015 14:42:23 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC4B3A3B8E@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <547EE95EB794FD4DB8062F7A4C86D0BC4A33AF99@FR712WXCHMBA13.zeu.alcatel-lucent.com> In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A33AF99@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] draft-guballa-tls-terminology-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 14:43:01 -0000 With regards to 3.5.2. Term "(D)TLS session rekeying" Would suggest to add following sentence to "Notes:": [RFC5763], clause 6.8 provides a high-level description of a "rekeying con= cept" in context of DTLS-based SRTP key management. -Albrecht -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of GUBALLA, JENS (JENS) Sent: Montag, 9. M=E4rz 2015 14:42 To: TLS@ietf.org (tls@ietf.org) Subject: [TLS] draft-guballa-tls-terminology-00.txt Hello, Based on the study of TLS- and DTLS-related RFCs we defined a set of (D)TLS= terminology terms (http://tools.ietf.org/id/draft-guballa-tls-terminology-= 00.txt). We put the focus on key terms which were causing some controversy = so far (other IETF-WGs, outside of IETF). The purpose of this document is to provide a central place of key terms as = used in TLS and DTLS RFCs. We are appreciating any feedback. Thanks, Jens and Juergen From nobody Fri Mar 13 22:43: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 0C5661AC3F8 for ; Fri, 13 Mar 2015 22:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.112 X-Spam-Level: X-Spam-Status: No, score=-5.112 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_HI=-5, 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 bVhBWQkcCHOo for ; Fri, 13 Mar 2015 22:43:15 -0700 (PDT) Received: from prodomx02.usaa.com (prodomx02.usaa.com [167.24.25.92]) (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 2BD451AC3F7 for ; Fri, 13 Mar 2015 22:43:14 -0700 (PDT) Received: from pps.filterd (prodomx02.usaa.com [127.0.0.1]) by prodomx02.usaa.com (8.14.7/8.14.7) with SMTP id t2E5hDaf020137 for ; Sat, 14 Mar 2015 00:43:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=201408; bh=pxkH0A0QOnH+lbj9p9ux4rrO6GaWukd8ZNb5VCLIvVk=; b=S75FCPRW86M62H2wt2k5rI266PbVLMrdBjSKBZbdtgHmVL0pXADcVIIQk5lq/fWxPjKB hF+uB5JWbiESgzq6qb6OxMWK93zbZv43jAR5ppVBjNT2A5Zivc8pIWK7ZPuYNZeaAw3V r7arHLlQ812BtbXK8iDGQIFkoPKPBC0F1ktjPy1lPPRxK1Np78EAkF2pJk/ck2dbNL/7 zO7eXBahDwaBsGha9gjo+0eicWbrAps4m3eVgeZOG+a5C+iug04+4FphALs36aniT9QU ljyhNLSgI3q7B2a+pAGJ1cQlDn38cme5KO+hwYRxdXB5jdV0pp99i8B9x4EHPux8QIHG FA== Received: from prodexch04w.eagle.usaa.com (prodexch04w.eagle.usaa.com [10.170.40.30]) by prodomx02.usaa.com with ESMTP id 1t36ba5uj3-1 for ; Sat, 14 Mar 2015 00:43:13 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.159]) by PRODEXCH04W.eagle.usaa.com ([10.170.40.30]) with mapi id 14.03.0158.001; Sat, 14 Mar 2015 00:43:13 -0500 From: "Mehner, Carl" To: "tls@ietf.org" Thread-Topic: Client Request and ecdsa_sign Thread-Index: AdBeFxZAgbOQWepsTpeFtVwI35PnEA== Date: Sat, 14 Mar 2015 05:43:12 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D41145EEAA@PRODEXMB01W.eagle.usaa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.191.4.19] x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-14_01:2015-03-13,2015-03-14,1970-01-01 signatures=0 Archived-At: Subject: [TLS] Client Request and ecdsa_sign X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 05:43:17 -0000 I created a new issue on GitHub: https://github.com/tlswg/tls13-spec/issues/154 Right now it appears that ecdsa certificates are not allowed for use as cli= ent certificates. Should we explicitly state that they may be used in the C= lient Certificate section? this would add an element (ecdsa_sign(64)) to the ClientCertificateType enu= m to make it: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) } ClientCertificateType; as well as a new line to the certificate_types: ecdsa_sign a certificate containing an ECDSA key I suppose we could add in the ecdsa_fixed_ecdh as well... but weren't we tr= ying to go pure ephemeral? If so, should we take out the other *_fixed_dh identifiers? Already the par= agraph that starts, "For historical reasons," says those have been obsolete= d. From nobody Fri Mar 13 23:12: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 E987F1AC405 for ; Fri, 13 Mar 2015 23:12:56 -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 1Sapx0DYSTRs for ; Fri, 13 Mar 2015 23:12:55 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::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 B0AB21AC402 for ; Fri, 13 Mar 2015 23:12:55 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so6114926qcb.2 for ; Fri, 13 Mar 2015 23:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=H/DpozSbjM2wM1uh8g2jZKwJgQtztWp6eh6Aoi02UI8=; b=1HZH6CZwwejK0abe4pxT/6uV6JYaTDZjCAm310s3CMPZqUHm80kVgvxneMCWUhU/Bg /rGcxydk9Rx+OwyRPc0Hf2hwVBFW2BhZEncYAcxfFhhhz1zJTWxTko1k/otBnmO8CJ2P OXWYRLaKCEz270i6jcnC6B3sZZpssBN3zle9tJkqABwrJatzbZQ8FKTOMKjpxu42f/Sb U1GbXe4jkAZOXEGSVmwYMckF66BHvMyGiCMd71XdFmjgkLpgFUudSmDH5NMtiSFYXcIq py7n6WREJqJ/t5ElExPKTHHqxBZOXW5D/k2F1ArLGFiREKxst3FTtTAF0iNcJFX6IA2C nTIA== X-Received: by 10.140.132.197 with SMTP id 188mr66435976qhe.24.1426313575053; Fri, 13 Mar 2015 23:12:55 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id x15sm2960838qkx.28.2015.03.13.23.12.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Mar 2015 23:12:54 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" Date: Sat, 14 Mar 2015 02:12:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201503140212.53255.davemgarrett@gmail.com> Archived-At: Subject: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 06:12:57 -0000 Idea: Add a small section after MTI cipher suites for MTI extensions. After enumerating the extensions that are part of the TLS 1.3 spec itself, I think it would be helpful to list a few other extensions that are reasonable to expect of all implementations. In particular, SNI & ALPN should ideally be available everywhere. (not all deployments would need them, but they should always be available) These are the two HTTP/2 needs to work, so just stating that as a requirement in the TLS 1.3 spec would ensure that all TLS 1.3 implementations are HTTP/2 ready without further consideration. Dave From nobody Sat Mar 14 07:35: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 A8BE61A038E for ; Sat, 14 Mar 2015 07:35:55 -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 q71VdP3yyhX7 for ; Sat, 14 Mar 2015 07:35:54 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (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 B8D6D1A0262 for ; Sat, 14 Mar 2015 07:35:53 -0700 (PDT) Received: by wggv3 with SMTP id v3so8423281wgg.1 for ; Sat, 14 Mar 2015 07:35:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PpsNeeblcvdKABJbEK+q5m3TerbT3DL7r4426xQ7kn8=; b=Z3BAm/a3nCdrBgSiLyokPzq2CxM8d1JppuogSjF8fPENyyix5V9L2g1xJxPEyN0VvK 9EZFMVE/O1nDN1aArzZhl9igCoqNRwtwisFtiqge/p9csQhMi4XWwvrS+RT8aIchw9Ma 68crKzB/eJFDNdqVNxImls7Ge5eswEOvAtnLrnAmeo/+22y4fvNXCoJpYPnmjrNBIwPF dL/iLAY4b0XxG8LFGYGq93b4lZGPOJdwdOpWJisBUVnKx1X13LtwqsfeMpAkMMio+0/4 hqVK5tyzvmuXEtIGMaSagFOzyHJFtjp/fshZ3PSYmaFxsxevgdNfU1JKHuMU3jh4tMSk cXLA== X-Gm-Message-State: ALoCoQnvOa6EJiJE/bhVj6JGILCso5iP5WLzV4eB7voCeyTiJEXZhddMR3sy5LpH1r9+LAJ1Wm2e X-Received: by 10.194.190.10 with SMTP id gm10mr106970958wjc.91.1426343752440; Sat, 14 Mar 2015 07:35:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 14 Mar 2015 07:35:12 -0700 (PDT) In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41145EEAA@PRODEXMB01W.eagle.usaa.com> References: <19075EB00EA7FE49AFF87E5818D673D41145EEAA@PRODEXMB01W.eagle.usaa.com> From: Eric Rescorla Date: Sat, 14 Mar 2015 07:35:12 -0700 Message-ID: To: "Mehner, Carl" Content-Type: multipart/alternative; boundary=047d7bea39f4b1359005114088a5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Client Request and ecdsa_sign X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 14:35:55 -0000 --047d7bea39f4b1359005114088a5 Content-Type: text/plain; charset=UTF-8 I believe we are going to remove this entire field and its associated code points because it is redundant with the signature algorithms. -Ekr On Fri, Mar 13, 2015 at 10:43 PM, Mehner, Carl wrote: > I created a new issue on GitHub: > https://github.com/tlswg/tls13-spec/issues/154 > > > Right now it appears that ecdsa certificates are not allowed for use as > client certificates. Should we explicitly state that they may be used in > the Client Certificate section? > > > this would add an element (ecdsa_sign(64)) to the ClientCertificateType > enum to make it: > > enum { > rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), > rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), > fortezza_dms_RESERVED(20), ecdsa_sign(64), (255) > } ClientCertificateType; > > > > as well as a new line to the certificate_types: > > ecdsa_sign a certificate containing an ECDSA key > > > I suppose we could add in the ecdsa_fixed_ecdh as well... but weren't we > trying to go pure ephemeral? > > If so, should we take out the other *_fixed_dh identifiers? Already the > paragraph that starts, "For historical reasons," says those have been > obsoleted. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bea39f4b1359005114088a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe we are going to remove this entire field and its= associated
code points because it is redundant with the signature algo= rithms.

-Ekr



On Fri, M= ar 13, 2015 at 10:43 PM, Mehner, Carl <Carl.Mehner@usaa.com> wrote:
I created a new issue on GitHu= b:
https://github.com/tlswg/tls13-spec/issues/154


Right now it appears that ecdsa certificates are not allowed for use as cli= ent certificates. Should we explicitly state that they may be used in the C= lient Certificate section?


this would add an element (ecdsa_sign(64)) to the ClientCertificateType enu= m to make it:

enum {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rsa_sign(1), dss_sign(2), rsa_fixe= d_dh(3), dss_fixed_dh(4),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rsa_ephemeral_dh_RESERVED(5), dss_= ephemeral_dh_RESERVED(6),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fortezza_dms_RESERVED(20), ecdsa_s= ign(64), (255)
=C2=A0 =C2=A0 =C2=A0 =C2=A0} ClientCertificateType;



as well as a new line to the certificate_types:

ecdsa_sign=C2=A0 =C2=A0 =C2=A0 =C2=A0 a certificate containing an ECDSA key=


I suppose we could add in the ecdsa_fixed_ecdh as well... but weren't w= e trying to go pure ephemeral?

If so, should we take out the other *_fixed_dh identifiers? Already the par= agraph that starts, "For historical reasons," says those have bee= n obsoleted.

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

--047d7bea39f4b1359005114088a5-- From nobody Sat Mar 14 11:21:43 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 B44271A00EF; Sat, 14 Mar 2015 11:21:39 -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 tY16nLt8tbbQ; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c: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 4F8971A00C8; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: by wixw10 with SMTP id w10so11399445wix.0; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HCkgWH9OcYpZ+v8LcK8G6NZ5+Ccwc7sz1b6y6K+rqN4=; b=KcGVOmA90gwS+xsK53RbuD/AhMLbwk4/Ny+P5XNVgrqj8IJjdMVNnWaW5R4qziQLEg aYAiYL3yEvUsdIGUND1M5srU07gqiXVzFEb1IQPiBbDT5qsSIITqfPQCBnkVdkXf5ZgH HgTQ0UQSQHt71nXuzHq5loUrm4P/y2lNAXIZqupF4pUVQrtu7JzPbbyPCipNSx87OLUV Zid0sSgVCFCrgY4Em3j6VU4FbhsyAE4phB74uIVaj8+t/Wt241cdoe072yUH9oiodPUA s5Iz2LsGq1KMhwg5iKzTYR1bz18mdGQlLwFEVajW2wKeozRFingjYW55IebWlLmB+RzY A4vQ== X-Received: by 10.180.98.67 with SMTP id eg3mr40191276wib.11.1426357297004; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id ka1sm7996177wjc.2.2015.03.14.11.21.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 11:21:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sat, 14 Mar 2015 20:21:34 +0200 Message-Id: References: To: "Boyle, Vincent M" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" , Security Area Advisory Group , "tls@ietf.org" Subject: Re: [TLS] [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:21:39 -0000 --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mike > Please discuss on the saag mail list. I will schedule = a meeting time at a local drinking establishment for either Monday or = Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d appreciate = feedback on the meeting times (if you expect to attend) as well as any = comment on the usefulness or feasibility of this effort. On Wednesday there is going to be a I2NSF side meeting that is likely to = attract many of the same people. I would go with Monday. Yoav= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Mike

      =           Please discuss on the  saag mail = list. I will schedule a meeting time at a local drinking establishment = for either Monday or Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d= appreciate feedback on the meeting times (if you expect to attend) as = well as any comment on the usefulness or feasibility of this = effort.

On Wednesday there is going to be a = I2NSF side meeting that is likely to attract many of the same people. I = would go with Monday.

Yoav
= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890-- From nobody Sat Mar 14 20:40: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 604E21A0AF1 for ; Sat, 14 Mar 2015 20:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 bvpEEO_IY6j9 for ; Sat, 14 Mar 2015 20:40:44 -0700 (PDT) Received: from prodomx02.usaa.com (prodomx02.usaa.com [167.24.25.92]) (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 44CFA1A03A9 for ; Sat, 14 Mar 2015 20:40:43 -0700 (PDT) Received: from pps.filterd (prodomx02.usaa.com [127.0.0.1]) by prodomx02.usaa.com (8.14.7/8.14.7) with SMTP id t2F3ZtPm028691; Sat, 14 Mar 2015 22:40:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=201408; bh=Wr1ibySFVHIvHtyUXlDYiqmrNSgP1irhYUW9uGHaeWQ=; b=WeUgukt1WJaYhUwed4pkcQIxoYi1OKsD1vRgGJHUTI8/UFaRSq1Mb1w7kuRzjh0MZFsW ByHzkVeEMiXRaydZ08bdyI51WmpYxtRS0pU1X4zuQRJl0L4L/vPCjEymEwPl/H2bFtX2 CGlUr5eL1tqoWjWO+Ju3TKMuyrSUwVsX0jZUwpJGu3dtj/Js3OAt0PP0yxBOaYcHQUJS kjoDGB19tArUoWa3BVW2plS764BjJNruyisgHRk414al22QZOwn6/WpSf0ypET+zqc2Y 8L4FWuO7stBMRIxaRsGwcpQru+aLuSGGpJUErNn/dVeI8JCyBE+4Pfjg+fPC5SlJ7aU6 KQ== Received: from prodexch06w.eagle.usaa.com (prodexch06w.usaa.com [10.170.40.22]) by prodomx02.usaa.com with ESMTP id 1t36ba7ndd-1; Sat, 14 Mar 2015 22:40:41 -0500 Received: from PRODEXCH01W.eagle.usaa.com (10.70.41.151) by PRODEXCH06W.eagle.usaa.com (10.170.40.22) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 14 Mar 2015 22:40:41 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.159]) by PRODEXCH01W.eagle.usaa.com ([10.70.41.151]) with mapi id 14.03.0158.001; Sat, 14 Mar 2015 22:40:41 -0500 From: "Mehner, Carl" To: Eric Rescorla Thread-Topic: Signature Algorithms Thread-Index: AQHQXmX8asKK2lJ1wUKslyiYez0tCg== Date: Sun, 15 Mar 2015 03:40:38 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.191.4.19] x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-14_02:2015-03-13,2015-03-14,1970-01-01 signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 03:40:46 -0000 >I believe we are going to remove this entire field and its associated=0A= >code points because it is redundant with the signature algorithms.=0A= sounds good.=0A= =0A= Speaking of Signature Algorithms, what do you think of this?=0A= =0A= =0A= Since root certificates are trusted by their identity rather than the signa= ture I think that amendments to the text in the Server Certificates and Cer= tificate Request sections are necessary.=0A= =0A= As we move into a world that lacks trusted SHA-1 signatures, a change in th= e text would be necessary in order for clients that drop SHA-1 from the sup= ported hash algorithms to continue to connect to servers that send a certif= icate_list that includes roots signed with SHA-1.=0A= =0A= This has been an issue recently with a browser that did not include the MD2= signature algorithm in this client extension. When it encountered a certif= icate that sends the root in the certificate_list, the client closes the co= nnection (likely before evaluating if there was an alternate trusted chain)= . I can see this being an issue in the future with the SHA-1 2048-bit roots= .=0A= =0A= In the Server Certificates section:=0A= OLD:=0A= =0A= If the client provided a "signature_algorithms" extension, then all=0A= certificates provided by the server MUST be signed by a=0A= hash/signature algorithm pair that appears in that extension. Note=0A= that this implies that a certificate containing a key for one=0A= signature algorithm MAY be signed using a different signature=0A= algorithm (for instance, an RSA key signed with a DSA key). This is=0A= a departure from TLS 1.1, which required that the algorithms be the=0A= same.=0A= =0A= NEW:=0A= =0A= If the client provided a "signature_algorithms" extension, then all=0A= certificates provided by the server, except for the self-signed=0A= root CA certificate, MUST be signed by a hash/signature algorithm=0A= pair that appears in that extension. Note that this implies that=0A= a certificate containing a key for one signature algorithm MAY be=0A= signed using a different signature algorithm (for instance, an=0A= RSA key signed with a DSA key). This is a departure from TLS 1.2,=0A= which required that all provided certificate signature algorithms=0A= be included in the client extension regardless of whether or not=0A= they were evaluated.=0A= =0A= Likewise in the Certificate Request section,=0A= OLD:=0A= - Any certificates provided by the client MUST be signed using a=0A= hash/signature algorithm pair found in=0A= supported_signature_algorithms.=0A= NEW: =0A= - Any certificates provided by the client, except for the=0A= self-signed root CA certificate, MUST be signed using a=0A= hash/signature algorithm pair found in=0A= supported_signature_algorithms.=0A= From nobody Sun Mar 15 11:08: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 82E011A1B60 for ; Sun, 15 Mar 2015 11:08: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 170onLi1Fz3X for ; Sun, 15 Mar 2015 11:08:24 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 3C6E81A1B5F for ; Sun, 15 Mar 2015 11:08:24 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so21152917obb.1 for ; Sun, 15 Mar 2015 11:08: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=8BR3IedZ7fNEJqft/ba5+jmZhtjCXI+FPw0HRDs6M+g=; b=YgP8fOPA2lVMgZ7ieLzz2WLw/EbeK8PoFRIUlEmDUe8jDcYIg1yE+kk9OGrXklyMuK 86CzOzz/4sn7b4Gn8e3oqd8hD+eMO300puShdfzssLLu7FxBiYjS31Z6Re8l1AGvjPol GXh+0fd5RE36W0UtRQ0usb5VPj1XhWLi/fphNtrkpLzJ5v5j66QoVCjU7yhX80jvnz0o YxPyCoytDcTfX0TPssSpNk4zsfrK33DrN4Yihk/I5N4/axqz8rRET+b8SlsOz6l1Zl6P +96pzFK2MwvkcX1WoAh/UK6kudK1YyPHN4yakWJobeDvqLR6bhnM0EOgPtaAtfU7Ylq8 F/4A== MIME-Version: 1.0 X-Received: by 10.60.84.40 with SMTP id v8mr9273177oey.80.1426442903601; Sun, 15 Mar 2015 11:08:23 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Sun, 15 Mar 2015 11:08:23 -0700 (PDT) In-Reply-To: <201503140212.53255.davemgarrett@gmail.com> References: <201503140212.53255.davemgarrett@gmail.com> Date: Sun, 15 Mar 2015 11:08:23 -0700 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:08:25 -0000 On 13 March 2015 at 23:12, Dave Garrett wrote: > Idea: Add a small section after MTI cipher suites for MTI extensions. I think that's fine. Signature algorithms was made mandatory in 1.2, here, we are going to make ClientKeyShare mandatory. I think that there is good justification for SNI too. > After enumerating the extensions that are part of the TLS 1.3 spec itself, I think it would be helpful to list a few other extensions that are reasonable to expect of all implementations. In particular, SNI & ALPN should ideally be available everywhere. I don't see any point in making ALPN mandatory. If you need it, you need it; if you don't, that's all there is to say. From nobody Sun Mar 15 11:23: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 664F21A1B62 for ; Sun, 15 Mar 2015 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSTbHJ0TWEHi for ; Sun, 15 Mar 2015 11:22:59 -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 5D0531A1B60 for ; Sun, 15 Mar 2015 11:22:58 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3696E2859E; Sun, 15 Mar 2015 18:22:57 +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 0A6F92859D; Sun, 15 Mar 2015 18:22:57 +0000 (GMT) Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id E4AD280040; Sun, 15 Mar 2015 18:22:56 +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.913.22; Sun, 15 Mar 2015 13:21:39 -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.0913.011; Sun, 15 Mar 2015 13:21:21 -0500 From: "Salz, Rich" To: Martin Thomson , Dave Garrett Thread-Topic: [TLS] MTI extensions? Thread-Index: AQHQX0sMs4ufdYISFEu+mUiTAoOQRZ0d2vDA Date: Sun, 15 Mar 2015 18:21:20 +0000 Message-ID: References: <201503140212.53255.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.56.167] 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] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:23:01 -0000 Agree with mt: SNI yes, ALPN not mandatory. -- =20 Senior Architect, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Sun Mar 15 11:25:34 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 607751A1B62 for ; Sun, 15 Mar 2015 11:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pJhJKLmWP2bi for ; Sun, 15 Mar 2015 11:25:32 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDE11A1B5F for ; Sun, 15 Mar 2015 11:25:31 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id A52C3817F6; Sun, 15 Mar 2015 20:25:29 +0200 (EET) Date: Sun, 15 Mar 2015 20:25:29 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20150315182529.GB16994@LK-Perkele-VII> References: <201503140212.53255.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] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:25:33 -0000 On Sun, Mar 15, 2015 at 11:08:23AM -0700, Martin Thomson wrote: > On 13 March 2015 at 23:12, Dave Garrett wrote: > > Idea: Add a small section after MTI cipher suites for MTI extensions. > > I think that's fine. Signature algorithms was made mandatory in 1.2, > here, we are going to make ClientKeyShare mandatory. I think that > there is good justification for SNI too. > > > After enumerating the extensions that are part of the TLS 1.3 spec > itself, I think it would be helpful to list a few other extensions > that are reasonable to expect of all implementations. In particular, > SNI & ALPN should ideally be available everywhere. > > I don't see any point in making ALPN mandatory. If you need it, you > need it; if you don't, that's all there is to say. Also, regarding ALPN... It occurs to me ALPN interacts with early client data (if doing that). E.g. One certainly does not want earlydata for HTTP/2 to be played upon HTTP/1.1 (or vice versa). Also, regarding ALPN, if ALPN is mandated, what API capabilities should it have? The simplest (set proposed/supported list, get selected protocol) or something more complicated? Also, there are extensions one doesn't want to appear in TLS 1.3 (however proposing is possible for backward compat.). Some candidates are: - truncated_hmac (does nothing [block ciphers only]) - srp (if SRP is not supported). - encrypt_then_mac (does nothing [block ciphers only]) - extended_master_secret (can't do anything sane besides no-op) - renegotiation_info (no renegotiation is possible). -Ilari From nobody Sun Mar 15 11:27:45 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 D12981A1B63 for ; Sun, 15 Mar 2015 11:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J2M7D3HvmTH for ; Sun, 15 Mar 2015 11:27:42 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 721D21A1B6D for ; Sun, 15 Mar 2015 11:27:42 -0700 (PDT) Received: by obfv9 with SMTP id v9so21256328obf.2 for ; Sun, 15 Mar 2015 11:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xYJe0FrlSK4NqTWZoPAqPNMoBCoXBpJYBwad+MTMNnI=; b=Cy+FS7gwvLeLMb0vg+WJdunevI5UZGiClLn16geo/T0s5XiY5pBlvle59X/4PPqebh WERY0rnvrI5A5HIrGy08RHMktymP9UWwV3fi2ixPHCwkEu/xJDxLoSNs8ZbCT3osEn9H BggjnKbk7fLf6SLdW0Hygw9RWzUQYECk8RWAXxm83piV5rIAub/m58wJlqJhjSypC8le zaoCcsakUtbO1WtowALoXvUsU3eEGkIcrDPjoDKoeXNcLpd3bbRufeUk3o/bHNq4jtCS ayREDHpvj6ZWmMfqsu1MajsjilYO7VrweY26PS5wvM2FSpSGfrEsJX6olm4ke1ezl/ST jXLg== MIME-Version: 1.0 X-Received: by 10.60.129.161 with SMTP id nx1mr44882006oeb.77.1426444062039; Sun, 15 Mar 2015 11:27:42 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Sun, 15 Mar 2015 11:27:41 -0700 (PDT) In-Reply-To: <20150315182529.GB16994@LK-Perkele-VII> References: <201503140212.53255.davemgarrett@gmail.com> <20150315182529.GB16994@LK-Perkele-VII> Date: Sun, 15 Mar 2015 11:27:41 -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] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:27:44 -0000 On 15 March 2015 at 11:25, Ilari Liusvaara wrote: > One certainly does not want earlydata for > HTTP/2 to be played upon HTTP/1.1 (or vice versa). In this case, 0RTT is - in many senses - just resumption. I think that it would be OK to send ALPN with a single value here - the value from last time. From nobody Sun Mar 15 11:28: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 B940B1A1B63 for ; Sun, 15 Mar 2015 11:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW1CfYFxVzac for ; Sun, 15 Mar 2015 11:28:11 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 D712D1A1B73 for ; Sun, 15 Mar 2015 11:28:11 -0700 (PDT) Received: by oiag65 with SMTP id g65so21555787oia.2 for ; Sun, 15 Mar 2015 11:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xYJe0FrlSK4NqTWZoPAqPNMoBCoXBpJYBwad+MTMNnI=; b=WbHlhzp/OveOa7bajMr0rak/T5YLOeJdWgZEDthBu48NtjnWZMIz8Qi4zgLSIN+JSt A21RVzzzPXzz9TKrJIbFSMFJ3kPpZJdMh88PvG5wjnDSpsCuvebf2ZibIjyFjEhdUiNH Di/bLeBYBh9M0uABFhq9M5kFQIVLUzO/quJsehnArhYYsiytIknX0gBqrAXaOn4poURe GlDz5xussWkxp0CeVoWUVi3GEVzF1yzVwR7cRGk1aHMVsOV6/Lm9DCPCkHTd3YaYc7nv E7M5DjzItKsjAJokNz7lqJT77SMx0CU8rIKr2aWUw0B4miYU3kP0EC4SJgrcCjOfr1lA i/0g== MIME-Version: 1.0 X-Received: by 10.60.84.40 with SMTP id v8mr9312714oey.80.1426444091290; Sun, 15 Mar 2015 11:28:11 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Sun, 15 Mar 2015 11:28:11 -0700 (PDT) In-Reply-To: <20150315182529.GB16994@LK-Perkele-VII> References: <201503140212.53255.davemgarrett@gmail.com> <20150315182529.GB16994@LK-Perkele-VII> Date: Sun, 15 Mar 2015 11:28:11 -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] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 18:28:12 -0000 On 15 March 2015 at 11:25, Ilari Liusvaara wrote: > One certainly does not want earlydata for > HTTP/2 to be played upon HTTP/1.1 (or vice versa). In this case, 0RTT is - in many senses - just resumption. I think that it would be OK to send ALPN with a single value here - the value from last time. From nobody Sun Mar 15 13:59: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 C1E461A1B88 for ; Sun, 15 Mar 2015 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bxlAQ1tpgvp for ; Sun, 15 Mar 2015 13:59:05 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d: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 9490F1A1B8A for ; Sun, 15 Mar 2015 13:59:05 -0700 (PDT) Received: by qgez64 with SMTP id z64so25800044qge.2 for ; Sun, 15 Mar 2015 13:59:04 -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=SnjJ9sg3HBdFreLweOAG0EVB2xQaCSBWFrjl9omIcyA=; b=kGsLdbO0rkw0mq0MiRl5GlngzcvKq59NasZqXNFjNrNDYH0tjRnq/a+yxNJoPkXZNg LSaEPeRH2E83PEPwuR6Ao8M9ZRFSZN8tYuLqg254GmBJGzE0140Pkces7EVqBKgWmUC9 1NtnTHj1A8AenO3KsfNgPlU9K5jSbkG/Sh5CMW/qrSFKuIqnG0/Ja/z9NpwNy919hw1v /eE8hZLkLJNNEv6MwWuju0jycINytbCtlXW4C8CWj6lG+2j0ZpW9Ay1nvRLGCdDOgvYK mayQTVNWm8kT0TnsEAIVxg5B4WM7+toEPFN2grcroYyYPEV1v4Wj9LMtWMUjht7mGHsT N8og== X-Received: by 10.229.197.134 with SMTP id ek6mr70676908qcb.21.1426453144779; Sun, 15 Mar 2015 13:59:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q41sm6099480qkq.4.2015.03.15.13.59.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 15 Mar 2015 13:59:04 -0700 (PDT) From: Dave Garrett To: Martin Thomson Date: Sun, 15 Mar 2015 16:59:01 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503140212.53255.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503151659.02311.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 20:59:06 -0000 On 13 March 2015 at 23:12, Dave Garrett wrote: > In particular, SNI & ALPN should ideally be available everywhere. On Sunday, March 15, 2015 02:08:23 pm Martin Thomson wrote: > I don't see any point in making ALPN mandatory. If you need it, you > need it; if you don't, that's all there is to say. On Sunday, March 15, 2015 02:21:20 pm Salz, Rich wrote: > Agree with mt: SNI yes, ALPN not mandatory. Fair enough. It might still be worth mentioning in the spec, but with no requirements placed on it. Dave From nobody Sun Mar 15 14:13: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 C9E5C1A035F for ; Sun, 15 Mar 2015 14:13: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 XUxV_pF5ZvxD for ; Sun, 15 Mar 2015 14:13: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 1B0CB1A0194 for ; Sun, 15 Mar 2015 14:13:56 -0700 (PDT) Received: by wifj2 with SMTP id j2so27851822wif.1 for ; Sun, 15 Mar 2015 14:13: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=fIrOpB2OgponnkNCrHKJxKKIHZSAgU4F3YWnLm3Lewk=; b=fgbfwsPmzmEZZ2G15cY1IarAEBGdfIcIT91a8IF6LBiTjs3fLND+pxlkPZLZxizh6t RcHKuPakOjgJKBcZ16JWDX9zhw5TvMfu1ff7OLtIHbWw0O2X3RyTo/W7cMVuMu4qzEg9 WsfEn5VbV1zBMHpVjxcHvLk0xlQv8Oi3wS2qO2LBO5EXeE3kQuKPD/lJTC1eDqEav7qK mDjcpig5AmwlryL0xIdBOfd4SuAzComwajVI/99OHmg8OQJY4wlQqLEEG2CJi4GYfTV+ ZSWHzySwWD4xYWm9jGwE5kfB0Pzs8n8/0Xw25kadOx5Fco8L9kQaDbRoVvMKu5rnYO4x wOWg== X-Gm-Message-State: ALoCoQm60NQKkm5VXO4IDofIT6rp6tneCUpWg8C32ZNCHopCUA5CIVPzH3AbrlnKis4deWnfymdY X-Received: by 10.194.62.198 with SMTP id a6mr118223872wjs.90.1426454034700; Sun, 15 Mar 2015 14:13:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 15 Mar 2015 14:13:14 -0700 (PDT) In-Reply-To: <201503151659.02311.davemgarrett@gmail.com> References: <201503140212.53255.davemgarrett@gmail.com> <201503151659.02311.davemgarrett@gmail.com> From: Eric Rescorla Date: Sun, 15 Mar 2015 14:13:14 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7ba97e4e06df5205115a36e7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:13:57 -0000 --047d7ba97e4e06df5205115a36e7 Content-Type: text/plain; charset=UTF-8 SNI might be plausible as a MUST implement but there are plenty of cases where it's not sensible to be MUST send, as in where there is no server hostname. E.g., WebRTC. -Ekr On Sun, Mar 15, 2015 at 1:59 PM, Dave Garrett wrote: > On 13 March 2015 at 23:12, Dave Garrett wrote: > > In particular, SNI & ALPN should ideally be available everywhere. > > On Sunday, March 15, 2015 02:08:23 pm Martin Thomson wrote: > > I don't see any point in making ALPN mandatory. If you need it, you > > need it; if you don't, that's all there is to say. > > On Sunday, March 15, 2015 02:21:20 pm Salz, Rich wrote: > > Agree with mt: SNI yes, ALPN not mandatory. > > Fair enough. > > It might still be worth mentioning in the spec, but with no requirements > placed on it. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7ba97e4e06df5205115a36e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SNI might be plausible as a MUST implement but there are p= lenty of cases
where it's not sensible to be MUST send, as in where= there is no server
hostname. E.g., WebRTC.

<= div>-Ekr



On Sun, Mar 15, 2015 at 1:59 PM, Dave Garr= ett <davemgarrett@gmail.com> wrote:
On 13 March 2015 at 23:12, Dave Garrett &l= t;davemgarrett@gmail.com> = wrote:
> In particular, SNI & ALPN should ideally b= e available everywhere.

On Sunday, March 15, 2015 02:08:23 pm Martin Thomso= n wrote:
> I don't see any point in making ALPN mandatory.=C2=A0 If you need = it, you
> need it; if you don't, that's all there is to say.

On Sunday, March 15, 2015 02:21:20 pm Salz, Rich wr= ote:
> Agree with mt: SNI yes, ALPN not mandatory.

Fair enough.

It might still be worth mentioning in the spec, but with no requirements pl= aced on it.


Dave

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

--047d7ba97e4e06df5205115a36e7-- From nobody Sun Mar 15 14:18: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 764BB1A1B8C for ; Sun, 15 Mar 2015 14:18: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 dRem7mCIhN1s for ; Sun, 15 Mar 2015 14:18:53 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::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 41B391A01AE for ; Sun, 15 Mar 2015 14:18:53 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so29062920qcb.2 for ; Sun, 15 Mar 2015 14:18: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:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=wsteRBOhJyrjON7qhYKU9WIJidnZgQNnY8GearsI340=; b=BiJP+ig9ksmXiWTXh2U8+dX3nzZwEhX+B+pj0VOuoXejfwkMLUx93SIQgVlMqaj1Ze t7wsi320uUvJQ7RB6sEgY53JrnR2MWfhxfRY9sBDjZSF7ldHoxLGvGTpnH05jPLpHIhw 4jU7yJcCRA2fzDF3+Fnflnm+ONyAqbND6MeEoT2g24dFkcQv4DaA87NsRWgBzTpm2O5j r2XrSy7k8Yu0m60yvGZHP5puZnnBJoYeTykN22bBzg/1xwwhQLwuecJ75gjB5AKjSKc2 +B6JDjoqU8rMwkEr9qUULHZXz1Lq98c0DG8S1xNWZwPK4+P7U4iO0DkYpWkSL5gQwkLH sHJg== X-Received: by 10.55.23.83 with SMTP id i80mr110303993qkh.104.1426454332561; Sun, 15 Mar 2015 14:18:52 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 10sm6112561qht.13.2015.03.15.14.18.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 15 Mar 2015 14:18:52 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Sun, 15 Mar 2015 17:18:50 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503140212.53255.davemgarrett@gmail.com> <201503151659.02311.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503151718.50477.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:18:54 -0000 On Sunday, March 15, 2015 05:13:14 pm Eric Rescorla wrote: > SNI might be plausible as a MUST implement but there are plenty of cases > where it's not sensible to be MUST send, as in where there is no server > hostname. E.g., WebRTC. Yes, I acknowledged that when I started the thread, but with email threading being what it is, it got cut out of quotes. ;) On Saturday, March 14, 2015 02:12:52 am Dave Garrett wrote: > Idea: Add a small section after MTI cipher suites for MTI extensions. [...] > (not all deployments would need them, but they should always be available) Dave From nobody Sun Mar 15 14:21: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 6E97F1A1B8C for ; Sun, 15 Mar 2015 14:21:04 -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 766m7LorRaGf for ; Sun, 15 Mar 2015 14:21:03 -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 B3AB61A01AE for ; Sun, 15 Mar 2015 14:21:02 -0700 (PDT) Received: by wibg7 with SMTP id g7so23957647wib.1 for ; Sun, 15 Mar 2015 14:21: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=0jmFBh/tPCw3LOYB5wmZf96YhEqY4S+uc/KSm02qi8M=; b=ZzGa/kkS0I0fro2nzsDoEh1ezucSyImGm80paZwgX6FV2PwU0PZ4cEy+AL/QEbVWxg aMDie2krMpFwPlTjeSQH+qUXN2qwFjgZLr+1EELw3jTCblG7M3cUaHULsLJ/zNIqRiAN /0fcFWcUwHdRPnI9ncKWsR6/YqxBRSQrNVh3yLoFU+OFUN/1SGsG2/Vw0l+PDVsMsxdy oxtzYN3ZfVExjPhAyjH+1Vi/AyrQhmAO+77TwcqyPiDMkvvMEtyYgjcNRpWJK9Uwe33V +2CRKkLKf6GKqT1uoa/OrxiPC3MXLci+TrD2K1QXwGTIqKzRPXQoHa4Q1eIqeyAuhxjH fsvg== X-Gm-Message-State: ALoCoQlQzQ/iBdrQgSR3gHH8ZfHVTjq8bk2SjQHXvQPcFC37qoq6W4mmmVrJXzpMj/21t6pRwBac X-Received: by 10.194.191.228 with SMTP id hb4mr118993951wjc.116.1426454461335; Sun, 15 Mar 2015 14:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 15 Mar 2015 14:20:21 -0700 (PDT) In-Reply-To: <201503151718.50477.davemgarrett@gmail.com> References: <201503140212.53255.davemgarrett@gmail.com> <201503151659.02311.davemgarrett@gmail.com> <201503151718.50477.davemgarrett@gmail.com> From: Eric Rescorla Date: Sun, 15 Mar 2015 14:20:21 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b8750be74e39a05115a4f37 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:21:04 -0000 --047d7b8750be74e39a05115a4f37 Content-Type: text/plain; charset=UTF-8 Sounds like we're in violent agreement, then. On Sun, Mar 15, 2015 at 2:18 PM, Dave Garrett wrote: > On Sunday, March 15, 2015 05:13:14 pm Eric Rescorla wrote: > > SNI might be plausible as a MUST implement but there are plenty of cases > > where it's not sensible to be MUST send, as in where there is no server > > hostname. E.g., WebRTC. > > Yes, I acknowledged that when I started the thread, but with email > threading being what it is, it got cut out of quotes. ;) > > On Saturday, March 14, 2015 02:12:52 am Dave Garrett wrote: > > Idea: Add a small section after MTI cipher suites for MTI extensions. > [...] > > (not all deployments would need them, but they should always be > available) > > > Dave > --047d7b8750be74e39a05115a4f37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds like we're in violent agreement, then.

On Sun, Mar 15, 2015= at 2:18 PM, Dave Garrett <davemgarrett@gmail.com> wrot= e:
On Sunday, March 15, = 2015 05:13:14 pm Eric Rescorla wrote:
> SNI might be plausible as a MUST implement but there are plenty of cas= es
> where it's not sensible to be MUST send, as in where there is no s= erver
> hostname. E.g., WebRTC.

Yes, I acknowledged that when I started the thread, but with email t= hreading being what it is, it got cut out of quotes. ;)

On Saturday, March 14, 2015 02:12:52 am Dave Garrett wrote:
> Idea: Add a small section after MTI cipher suites for MTI extensions.<= br> [...]
> (not all deployments would nee= d them, but they should always be available)


Dave

--047d7b8750be74e39a05115a4f37-- From nobody Sun Mar 15 14:28: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 675531A1B96 for ; Sun, 15 Mar 2015 14:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omng9OwLPfau for ; Sun, 15 Mar 2015 14:28:49 -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 2D1311A1B8C for ; Sun, 15 Mar 2015 14:28:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F0594282FC0; Sun, 15 Mar 2015 21:28:43 +0000 (UTC) Date: Sun, 15 Mar 2015 21:28:43 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150315212843.GU27479@mournblade.imrryr.org> References: <201503140212.53255.davemgarrett@gmail.com> <201503151659.02311.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] MTI extensions? 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: Sun, 15 Mar 2015 21:28:51 -0000 On Sun, Mar 15, 2015 at 02:13:14PM -0700, Eric Rescorla wrote: > SNI might be plausible as a MUST implement but there are plenty of cases > where it's not sensible to be MUST send, as in where there is no server > hostname. E.g., WebRTC. Furthermore, even when SNI is sent, a server should generally NOT abort the handshake when it does not find a match for the requested name. Rather, it is better for the server to choose *some* other (often default) certificate, and leave it up to the client to decide whether that one is also acceptable. This is a signficant consideration for SMTP with DANE, because clients use the TLSA base domain (typically MX host name) in the SNI message, but will also accept other names (typically the recipient domain for which the server is an MX host). The server may have just one "UCC" certificate for the recipient domain, and MUST NOT abort the connection just because the client seems to want something else. -- Viktor. From nobody Sun Mar 15 14:52: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 C82E91A1B92 for ; Sun, 15 Mar 2015 14:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUoG5OgyFGXn for ; Sun, 15 Mar 2015 14:52:13 -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 72F641A1B8A for ; Sun, 15 Mar 2015 14:52:13 -0700 (PDT) Received: by igbue6 with SMTP id ue6so26494395igb.1 for ; Sun, 15 Mar 2015 14:52:13 -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:content-type; bh=UwePxwU+wf4Ug1zZW+pa0e0R1Fk0dmwbnFjgWdjtJ8E=; b=XHIzv+ORa+mj1VO6H/PJ5Ju7E4cZ2scYzEAXEII2K9a2A/+iMIrF6uEDyNItYNt1jm 1CcQbod6FEPDRNTuXrSJzNSr9vu/3hKKXA6HEe/evdaANXhQhQmk9n+zoEeIbniwJwP2 ovA8s0jSwXYtF/Tx3fkFVW8luIHLYWKrmPEl7TCF7fZol/X3p//McVwd4XnshkIwmL4F 5bI7qC95EsqZ3C0AxaqJYmTbo9SUGDAwKUh0DU+CW5JUQa81Py3lFxfRon7IP224cMBn Qt6PRRhxKImOJT022tlkMuVL6cQPzfiqga8NfdcXFkSf2cBJdoPI+jdxbOBBtQorpumj RrbA== MIME-Version: 1.0 X-Received: by 10.50.30.130 with SMTP id s2mr103984416igh.11.1426456332978; Sun, 15 Mar 2015 14:52:12 -0700 (PDT) Received: by 10.36.81.15 with HTTP; Sun, 15 Mar 2015 14:52:12 -0700 (PDT) In-Reply-To: <20150315212843.GU27479@mournblade.imrryr.org> References: <201503140212.53255.davemgarrett@gmail.com> <201503151659.02311.davemgarrett@gmail.com> <20150315212843.GU27479@mournblade.imrryr.org> Date: Sun, 15 Mar 2015 17:52:12 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] MTI extensions? 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: Sun, 15 Mar 2015 21:52:14 -0000 > This is a significant consideration for SMTP with DANE, because > clients use the TLSA base domain (typically MX host name) in the > SNI message, but will also accept other names (typically the > recipient domain for which the server is an MX host). The server > may have just one "UCC" certificate for the recipient domain, and > MUST NOT abort the connection just because the client seems to want I think cases like this should be considered further. There's too many open questions surrounding use cases like this. Jeff On Sun, Mar 15, 2015 at 5:28 PM, Viktor Dukhovni wrote: > On Sun, Mar 15, 2015 at 02:13:14PM -0700, Eric Rescorla wrote: > >> SNI might be plausible as a MUST implement but there are plenty of cases >> where it's not sensible to be MUST send, as in where there is no server >> hostname. E.g., WebRTC. > > Furthermore, even when SNI is sent, a server should generally NOT > abort the handshake when it does not find a match for the requested > name. > > Rather, it is better for the server to choose *some* other (often > default) certificate, and leave it up to the client to decide > whether that one is also acceptable. > > This is a signficant consideration for SMTP with DANE, because > clients use the TLSA base domain (typically MX host name) in the > SNI message, but will also accept other names (typically the > recipient domain for which the server is an MX host). The server > may have just one "UCC" certificate for the recipient domain, and > MUST NOT abort the connection just because the client seems to want > something else. From nobody Mon Mar 16 06:41: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 1FE051A875A for ; Mon, 16 Mar 2015 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjUX1d5YX9jM for ; Mon, 16 Mar 2015 06:41:00 -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 78E991A8759 for ; Mon, 16 Mar 2015 06:41:00 -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 EF0AFC1F94; Mon, 16 Mar 2015 13:40:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-213.brq.redhat.com [10.34.0.213]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2GDewJA031127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 09:40:59 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 16 Mar 2015 14:40:51 +0100 Message-ID: <2126970.G8GsdsskoZ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.4 (Linux/3.18.7-100.fc20.x86_64; KDE/4.14.4; x86_64; ; ) In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3652554.BkmTUHDRYH"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:41:02 -0000 --nextPart3652554.BkmTUHDRYH Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Sunday 15 March 2015 03:40:38 Mehner, Carl wrote: > >I believe we are going to remove this entire field and its associate= d > >code points because it is redundant with the signature algorithms. >=20 > sounds good. >=20 > Speaking of Signature Algorithms, what do you think of this? >=20 >=20 > Since root certificates are trusted by their identity rather than the= > signature I think that amendments to the text in the Server Certifica= tes > and Certificate Request sections are necessary. >=20 > As we move into a world that lacks trusted SHA-1 signatures, a change= in the > text would be necessary in order for clients that drop SHA-1 from the= > supported hash algorithms to continue to connect to servers that send= a > certificate_list that includes roots signed with SHA-1. server that provides a self signed certificate is misconfigured in the = first=20 place... a change that would reflect better the real world deployments would be = to=20 change the MUST to SHOULD - significant portion of servers ignore=20 signature_algorithms when selecting server certificate (i.e. send sha-1= signed=20 certs even when client didn't advertise SHA-1 in sig_algs) and its the client's duty anyway to decide if it trusts a chain or not,= the=20 server should just provide one that is most likely to be trusted, not s= econd- guess client's intentions =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 --nextPart3652554.BkmTUHDRYH 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 iQIcBAABAgAGBQJVBt1pAAoJEJKo0bgB0vX1bUsQAJ1b4jC6Au02c19xUq1rSHJ3 Ay8tspLHAxbt5sOljUCP7ZbR8M9UZTvmjyqo4qikJcZW5e3TH2UybE3xqNjfgLJa HUfmxyUCoDUS5K42aAd63osssFQRFVXY6R/X/NMDlEQIR70XzUs1YqGn39B615PO QwszDzPKVo+TcAJoyw93Y9h4GjVtcpGhf/OCzhp050i4odOJ9ErXAOhwGYZE09KX rt0diosmaHnmwY5FAUPTzkQgd4wEicrsUUwqo/PC5xT4aCeev4Gckb19KDLIKKCN FpedbobOScqmgB2gBB7pyHoHchwPtn2U9X2twd98KtAHwhc2e7vvLAg2ZFm7oGyl h9LX0scJ4+djJSnIbNtbKnEwSZieWxy2URfzjMGJoNP3QHcs1BI6MMplSyvk+8Zr /1Lalw6TxrW63KQ+5jT/JuAtDh3VbZ2JSCPZ9/cGATtuaGLJIhwuA7do/WTajuZR msABORjWoeZL1WZNZTVmBsHpDMa59OqNdifm+gpgG/fD95+8/1f04MD9X8JSokLT 6BUdqEUal+9NdsBkmf/9ONHPJCnpZ6X+JuWd4B+MSehXeD7e3pLWhehmHS1YmeFs xYUk1teCT/ZS0zRkMxmm+XXv6WYMMtq8IXXV3KItAy7qsEs5C/+GOxWnlsaGDh1h 2Nnn6c7dSL4WZU3l+VYV =mZdE -----END PGP SIGNATURE----- --nextPart3652554.BkmTUHDRYH-- From nobody Mon Mar 16 07:56: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 5D8111A882F for ; Mon, 16 Mar 2015 07:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHInv1H26um9 for ; Mon, 16 Mar 2015 07:55: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 701521A8828 for ; Mon, 16 Mar 2015 07:55:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 60417283012; Mon, 16 Mar 2015 14:55:52 +0000 (UTC) Date: Mon, 16 Mar 2015 14:55:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150316145552.GF27479@mournblade.imrryr.org> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <2126970.G8GsdsskoZ@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2126970.G8GsdsskoZ@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Signature Algorithms 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, 16 Mar 2015 14:55:57 -0000 On Mon, Mar 16, 2015 at 02:40:51PM +0100, Hubert Kario wrote: > Server that provides a self signed certificate is misconfigured in the first > place... That's not correct. TLS servers are generally not required to send trust-anchor CA certs, but they may certainly do so. In fact with DANE TLSA records with the DANE-TA(2) certificate usage, servers MUST send the trust-anchor certificate, which may be be self-signed. With DANE-EE(3) the server's end-entity (leaf) certificate is often self-signed. That signature is irrelevant, the signature that matters is the one on the DNSSEC TLSA RRset that authenticates the server certificate. Ditto for the trust anchor in the previous paragraph. -- Viktor. From nobody Mon Mar 16 13:19: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 356D81A8965; Fri, 13 Mar 2015 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 W5xQ1Jp5BPXN; Fri, 13 Mar 2015 10:11:39 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 135771A8A9A; Fri, 13 Mar 2015 10:11:33 -0700 (PDT) X-TM-IMSS-Message-ID: <8a06fd0800122d48@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov (msht-gh1-uea01.corp.nsa.gov [10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 8a06fd0800122d48 ; Fri, 13 Mar 2015 13:11:26 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 13 Mar 2015 13:11:31 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.02.0347.000; Fri, 13 Mar 2015 13:11:30 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBdsL81XCyfXC5pQPeZlyI69acR3g== Date: Fri, 13 Mar 2015 17:11:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 16 Mar 2015 13:19:08 -0700 Cc: "'ipsec@ietf.org'" , "'tls@ietf.org'" Subject: [TLS] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:11:43 -0000 --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm planning to hold a side meeting at IETF 92 to gauge int= erest in creating a standard for TLS VPNs. One motivating use case for my o= rganization is the need to protect data between an app on a mobile device = and the enterprise network that it connects to. For many of our customers,= a TLS-based solution is preferable to IPSec (perhaps because their vendors= support the former). For some sensitive military applications, there is a = requirement to provide two layers of encryption, so using TLS for the secon= d layer makes sense. Having each app invoke TLS is problematic because it i= ntroduces validation costs for each app before it is deployed (to ensure th= at it correctly implements TLS or makes the appropriate OS calls). We would= prefer the option of validating a TLS VPN product and having it available = for use by all apps on the device. To create the necessary validation requi= rements and test activities, we need to have a standard that we can point t= o. The development of an open standard would provide a consistent and fair= method of measuring security (using Protection Profiles) which scales to e= nable the validation and testing of TLS VPNs. Beyond this specific (but fairly pressing) use case, we bel= ieve that there are many organizations that would benefit from the availabi= lity of a standards-based, validated mechanism to protect communications be= tween their mobile devices and the enterprise network. Please discuss on the saag mail list. I will schedule a me= eting time at a local drinking establishment for either Monday or Wednesday= at 7:30 PM (local Dallas time). I'd appreciate feedback on the meeting tim= es (if you expect to attend) as well as any comment on the usefulness or fe= asibility of this effort. Thanks, Mike Boyle Standards Lead Information Assurance Directorate, NSA --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

        &nbs= p;       I’m planning to hold a side me= eting at IETF 92 to gauge interest in creating a standard for TLS VPNs. One= motivating use case for my organization is the need to  protect data = between an app on a mobile device and the enterprise network that it connects to.  For many of our customers, a TLS-based = solution is preferable to IPSec (perhaps because their vendors support the = former). For some sensitive military applications, there is a requirement t= o provide two layers of encryption, so using TLS for the second layer makes sense. Having each app invoke TLS is = problematic because it introduces validation costs for each app before it i= s deployed (to ensure that it correctly implements TLS or makes the appropr= iate OS calls). We would prefer the option of validating a TLS VPN product and having it available for use= by all apps on the device. To create the necessary validation requirements= and test activities, we need to have a standard that we can point to. &nbs= p;The development of an open standard would provide a consistent and fair method of measuring security (using Pr= otection Profiles) which scales to enable the validation and testing of TLS= VPNs.

 

        &nbs= p;       Beyond this specific (but fairly pre= ssing) use case, we believe that there are many organizations that would be= nefit from the availability of a standards-based, validated mechanism to pr= otect communications between their mobile devices and the enterprise network.

 

        &nbs= p;       Please discuss on the  saag mai= l list. I will schedule a meeting time at a local drinking establishment fo= r either Monday or Wednesday at 7:30 PM (local Dallas time). I’d appr= eciate feedback on the meeting times (if you expect to attend) as well as any comment on the usefulness or feasibility = of this effort.

 

Thanks,

Mike Boyle

Standards Lead

Information Assurance Directorate, NSA

--_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_-- From nobody Mon Mar 16 13:19: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 E67A71A0204; Sat, 14 Mar 2015 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFumaO-AK18y; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FE1A0194; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EF90120012; Sat, 14 Mar 2015 15:57:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D49263784; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 67D48636B6; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) From: Michael Richardson To: "Boyle\, Vincent M" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: X-Mailman-Approved-At: Mon, 16 Mar 2015 13:19:08 -0700 Cc: "'ipsec@ietf.org'" , "'saag@ietf.org'" , "'tls@ietf.org'" Subject: Re: [TLS] [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:47:53 -0000 --=-=-= Content-Type: text/plain I sure hope that you will give us a definition of a TLS VPN. It's really important that we know what is in scope and what is not. My take is that solutions that run TCP and/or HTTPS proxy over TLS, are not TLS VPNs, because they don't pass the "N"etwork part of VPN. They are useful mechanisms, and I'm all for standardizing them, but the word VPN should not be applied. OpenVPN is a TLS keyed VPN. It can and does run over a single TCP port, but that has congestion issues (tcp over tcp), so running the data part it over UDP is preferrale, but not always possible. (Meanwhile,there are IPsec vendors that run ESP over TCP in non-standard fashions...) I'd like to see some convergence at the dataplane side. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQSQZYCLcPvd0N1lAQJyIAf/c7X5sxRvcVQgaY2Lll11d8IxEFqh0/q3 U/dBnT6EJHW4h6g1rRlqVFmFyUPXSwqZZiPvSfG1s1bE2ew4Q7k9Fspj1sbUGBL5 U294sZpxCeCrSBUhnqH/nopap5hReAU54VgEjlEebmn8PGHuNn7y537+tIq09yQM os+uIf/O1OAgTwcX8WzYMg4BQuUb7hQqA21JzENeBSxsYgim4aPKAQXCu3krlguz ZTXSH+7Bkne/z/6PhHkdqg7BpDhPgxqZwT/rmrmmAAJu0a5Ou5iQdaa+HWgPZibe 6QIMS/9Ah0TBFjrT3MJ/EoR1cLoU/GTZvA3xM6rcDsY/7Bvkigieig== =7djO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 16 13:29: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 ED85C1A90C3 for ; Mon, 16 Mar 2015 13:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bzINN7Kmu3jZ for ; Mon, 16 Mar 2015 13:29:01 -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 23D431A90B2 for ; Mon, 16 Mar 2015 13:29:01 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id F10EB2A64B; Mon, 16 Mar 2015 21:28:58 +0100 (CET) X-purgate-ID: 152705::1426537739-0000765A-1851019F/0/0 X-purgate-size: 392 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id E6BC9430C3; Mon, 16 Mar 2015 21:28:58 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DDD661B22E; Mon, 16 Mar 2015 21:28:58 +0100 (CET) In-Reply-To: To: Martin Thomson Date: Mon, 16 Mar 2015 21:28:58 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150316202858.DDD661B22E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:29:03 -0000 Martin Thomson wrote: > Dave Garrett wrote: >> >> Idea: Add a small section after MTI cipher suites for MTI extensions. > > I think that's fine. Signature algorithms was made mandatory in 1.2, You may have missed it, but Signature algorithms support in TLSv1.2 is only mandatory for the *SERVER*. It is an implementor option for the client. -Martin From nobody Mon Mar 16 15:42: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 C3D601AC434 for ; Mon, 16 Mar 2015 15:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTomIcJJUZyc for ; Mon, 16 Mar 2015 15:42:56 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 A1E921AC3CE for ; Mon, 16 Mar 2015 15:42:56 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so47194374obd.3 for ; Mon, 16 Mar 2015 15:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aOto1EDh/M/Kqgbg/s/zsEY5BU02LR7NOu09O2SHVxM=; b=IuxKnCbnFPh7BhExltHBnj2q8HSZkqGSWFPqkyHLvgvrcXpBeEtpjFwNeIw5aXE50X LlBN+OxWEKzD9y9+sQYu0/7AHtknOns5ioHtARGfrjISaAYWMRl+ZPcYpHub/QCd3DrO y9uOUU5Zz6Pyt8JAacQ/rrbAs1CTPxETH5U9DY5+s9QG25dCyQVvw2ktcg1GhJ64FSor ServnmHjTzqvfmh0sli2+dgkOlHZyNJ/U1AT0qsC93Ubj/ncYFtlNiiKRgUgks7TaDdA l6K6Ly79y/yxmLDf8+fR6LgvRRvGoWXE21EIAxrebC5OpCUDWymaiU3VehNyPRQ5PWGt 4a6A== MIME-Version: 1.0 X-Received: by 10.60.158.202 with SMTP id ww10mr23236980oeb.18.1426545776173; Mon, 16 Mar 2015 15:42:56 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Mon, 16 Mar 2015 15:42:56 -0700 (PDT) In-Reply-To: <20150316202858.DDD661B22E@ld9781.wdf.sap.corp> References: <20150316202858.DDD661B22E@ld9781.wdf.sap.corp> Date: Mon, 16 Mar 2015 15:42:56 -0700 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] MTI extensions? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 22:42:57 -0000 On 16 March 2015 at 13:28, Martin Rex wrote: > You may have missed it, but Signature algorithms support in TLSv1.2 is only > mandatory for the *SERVER*. It is an implementor option for the client. Quite right: I consider a default value to be semantically equivalent. From nobody Mon Mar 16 16:20: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 8D7201ACD29 for ; Mon, 16 Mar 2015 16:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OH_zVdcaWGZ for ; Mon, 16 Mar 2015 16:20:49 -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 2B2BE1ACD21 for ; Mon, 16 Mar 2015 16:20:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C8F75BE5D for ; Mon, 16 Mar 2015 23:20:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylUrsbBSz8Db for ; Mon, 16 Mar 2015 23:20:46 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF1BBBE53 for ; Mon, 16 Mar 2015 23:20:46 +0000 (GMT) Message-ID: <5507654E.3040402@cs.tcd.ie> Date: Mon, 16 Mar 2015 23:20:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] AD review of draft-ietf-tls-sslv3-diediedie-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:20:52 -0000 Hiya, I got the publication request for this a couple of weeks ago. Sorry for being slow. (#include ) Good to (start to) see the back of this, thanks. I've started IETF LC as I only had nits to note. The announcement should pop out soonish. Those nits are: - ID nits sez you should say in the abstract that you're updating 5246 and that prohibiting-rc4 is now RFC 7465. It also wants you to add the usual 2119 boilerplate. I noted those in the LC text so presumably we can fix 'em later if needed. - abstract: (philosophical nit:-) is "no longer secure" correct - I guess it was never secure, it's just we've now discovered exactly how and why. The same point arises in the intero, in that ssl2 is "no longer considered secure" - I think you mean "sufficiently secure" in both cases. Those can be fixed during/after IETF LC if need be. Cheers, S. From nobody Mon Mar 16 16:49: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 EA8601ACD50; Mon, 16 Mar 2015 16:49:10 -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 Rze5_s1ouUSX; Mon, 16 Mar 2015 16:49:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7D41ACD55; Mon, 16 Mar 2015 16:48:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150316234859.1208.62933.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 16:48:59 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] Last Call: (Deprecating Secure Sockets Layer Version 3.0) to Best Current Practice 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, 16 Mar 2015 23:49:11 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Deprecating Secure Sockets Layer Version 3.0' as Best Current Practice 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-03-30. 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 Secure Sockets Layer version 3.0 (SSLv3) is no longer secure. This document requires that SSLv3 not be used. The replacement versions, in particular Transport Layer Security (TLS) 1.2, are considerably more secure and capable protocols. This document updates the backward compatibility sections of the TLS RFCs to prohibit fallback to SSLv3. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-sslv3-diediedie/ballot/ No IPR declarations have been submitted directly on this I-D. - ID nits says we should say in the abstract that we're updating 5246 and that prohibiting-rc4 is now RFC 7465. It also wants us to add the usual 2119 boilerplate. Those will be taken care of after IETF LC. From nobody Mon Mar 16 16:54: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 5AD631ACD27 for ; Mon, 16 Mar 2015 16:54: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 hWr_kVuUXIke for ; Mon, 16 Mar 2015 16:54:16 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 1D3B11A1BE0 for ; Mon, 16 Mar 2015 16:54:16 -0700 (PDT) Received: by oigv203 with SMTP id v203so17618817oig.3 for ; Mon, 16 Mar 2015 16:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pJtbndyhFqwh15hEq9yE1EtTnkEKOwDi9ulqFNpxuhQ=; b=KzR4QZ+nV7tRe0eWr/nqttytBFW/nFyD5EsiRCpS96L87td8LLQ9cC11bM4aiJo4ZW mq8yA1GBuR8FYIu6WtvMLzSg0aoxECyW1ScvnOExAZVBxIPXRPFmF04P4bcrqznxC1Lp wl3cKTWY0+2wCuVh8wzufYBPn9EhFDnGyXqCDg289yT1VozJPJLFcDLBgspRD5BAJnzz 8+QC8Pla/hDfTFKzZTdKWfj0QFJ6+DYrPi1CBUSvIeYVzqZf0DaX4QvpcEsXadeLo5BL n2Ry6OqXos0qLe8DCleLTTQ+wrUzF7dra+s8agZsUu+6+b0n7x8dvRfCdMMRBDWiHqXo +y4g== MIME-Version: 1.0 X-Received: by 10.182.97.41 with SMTP id dx9mr50721093obb.4.1426550055663; Mon, 16 Mar 2015 16:54:15 -0700 (PDT) Received: by 10.202.86.20 with HTTP; Mon, 16 Mar 2015 16:54:15 -0700 (PDT) In-Reply-To: <5507654E.3040402@cs.tcd.ie> References: <5507654E.3040402@cs.tcd.ie> Date: Mon, 16 Mar 2015 16:54:15 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-sslv3-diediedie-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:54:17 -0000 On 16 March 2015 at 16:20, Stephen Farrell wrote: > - ID nits sez you should say in the abstract that you're > updating 5246 and that prohibiting-rc4 is now RFC 7465. > It also wants you to add the usual 2119 boilerplate. > I noted those in the LC text so presumably we can fix 'em > later if needed. Why can't "MUST" be assumed in the same way that "TCP" is, I ask? A question that is perfectly suited to the upcoming plenary, methinks. Bike sheds are always best painted in large groups. (I've fixed the editor's copy, BTW.) > - abstract: (philosophical nit:-) is "no longer secure" > correct - I guess it was never secure, it's just we've now > discovered exactly how and why. The same point arises in > the intero, in that ssl2 is "no longer considered secure" - > I think you mean "sufficiently secure" in both cases. Fine with me. Updated. From nobody Mon Mar 16 16:55: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 A8F661ACD55 for ; Mon, 16 Mar 2015 16:55:42 -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 FhfVsvhzH2Ig for ; Mon, 16 Mar 2015 16:55:38 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.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 D66941ACD4A for ; Mon, 16 Mar 2015 16:55:37 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so52519203wgb.0 for ; Mon, 16 Mar 2015 16:55:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=OTHvYIo02Vdb0n1ervS8yz2OANQFuMV+l4cSKvJP1H8=; b=R0AziovHqAHgDTjwAVfJcI54j/vlfeqkCMlQdTNXv31WKSsCxANxJ84ndoyJpUIGA2 e5wR8A1UMvPvh0uq8dvMjBrqj0dvylnIN90oWqNkmPYf9HmwW10Bc31nOSG42plfzXs4 RBc2C1k3qsPfYczjOKJ5m+gioGXtI6GY4hw5FvT9TvTdpOFTs0r5rDk60IHhOtAqR9ti fTAYPfyu9AYftkozMG803HGbUmk72zglVTSA3q6GAH/AznCeIo4v4+2tUniFE9CuKb4U S7LfFyg7XiRM1RtdUWKhvqFRGGjuoszQO0hmaoP8vO+p3YWsG3dxggEQKPjrQORRBfJq hOfw== X-Gm-Message-State: ALoCoQmygnSZcnJOfUme4J6nKnLhYy8wYqrU+MtEktgPPWtsTVZGEO5GY3Pu/3ia4vqf3UTINjVs X-Received: by 10.194.185.68 with SMTP id fa4mr124707608wjc.111.1426550136612; Mon, 16 Mar 2015 16:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 16 Mar 2015 16:54:56 -0700 (PDT) From: Eric Rescorla Date: Mon, 16 Mar 2015 16:54:56 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bacb11e25bf3305117096ff Archived-At: Subject: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:55:42 -0000 --047d7bacb11e25bf3305117096ff Content-Type: text/plain; charset=UTF-8 PR: https://github.com/tlswg/tls13-spec/pull/155 Target merge date: 3/21 Currently: - AES-GCM uses a partially explicit nonce - The ChaCha20 draft uses the sequence number as the nonce. As Stephen Kent has observed, the idea behind the explicit IV is to allow the cryptographic module implementing the AEAD algorithm to ensure non-reuse of the nonce. However, for ChaCha I believe we came to the conclusion that it was acceptable to use the sequence number as the nonce, as the module can check for sequential usage. This saves 8 octets on the wire. In the interim in Seattle, we came to the conclusion that we should make all AEAD algorithms behave this way, which also simplifies the spec some. I've formatted this into a PR to verify the consensus on the list. Please comment here if you object and on the PR if you have editorial comments. https://github.com/tlswg/tls13-spec/pull/155 -Ekr --047d7bacb11e25bf3305117096ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Targ= et merge date: 3/21

Currently:

- AES= -GCM uses a partially explicit nonce
- The ChaCha20 draft uses th= e sequence number as the nonce.

As Stephen Kent ha= s observed, the idea behind the explicit IV is to allow the
crypt= ographic module implementing the AEAD algorithm to ensure non-reuse
of the nonce. However, for ChaCha I believe we came to the conclusion th= at it
was acceptable to use the sequence number as the nonce, as = the module can
check for sequential usage. This saves 8 octets on= the wire.

In the interim in Seattle, we came to t= he conclusion that we should make
all AEAD algorithms behave this= way, which also simplifies the spec some.
I've formatted thi= s into a PR to verify the consensus on the list. Please comment
h= ere if you object and on the PR if you have editorial comments.
<= br>

-= Ekr

--047d7bacb11e25bf3305117096ff-- From nobody Tue Mar 17 10:41: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 D73481A87E7 for ; Tue, 17 Mar 2015 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGijaFW1Gnk7 for ; Tue, 17 Mar 2015 10:41:42 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::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 9236D1A00F4 for ; Tue, 17 Mar 2015 10:41:42 -0700 (PDT) Received: by qcyi15 with SMTP id i15so15754513qcy.0 for ; Tue, 17 Mar 2015 10:41:41 -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=Ex/V+mPxU1dalytorA9z9Usj4CZjl9u+D62dYfwI9e0=; b=q6RR5WjP5RRMYpVT1mifOgUydmyG9/dqbAshyf/6AthWST/b8Hj+SaRWvSIrd9eRHa G+vDVwbF2DZMnHJTeY1eWU0kNgi1mZy92Q3gO4HE5vPaJUKKKk3AhfOVHS5xVaS6n5VZ FRDwer33qDq2vmT0vKxiGFqBQ9V3DfT0BnG7O+eHY92E9VOtryQ/jwM06HHaKHuaSR/J Ju9inHK6ZU8YDtWT9fPJ2SsthbSEjMKHvPgPhByztv8xofup5CwXIY3z1wLO1vdwVfkU IqhBZy42KWb6qb5tYcYtrvYpfRIIQ7dXNTNBIPQizTNnMa7VtlazB8km9UYrtVr1gxJz uVoA== X-Received: by 10.140.238.78 with SMTP id j75mr45026326qhc.96.1426614101934; Tue, 17 Mar 2015 10:41:41 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 91sm10042309qkw.13.2015.03.17.10.41.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:41:41 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 17 Mar 2015 13:41:39 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503171341.40315.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:41:44 -0000 On Saturday, March 14, 2015 11:40:38 pm Mehner, Carl wrote: > As we move into a world that lacks trusted SHA-1 signatures, a change in the text would be necessary in order for clients that drop SHA-1 from the supported hash algorithms to continue to connect to servers that send a certificate_list that includes roots signed with SHA-1. What's the viability of having TLS 1.3 drop support for SHA-1 for end-entity certificates? (not root or intermediary, yet) This would of course be in addition to dropping all support for MD5, which I think is pretty much a given at this point. If it were to be new policy right this second, that wouldn't be great, but by the time TLS 1.3 is ready for widespread adoption I think that's a reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at about 2:3 and improving steadily. SHA-2 will probably be used in the majority within a couple months or so. Dave From nobody Tue Mar 17 10:51: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 18D471A8848 for ; Tue, 17 Mar 2015 10:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 j5L_JOY_RNmj for ; Tue, 17 Mar 2015 10:51:10 -0700 (PDT) Received: from prodomx03.usaa.com (prodomx03.usaa.com [167.24.101.121]) (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 95F2E1A883F for ; Tue, 17 Mar 2015 10:51:10 -0700 (PDT) Received: from pps.filterd (prodomx03.usaa.com [127.0.0.1]) by prodomx03.usaa.com (8.14.7/8.14.7) with SMTP id t2HHp0aq003850; Tue, 17 Mar 2015 12:51:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=201408; bh=kiMZhdgtwuWaVs4zLnAFx2J6lV/BrDI5yVYuqfzOaqg=; b=Zl+Ed12veRCL7oBLMYB+V3zj1UOfKYYZ4348s+0G9x+dJPu7UcDKYYWpvlLOAXXN7Dzt VOJUKbFeHnGG1Tx5d/7aykY+vjAIS5g4tRiHSK+X+83gEg9uMSVcxaXTYonxsiuVRllm UryHx/e+9Nrj6hx3DRPtVcbqG27Y0uPESp4SV6UmvchJPxfYw0CYTeAZ4RW/bHWWmkmu 61Pmnn2eR/pqsu/Svt1uJ5/AMCXkUGwasClGjyZ3Fx5eyXNeY50H78OSrO6P6+mYon0p PVoVvvtcvmBZzf80FzT3cyJ+HbuHMDUw3x7M8b89a1HX1AxovHgKuNqjdxwi5Lw6I9MI zA== Received: from prodexch03w.eagle.usaa.com (prodexch03w.eagle.usaa.com [10.70.41.152]) by prodomx03.usaa.com with ESMTP id 1t629b9hqy-1; Tue, 17 Mar 2015 12:51:07 -0500 Received: from PRODEXCH01W.eagle.usaa.com (10.70.41.151) by PRODEXCH03W.eagle.usaa.com (10.70.41.152) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Mar 2015 12:51:07 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.159]) by PRODEXCH01W.eagle.usaa.com ([10.70.41.151]) with mapi id 14.03.0158.001; Tue, 17 Mar 2015 12:51:06 -0500 From: "Mehner, Carl" To: Dave Garrett , "tls@ietf.org" Thread-Topic: EXTERNAL: Re: [TLS] Signature Algorithms Thread-Index: AQHQXmX8asKK2lJ1wUKslyiYez0tCp0hSkSA//+tOkA= Date: Tue, 17 Mar 2015 17:51:06 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D411463A97@PRODEXMB01W.eagle.usaa.com> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> In-Reply-To: <201503171341.40315.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.15.114] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00AB_01D060B1.08A2F6C0" MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-17_04:2015-03-17,2015-03-17,1970-01-01 signatures=0 Archived-At: Subject: Re: [TLS] EXTERNAL: Re: Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 17:51:14 -0000 ------=_NextPart_000_00AB_01D060B1.08A2F6C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Dave Garrett [mailto:davemgarrett@gmail.com] > What's the viability of having TLS 1.3 drop support for SHA-1 for end- > entity certificates? (not root or intermediary, yet) This would of course > be in addition to dropping all support for MD5, which I think is pretty > much a given at this point. > My thoughts were that this would happen on or after the sunset date (2017-01-01). Dropping SHA-1 for EE-certs is not something I am looking to have mandated in this document, just allowed for. (By not requiring all the certificates in the certificate_list to be signed with a supported algorithm regardless of if the signature was calculated in validation.) ------=_NextPart_000_00AB_01D060B1.08A2F6C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD78w ggQZMIIDAQIQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBv bmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp emVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvCg3C1SzbZ7kt5ZQn3aW+4LBNj7NhVjzWfMP0zT6Gy6KI4uHYpGnFteK/waZHUF5GOYvVlrq1 bxS/EM4nE54FR5sxehPYH9nTAjeLrSxH8I6BBqcNMAzr9zwPIB3cckbupQLIW8PJVmlMxRjBkXsL 1RMAm7zvw0g+RmAghSrVkLbNi6DMMt23/UBVslAcVq7MjXdNxyBNpzF272iSipAeCIFWsq1po1LQ yxzEIz0fmf5M6BZjjsYIjvYx9tL65XbdtRySo0nNzQHNaM2pabqj6x0NnKQgpsGgxdFGTBdt0qxm P5aM4ITUNv8iWcX5EWCoXwR98hr2JUJhD8RKuD6JAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBADQm FTzAjU1DSR296SGS12act97FuNDkXV92IsAm+YQ6OvmMtfvsYPHozgSwyN2nA48w85jfpOakMd/T HAtG3HIgP67uBTykMz8LOaxweHNLmSvfMMJUsKg7VaH+FijNQr10boDbJ0SnzkRd1BuQmA0eQpSx ACwE0HSjAgUiY2PNg7X7wW1ia2l1/V1wQbn1v3zfvsEycyIhi1iBexWRerrjZEiwf/s2JdqV0PEk FBfdGIBrRiM5VPWOYgkEHZSQppvmJeJCRaq4kK2+CI+pC0IYlM9yOeGxQ+Aoz7fnWmwTa0mz/+MY fImLM12sM9en+do6VclYEPmq71q2z0tL3yowggVAMIIEKKADAgECAhBmESBH7/zab8ij5uO8EiR9 MA0GCSqGSIb3DQEBBQUAMIHwMQswCQYDVQQGEwJVUzEvMC0GA1UEChMmVW5pdGVkIFNlcnZpY2Vz IEF1dG9tb2JpbGUgQXNzb2NpYXRpb24xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QTEbMBkGA1UEAxMSVVNBQSBEaWdpdGFsIElEIENBMB4XDTEzMTEwMTAwMDAwMFoXDTE1MTEwMTIz NTk1OVowgdcxLzAtBgNVBAoUJlVuaXRlZCBTZXJ2aWNlcyBBdXRvbW9iaWxlIEFzc29jaWF0aW9u MSEwHwYDVQQLFBhJbmZvcm1hdGlvbiBTZWN1cml0eSBQS0kxRjBEBgNVBAsTPXd3dy52ZXJpc2ln bi5jb20vcmVwb3NpdG9yeS9DUFMgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTkxFDASBgNV BAMTC0NhcmwgTWVobmVyMSMwIQYJKoZIhvcNAQkBFhRjYXJsLm1laG5lckB1c2FhLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMEcHc+OUIytQRjf2MPWvpqm80JlCJSD7pdUeszk 7J2NCjYiYonNYIWP9OTxdj8iDWSrOaiyeKXH5OZstI0AysJbN1ik19BhYJmGAJDygLwbMmZR7Ekt mF45cth1gpgWOts0DIwMCdhDxvWxhtNGULFdprQOFLp+3ml44GJjQQOA0LZANTzm6Q8mc6NT5+36 0kSvLcSsWfb3Ys4V7qw9M7NNPE//D//fVpZImAOowWPEhZ/k0v7smpXhMUeQurB2OFW4YUPCWBZl Rp/hwEwgIVmoFIorYW5XG61R0NJnv73Zw+//qoTFp7eyvQZOK0mKEr8W84OFJ4GQV43iKNoU84sC AwEAAaOB7DCB6TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwIwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwEQYJYIZIAYb4 QgEBBAQDAgeAMHYGA1UdHwRvMG0wa6BpoGeGZWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1VuaXRlZFNlcnZpY2VzQXV0b21vYmlsZUFzc29jaWF0aW9uSW5mb3JtYXRpb25TZWN1cml0eVBL SS9MYXRlc3RDUkwuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAE6oUVeaYzxmKrq7BU7AH9NOaJr0/0 JAuC/6O/XIauEywNd4h33YzNzhtEKb4JLNseNuS7F4PGrJF7/bodouOEQfJmkpnHC4Qr2vEKjISK +wvWMUHxMZyaDPEN105JwaadxtS4OttUnVLm/8YVCAQ/+wNta1D6Z/KU/7CBKfAtO6zZzD0vBSOE XAolOsJdSRS84ogCa5O6eA/xcjDoKxsYYNDELTrsGZggYR7xhPNw7NDUm4B8RjCp6a5EyGy/ZYuO WBpjgthQwFIsxhinCUQ48NXc+t18DYX20VDW19Rustgalans8Y7mSsNlvIxa3JyLAXFWOSVJDSyW qLYjj3VoMIIGWjCCBUKgAwIBAgIQEjtO36uJDhFABVol5JHT9jANBgkqhkiG9w0BAQUFADCByjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkxMTA0MDAwMDAwWhcNMTkxMTAzMjM1 OTU5WjCB8DELMAkGA1UEBhMCVVMxLzAtBgNVBAoTJlVuaXRlZCBTZXJ2aWNlcyBBdXRvbW9iaWxl IEFzc29jaWF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJU ZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UE CxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExGzAZBgNVBAMT ElVTQUEgRGlnaXRhbCBJRCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK5wCuVg wFkILbv8rxYROB6RFlTcNS6n3By3llHG2uhnDT9A51p73kpKV5zk6AgotAr5SJ4BDZlETPyquTsz SW8Pzr9NLYynrI3qDAqfeG0XH0P0RPbSd618tMgwQz3+m0npOuJe5juaLyWFQhlZenlEfDhCU8Zk sq3+E2bYBhGtclOGKvfROK2fjI0QrBLp5nPE0GP/WyCqVYPMWe2mHh7KQuz/Hy8QxdSfAXWt1lQg qT9xKSG/qhkSefaAtSsV9SLXrFE4qHlabGX70epyp+dUkSyv1/FQDZsvCGuh6o+HAb1EGTwYryJv J68eOeYjBZJ3X10+DcvBLQCnGOHRhcMCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAw cAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJp c2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw NAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgt MTUxMB0GA1UdDgQWBBSS5dwITxFWH7ttzpFrqM7Z8Emt2DCB8AYDVR0jBIHoMIHloYHQpIHNMIHK MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1h cnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxfmEUp57Cm2VBbejANBgkqhkiG 9w0BAQUFAAOCAQEAU1t64z3BAo409MvLnrNLgIbabxMHO9xF4m1OZBlRo3vA9JpydD+nuxSYpj+f fLghBglE7uF+wY62xzYM8mToWBKzsRr4lkzysCaF2iycw8jkOoiYLpA6Zv3j++UmBYky5JCf8xID qKOsyzL2mvEw45kywboQ8q5pOKYoCSWBzKGu/6iEBZRV2Rd8kzWhTHt+EnDEZ5u45IwnKo0bmSba oQzC298oH4fE4Cd2zQlKr5syungPW+DldIxoYtzjGkM+NyhrcbOA77DDm37/X+2i4oH5MvdM0jva KjGKzd36cRs0e0WazqRT4FR13brftJ8kK6Xh4PAdN6u+vBXsWlWX4jGCBZMwggWPAgEBMIIBBTCB 8DELMAkGA1UEBhMCVVMxLzAtBgNVBAoTJlVuaXRlZCBTZXJ2aWNlcyBBdXRvbW9iaWxlIEFzc29j aWF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExGzAZBgNVBAMTElVTQUEg RGlnaXRhbCBJRCBDQQIQZhEgR+/82m/Io+bjvBIkfTANBglghkgBZQMEAgEFAKCCA10wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMzE3MTc1MTA2WjAvBgkqhkiG 9w0BCQQxIgQgDFRn/KVg4dNTbpTH1tJYz+3kgRyq6afM88HTosnWwHAwgbcGCSqGSIb3DQEJDzGB qTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAO BggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwCwYJ YIZIAWUDBAIBMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowCgYIKoZIhvcNAgUw ggEYBgkrBgEEAYI3EAQxggEJMIIBBTCB8DELMAkGA1UEBhMCVVMxLzAtBgNVBAoTJlVuaXRlZCBT ZXJ2aWNlcyBBdXRvbW9iaWxlIEFzc29jaWF0aW9uMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExGzAZBgNVBAMTElVTQUEgRGlnaXRhbCBJRCBDQQIQZhEgR+/82m/Io+bjvBIkfTCC ARoGCyqGSIb3DQEJEAILMYIBCaCCAQUwgfAxCzAJBgNVBAYTAlVTMS8wLQYDVQQKEyZVbml0ZWQg U2VydmljZXMgQXV0b21vYmlsZSBBc3NvY2lhdGlvbjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJz Y3JpYmVyIENBMRswGQYDVQQDExJVU0FBIERpZ2l0YWwgSUQgQ0ECEGYRIEfv/NpvyKPm47wSJH0w DQYJKoZIhvcNAQEBBQAEggEATZAjZMIt7BL+WBPufvG2FwkreX0P1fXS4jIX2NQPhKTFN/8gpxAz PWUYMyyJL1HVcIfSXUT/QWAye+esY4/a1A2aX06XnTnwBluTPMC+Llyb+oC4hOIb5YTa2nbcNPSu PTuEgSpDgUP+P/XJ49EgXWZDv95pqel598irb68CTfunGwMYg9p1BeCOtxBWrULhd1+W3JgYbmuc QBQUnKjEgcbeXTDWJbjEKciccrLUGkJ7UBM2zyPaeEXUAuKcuAsBwTtgLfoyXHtoSdh3GBw1ugfW qTH+XleinS0RzDYOxeiwUNaRs41WA9Kc65kz4IPmTbib/bfIEKnKgdc3PSklRgAAAAAAAA== ------=_NextPart_000_00AB_01D060B1.08A2F6C0-- From nobody Tue Mar 17 11:00: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 E6C8D1A87E7 for ; Tue, 17 Mar 2015 11:00:42 -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 0Woap3hKRiYX for ; Tue, 17 Mar 2015 11:00:40 -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 CCCEC1A87E8 for ; Tue, 17 Mar 2015 11:00:39 -0700 (PDT) Received: by wibg7 with SMTP id g7so69885399wib.1 for ; Tue, 17 Mar 2015 11:00:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tmgnAMn5B7iz3OA44P6Vs1NuuE+gJw9xJRQGWD+B5SI=; b=gyKVV3d774RV7duXVKT032hTOYOJ49uThHmtDTK/GPuNQSyktbctrNR6RdruYqw7r+ FNnlpSpSiKbxJFPbUCvacLSytAUga8SRfeJI/bLj0/sWtpVmDa98D6sfZZgQmitmrIdD bMbhky18+Fpqp0zz0SXNVIj8Lt9dp/oYU+xXdJAJlmg+G+sEkxip8rBrpBkg6bMxlwyM tf0cm/keCCDq2CAgO7A8FEy1j3bqI/SMyxCAHrbBrNxk4q3fGGC28YJOvjC2I3XkF88g YEkioeY0E1327RjKbigPz2RrAOtszgfT2LeiHYn0kT2/803k3fhP8JRXgtC5/XSw8W61 X5fQ== X-Gm-Message-State: ALoCoQmb2PxBT2DuJPI+46IRIZQI5oF7xXCzm0keXsC4vMN5ZpnZWC6dX9UbYbe+o/4qpEVCmGu6 X-Received: by 10.180.101.225 with SMTP id fj1mr133161500wib.56.1426615238446; Tue, 17 Mar 2015 11:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Tue, 17 Mar 2015 10:59:58 -0700 (PDT) In-Reply-To: <201503171341.40315.davemgarrett@gmail.com> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 17 Mar 2015 10:59:58 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=f46d0442878884e4e305117fbea9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:00:43 -0000 --f46d0442878884e4e305117fbea9 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett wrote: > On Saturday, March 14, 2015 11:40:38 pm Mehner, Carl wrote: > > As we move into a world that lacks trusted SHA-1 signatures, a change in > the text would be necessary in order for clients that drop SHA-1 from the > supported hash algorithms to continue to connect to servers that send a > certificate_list that includes roots signed with SHA-1. > > What's the viability of having TLS 1.3 drop support for SHA-1 for > end-entity certificates? (not root or intermediary, yet) I would not be in favor of this. Many people have certificates with very long lifetimes and this would effectively mean that people could not drop in TLS 1.3 for 1.2 on their servers, which would be bad. -Ekr > This would of course be in addition to dropping all support for MD5, which > I think is pretty much a given at this point. > > If it were to be new policy right this second, that wouldn't be great, but > by the time TLS 1.3 is ready for widespread adoption I think that's a > reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at > about 2:3 and improving steadily. SHA-2 will probably be used in the > majority within a couple months or so. > > > Dave > --f46d0442878884e4e305117fbea9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
On Saturday, March 14, 2015 11:40:38 pm Mehner, Carl wrote:
> As we move into a world that lacks trusted SHA-1 signatures, a change = in the text would be necessary in order for clients that drop SHA-1 from th= e supported hash algorithms to continue to connect to servers that send a c= ertificate_list that includes roots signed with SHA-1.

What's the viability of having TLS 1.3 drop support for SHA-1 fo= r end-entity certificates? (not root or intermediary, yet)

I would not be in favor of this. Many people have certific= ates with very long lifetimes
and this would effectively mean tha= t people could not drop in TLS 1.3 for 1.2 on
their servers, whic= h would be bad.

-Ekr


=
=C2=A0
This would of course = be in addition to dropping all support for MD5, which I think is pretty muc= h a given at this point.

If it were to be new policy right this second, that wouldn't be great, = but by the time TLS 1.3 is ready for widespread adoption I think that's= a reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at = about 2:3 and improving steadily. SHA-2 will probably be used in the majori= ty within a couple months or so.


Dave

--f46d0442878884e4e305117fbea9-- From nobody Tue Mar 17 11:06: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 DC0751A87EC for ; Tue, 17 Mar 2015 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW3R4AxzzbuF for ; Tue, 17 Mar 2015 11:06:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.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 31CE51A87DB for ; Tue, 17 Mar 2015 11:06:52 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so16347100qcb.2 for ; Tue, 17 Mar 2015 11: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:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=78fzrsexSCmvDeFkVpND+HBqmbgdDamh4wtlVOSeXvQ=; b=Mtz+BagCEiMzsFmG5WUzCaWL78bHga6eEEJwCc6kF80M1qbvt/AoAQBU45BRvhhpNd LQ42N3EjRRVmzUMeRZwMTzorIwxzpgHgIKwyLyc0SGqpkYZAcx3IdFImh/YIX2NYEawY EE6h3np59rSCMetrTWHVrNHxs+4vLJoMQcCK++2dFUAkrJRRqeI1Y2dozu31lAExiKRL 0H1xFoMG4aNXZNkcRomjrR2ugzHO4PTn6JAYFrdqA1BND94p/hyKTgRUZsauB9RhrkWS DQwVTXZ8OwwCgFqThFAiQMbdPe21IMoCnln01aNGVrDfrlJrQZtZNdEOlX3WFDLOhhTM VgtA== X-Gm-Message-State: ALoCoQmyZfPEe6Kk7iiirTcBIMaFg6PDcFf3Cil2Y9JcH2vB2JmbGxCZvMlcTKHck7q5zvJCQvVc X-Received: by 10.140.101.22 with SMTP id t22mr83633987qge.9.1426615611364; Tue, 17 Mar 2015 11:06:51 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:381:1ca7:409d:c366:febf? ([2601:a:2a00:381:1ca7:409d:c366:febf]) by mx.google.com with ESMTPSA id b74sm10127167qga.40.2015.03.17.11.06.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 11:06:50 -0700 (PDT) Message-ID: <55086D3C.5090605@nthpermutation.com> Date: Tue, 17 Mar 2015 14:06:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000207030406010306070407" Archived-At: Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:06:55 -0000 This is a multi-part message in MIME format. --------------000207030406010306070407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry for being pedantic but... The Nonce is the fixed (per connection) part of the quantity of bits that are encrypted to produce one block of cipher text that's XOR'd with the plain text to produce the encrypted message block. The Nonce plus the message sequence number is the per-message initialization vector. The Nonce plus the message sequence number plus the block number is the per block value to be encrypted. At least for CCM and GCM. The Nonce is common across all messages within a session. (*sigh* the more general meaning of nonce is that of a unique per-invocation value but given that all per-message/per-block "nonce" usages contain the per-connection nonce it would be useful to not overload this too much - among other reasons: an IV is not always a nonce but can be, a nonce is not usually an IV but can be, most messages require an IV, most blocks don't). So maybe we call this the "Session Nonce" for clarity? In original TLS, the IV produced during session setup was actually not "the" IV, but "an" IV used for the first message. Then McGrew's AEAD modes repurposed the IV data produced as a nonce for the AEAD modes. So what you're proposing is to eliminate the determination of the Nonce as part of the session negotiation and make it a fixed value. E.g., we have an explicit nonce which is always zero which produces a per-message IV based on the sequence number of '0's | | . As a side effect that also eliminates the per-message IV field (which aren't actually used by the currently defined AEAD modes AFAICT). That works for the currently defined pure AEAD modes (CCM/GCM at least, haven't looked at chacha). Will that work in all cases for constructed AEAD modes? (e.g. where we build an AEAD mode out of an encryption mode and an integrity mode and derive the E and I keys from a single key internal to the constructed mode - say AES-CBC with CMAC for example). Short answer is probably not. Basically, this complete eliminates the ability to use CBC (or any cipher mode that requires an explicit per message IV) from TLS. Not arguing for or against this at this point, but not clear that everyone understands the side effects of this decision. Mike On 3/16/2015 7:54 PM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/155 > Target merge date: 3/21 > > Currently: > > - AES-GCM uses a partially explicit nonce > - The ChaCha20 draft uses the sequence number as the nonce. > > As Stephen Kent has observed, the idea behind the explicit IV is to > allow the > cryptographic module implementing the AEAD algorithm to ensure non-reuse > of the nonce. However, for ChaCha I believe we came to the conclusion > that it > was acceptable to use the sequence number as the nonce, as the module can > check for sequential usage. This saves 8 octets on the wire. > > In the interim in Seattle, we came to the conclusion that we should make > all AEAD algorithms behave this way, which also simplifies the spec some. > I've formatted this into a PR to verify the consensus on the list. > Please comment > here if you object and on the PR if you have editorial comments. > > https://github.com/tlswg/tls13-spec/pull/155 > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------000207030406010306070407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry for being pedantic but...

The Nonce is the fixed (per connection) part of the quantity of bits that are encrypted to produce one block of cipher text that's XOR'd with the plain text to produce the encrypted message block.   The Nonce plus the message sequence number is the per-message initialization vector.   The Nonce plus the message sequence number plus the block number is the per block value to be encrypted.   At least for CCM and GCM.

The Nonce is common across all messages within a session.   (*sigh* the more general meaning of nonce is that of a unique per-invocation value but given that all per-message/per-block "nonce" usages contain the per-connection nonce it would be useful to not overload this too much - among other reasons:  an IV is not always a nonce but can be, a nonce is not usually an IV but can be, most messages require an IV, most blocks don't).  So maybe we call this the "Session Nonce" for clarity?


In original TLS, the IV produced during session setup was actually not "the" IV, but "an" IV used for the first message.  Then McGrew's AEAD modes repurposed the IV data produced as a nonce for the AEAD modes.

So what you're proposing is to eliminate the determination of the Nonce as part of the session negotiation and make it a fixed value.  E.g., we have an explicit nonce which is always zero which produces a per-message IV based on the sequence number of '0's | <sequence counter> | <block counter>.  As a side effect that also eliminates the per-message IV field (which aren't actually used by the currently defined AEAD modes AFAICT).

That works for the currently defined pure AEAD modes (CCM/GCM at least, haven't looked at chacha).   Will that work in all cases for constructed AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode and an integrity mode and derive the E and I keys from a single key internal to the constructed mode - say  AES-CBC with CMAC for example).  Short answer is probably not. 

Basically, this complete eliminates the ability to use CBC (or any cipher mode that requires an explicit per message IV) from TLS.  Not arguing for or against this at this point, but not clear that everyone understands the side effects of this decision.

Mike


On 3/16/2015 7:54 PM, Eric Rescorla wrote:
Target merge date: 3/21

Currently:

- AES-GCM uses a partially explicit nonce
- The ChaCha20 draft uses the sequence number as the nonce.

As Stephen Kent has observed, the idea behind the explicit IV is to allow the
cryptographic module implementing the AEAD algorithm to ensure non-reuse
of the nonce. However, for ChaCha I believe we came to the conclusion that it
was acceptable to use the sequence number as the nonce, as the module can
check for sequential usage. This saves 8 octets on the wire.

In the interim in Seattle, we came to the conclusion that we should make
all AEAD algorithms behave this way, which also simplifies the spec some.
I've formatted this into a PR to verify the consensus on the list. Please comment
here if you object and on the PR if you have editorial comments.


-Ekr



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

--------------000207030406010306070407-- From nobody Tue Mar 17 11:10: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 63ED01A884D for ; Tue, 17 Mar 2015 11:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GielSNZY3qNr for ; Tue, 17 Mar 2015 11:10:28 -0700 (PDT) Received: from prodomx04.usaa.com (prodomx04.usaa.com [167.24.25.70]) (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 542911A8824 for ; Tue, 17 Mar 2015 11:10:28 -0700 (PDT) Received: from pps.filterd (prodomx04.usaa.com [127.0.0.1]) by prodomx04.usaa.com (8.14.7/8.14.7) with SMTP id t2HI9Bg5022186; Tue, 17 Mar 2015 13:10:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=201408; bh=/Y7sih26YQju/hsLNaZTrpJh2JrNG/Y+s9OAKjVVnT0=; b=fd8zcGLBBn6X9B5Tmo//cffL3HZXX3x9tRd2R8KOYCJBcMGWWo/H36F67VfcKeqO9LuI 1PmzFHzatyb5jD1TOOXkBJFqHCxCiMeDQXoJUin+fK/nrgROxF0ALPmjbwX4UFHNkimZ gFrbX/ri+v6xR5N+LDjJ9DVZsqP/PbVql9QrQcydyFFn51jvNlrw0mfkKMbZlszYSQYt P9eBbkuvBhcjNj3ax/CugAL0e+g7+04aU5xdgyhzhBHeIAJDNyKoTNsCXziQWRYYRJ8I xRcODQ4GRua7DgnWH5X2UWXbO+HDuvtcf+9qlMHwAT0dQe7MWEukISoL6JQ2krl5sTaB gA== Received: from prodexch06w.eagle.usaa.com (prodexch06w.eagle.usaa.com [10.170.40.22]) by prodomx04.usaa.com with ESMTP id 1t36bawu1v-1; Tue, 17 Mar 2015 13:10:26 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.159]) by PRODEXCH06W.eagle.usaa.com ([10.170.40.22]) with mapi id 14.03.0158.001; Tue, 17 Mar 2015 13:10:25 -0500 From: "Mehner, Carl" To: Eric Rescorla , Dave Garrett Thread-Topic: [TLS] Signature Algorithms Thread-Index: AQHQYN2keZkvConmFEatyoGpqnKTLw== Date: Tue, 17 Mar 2015 18:10:25 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D411463AF8@PRODEXMB01W.eagle.usaa.com> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.15.114] x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: multipart/alternative; boundary="_000_19075EB00EA7FE49AFF87E5818D673D411463AF8PRODEXMB01Weagl_" MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-17_04:2015-03-17,2015-03-17,1970-01-01 signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:10:31 -0000 --_000_19075EB00EA7FE49AFF87E5818D673D411463AF8PRODEXMB01Weagl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGFyZ3VpbmcgZm9yIFRMUyAxLjMgdG8gZHJvcCBzdXBwb3J0IGZvciBTSEEtMSAo dGhhdOKAmXMgdXAgdG8gdGhlIGNsaWVudCBjb25maWd1cmVyKSwgSeKAmW0gYXJndWluZyBmb3Ig dGhlIFRMUyBzaWduYXR1cmUgYWxnb3JpdGhtcyBleHRlbnNpb24gdG8gbm90IHNwZWNpZnkgdGhl IHNpZ25hdHVyZSBvZiBhIHJvb3QuIFRoaXMgc2FtZSBhcmd1bWVudCBhcHBsaWVzIGZvciBNRDUg cm9vdHMgd2l0aCBsb25nIHRlcm0gU0hBLTEgZW5kLWVudGl0eSBjZXJ0cy4NCg0KSWYgd2Ugd2Fu dCB0byBkcm9wIE1ENSBFRS1jZXJ0cyBieSByZW1vdmluZyBNRDUgZnJvbSB0aGUgc2lnbmF0dXJl IGFsZ29yaXRobXMsIGFuZCB5b3Ugd2FudCB0byBrZWVwIHlvdXIgbG9uZyB0ZXJtIFNIQS0xIEVF LWNlcnQgdGhhdCBoYXMgYSBjaGFpbiB3aGljaCBpcyBjYXBwZWQgYnkgYW4gTUQ1IHJvb3QsIHlv dSB3b3VsZCBub3QgYmUgYWJsZSB0byBzZW5kIHRoYXQgcm9vdCBpbiB0aGUgY2VydGlmaWNhdGVf bGlzdCBhcyB0aGUgZG9jdW1lbnQgaXMgd3JpdHRlbiB0b2RheS4gVGhlIHRleHQgSSBzdWdnZXN0 ZWQgYWxsb3dzIHlvdSB0byBzdGlsbCBzZW5kIHRoZSByb290Lg0KDQoNCg0KSWYgdGhlIGNsaWVu dCBwcm92aWRlZCBhICJzaWduYXR1cmVfYWxnb3JpdGhtcyIgZXh0ZW5zaW9uLCB0aGVuIGFsbA0K DQogICBjZXJ0aWZpY2F0ZXMgcHJvdmlkZWQgYnkgdGhlIHNlcnZlciwgZXhjZXB0IGZvciB0aGUg c2VsZi1zaWduZWQNCg0KICAgcm9vdCBDQSBjZXJ0aWZpY2F0ZSwgTVVTVCBiZSBzaWduZWQgYnkg YSBoYXNoL3NpZ25hdHVyZSBhbGdvcml0aG0NCg0KICAgcGFpciB0aGF0IGFwcGVhcnMgaW4gdGhh dCBleHRlbnNpb24uDQouLi4NCg0KDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JA cnRmbS5jb21dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxNywgMjAxNSAxOjAwIFBNDQpUbzogRGF2 ZSBHYXJyZXR0DQpDYzogdGxzQGlldGYub3JnOyBNZWhuZXIsIENhcmwNClN1YmplY3Q6IEVYVEVS TkFMOiBSZTogW1RMU10gU2lnbmF0dXJlIEFsZ29yaXRobXMNCg0KDQoNCg0KDQoNCg0KT24gVHVl LCBNYXIgMTcsIDIwMTUgYXQgMTA6NDEgQU0sIERhdmUgR2FycmV0dCA8ZGF2ZW1nYXJyZXR0QGdt YWlsLmNvbTxtYWlsdG86ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpPbiBTYXR1 cmRheSwgTWFyY2ggMTQsIDIwMTUgMTE6NDA6MzggcG0gTWVobmVyLCBDYXJsIHdyb3RlOg0KPiBB cyB3ZSBtb3ZlIGludG8gYSB3b3JsZCB0aGF0IGxhY2tzIHRydXN0ZWQgU0hBLTEgc2lnbmF0dXJl cywgYSBjaGFuZ2UgaW4gdGhlIHRleHQgd291bGQgYmUgbmVjZXNzYXJ5IGluIG9yZGVyIGZvciBj bGllbnRzIHRoYXQgZHJvcCBTSEEtMSBmcm9tIHRoZSBzdXBwb3J0ZWQgaGFzaCBhbGdvcml0aG1z IHRvIGNvbnRpbnVlIHRvIGNvbm5lY3QgdG8gc2VydmVycyB0aGF0IHNlbmQgYSBjZXJ0aWZpY2F0 ZV9saXN0IHRoYXQgaW5jbHVkZXMgcm9vdHMgc2lnbmVkIHdpdGggU0hBLTEuDQoNCldoYXQncyB0 aGUgdmlhYmlsaXR5IG9mIGhhdmluZyBUTFMgMS4zIGRyb3Agc3VwcG9ydCBmb3IgU0hBLTEgZm9y IGVuZC1lbnRpdHkgY2VydGlmaWNhdGVzPyAobm90IHJvb3Qgb3IgaW50ZXJtZWRpYXJ5LCB5ZXQp DQoNCg0KDQpJIHdvdWxkIG5vdCBiZSBpbiBmYXZvciBvZiB0aGlzLiBNYW55IHBlb3BsZSBoYXZl IGNlcnRpZmljYXRlcyB3aXRoIHZlcnkgbG9uZyBsaWZldGltZXMNCg0KYW5kIHRoaXMgd291bGQg ZWZmZWN0aXZlbHkgbWVhbiB0aGF0IHBlb3BsZSBjb3VsZCBub3QgZHJvcCBpbiBUTFMgMS4zIGZv ciAxLjIgb24NCg0KdGhlaXIgc2VydmVycywgd2hpY2ggd291bGQgYmUgYmFkLg0KDQoNCg0KLUVr cg0KDQoNCg0KDQoNCg0KDQogICBUaGlzIHdvdWxkIG9mIGNvdXJzZSBiZSBpbiBhZGRpdGlvbiB0 byBkcm9wcGluZyBhbGwgc3VwcG9ydCBmb3IgTUQ1LCB3aGljaCBJIHRoaW5rIGlzIHByZXR0eSBt dWNoIGEgZ2l2ZW4gYXQgdGhpcyBwb2ludC4NCg0KICAgSWYgaXQgd2VyZSB0byBiZSBuZXcgcG9s aWN5IHJpZ2h0IHRoaXMgc2Vjb25kLCB0aGF0IHdvdWxkbid0IGJlIGdyZWF0LCBidXQgYnkgdGhl IHRpbWUgVExTIDEuMyBpcyByZWFkeSBmb3Igd2lkZXNwcmVhZCBhZG9wdGlvbiBJIHRoaW5rIHRo YXQncyBhIHJlYXNvbmFibGUgZXhwZWN0YXRpb24uIExhdGVzdCBzdXJ2ZXkgc2hvd3MgdGhlIFNI QS0xIHRvIFNIQS0yIHJhdGlvIGF0IGFib3V0IDI6MyBhbmQgaW1wcm92aW5nIHN0ZWFkaWx5LiBT SEEtMiB3aWxsIHByb2JhYmx5IGJlIHVzZWQgaW4gdGhlIG1ham9yaXR5IHdpdGhpbiBhIGNvdXBs ZSBtb250aHMgb3Igc28uDQoNCg0KICAgRGF2ZQ0KDQoNCg0K --_000_19075EB00EA7FE49AFF87E5818D673D411463AF8PRODEXMB01Weagl_ 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 cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjVwdDsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5 bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPknigJltIG5vdCBhcmd1aW5nIGZvciBUTFMgMS4zIHRvIGRyb3Agc3VwcG9y dCBmb3IgU0hBLTEgKHRoYXTigJlzIHVwIHRvIHRoZSBjbGllbnQgY29uZmlndXJlciksIEnigJlt IGFyZ3VpbmcgZm9yIHRoZSBUTFMgc2lnbmF0dXJlIGFsZ29yaXRobXMgZXh0ZW5zaW9uIHRvIG5v dCBzcGVjaWZ5DQogdGhlIHNpZ25hdHVyZSBvZiBhIHJvb3QuIFRoaXMgc2FtZSBhcmd1bWVudCBh cHBsaWVzIGZvciBNRDUgcm9vdHMgd2l0aCBsb25nIHRlcm0gU0hBLTEgZW5kLWVudGl0eSBjZXJ0 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgd2Ugd2FudCB0byBkcm9wIE1ENSBF RS1jZXJ0cyBieSByZW1vdmluZyBNRDUgZnJvbSB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobXMsIGFu ZCB5b3Ugd2FudCB0byBrZWVwIHlvdXIgbG9uZyB0ZXJtIFNIQS0xIEVFLWNlcnQgdGhhdCBoYXMg YSBjaGFpbiB3aGljaCBpcyBjYXBwZWQNCiBieSBhbiBNRDUgcm9vdCwgeW91IHdvdWxkIG5vdCBi ZSBhYmxlIHRvIHNlbmQgdGhhdCByb290IGluIHRoZSBjZXJ0aWZpY2F0ZV9saXN0IGFzIHRoZSBk b2N1bWVudCBpcyB3cml0dGVuIHRvZGF5LiBUaGUgdGV4dCBJIHN1Z2dlc3RlZCBhbGxvd3MgeW91 IHRvIHN0aWxsIHNlbmQgdGhlIHJvb3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHRo ZSBjbGllbnQgcHJvdmlkZWQgYSAmcXVvdDtzaWduYXR1cmVfYWxnb3JpdGhtcyZxdW90OyBleHRl bnNpb24sIHRoZW4gYWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgY2VydGlmaWNhdGVzIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIsIGV4Y2VwdCBm b3IgdGhlIHNlbGYtc2lnbmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgcm9vdCBDQSBjZXJ0aWZpY2F0ZSwgTVVTVCBiZSBzaWduZWQgYnkgYSBo YXNoL3NpZ25hdHVyZSBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4m bmJzcDsmbmJzcDsgcGFpciB0aGF0IGFwcGVhcnMgaW4gdGhhdCBleHRlbnNpb24uPGJyPg0KLi4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29y bGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFy Y2ggMTcsIDIwMTUgMTowMCBQTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBHYXJyZXR0PGJyPg0KPGI+ Q2M6PC9iPiB0bHNAaWV0Zi5vcmc7IE1laG5lciwgQ2FybDxicj4NCjxiPlN1YmplY3Q6PC9iPiBF WFRFUk5BTDogUmU6IFtUTFNdIFNpZ25hdHVyZSBBbGdvcml0aG1zPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWFyIDE3LCAyMDE1IGF0IDEwOjQxIEFN LCBEYXZlIEdhcnJldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZlbWdhcnJldHRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGF2ZW1nYXJyZXR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0dXJkYXksIE1hcmNoIDE0 LCAyMDE1IDExOjQwOjM4IHBtIE1laG5lciwgQ2FybCB3cm90ZTo8YnI+DQomZ3Q7IEFzIHdlIG1v dmUgaW50byBhIHdvcmxkIHRoYXQgbGFja3MgdHJ1c3RlZCBTSEEtMSBzaWduYXR1cmVzLCBhIGNo YW5nZSBpbiB0aGUgdGV4dCB3b3VsZCBiZSBuZWNlc3NhcnkgaW4gb3JkZXIgZm9yIGNsaWVudHMg dGhhdCBkcm9wIFNIQS0xIGZyb20gdGhlIHN1cHBvcnRlZCBoYXNoIGFsZ29yaXRobXMgdG8gY29u dGludWUgdG8gY29ubmVjdCB0byBzZXJ2ZXJzIHRoYXQgc2VuZCBhIGNlcnRpZmljYXRlX2xpc3Qg dGhhdCBpbmNsdWRlcyByb290cw0KIHNpZ25lZCB3aXRoIFNIQS0xLjxicj4NCjxicj4NCldoYXQn cyB0aGUgdmlhYmlsaXR5IG9mIGhhdmluZyBUTFMgMS4zIGRyb3Agc3VwcG9ydCBmb3IgU0hBLTEg Zm9yIGVuZC1lbnRpdHkgY2VydGlmaWNhdGVzPyAobm90IHJvb3Qgb3IgaW50ZXJtZWRpYXJ5LCB5 ZXQpDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291 bGQgbm90IGJlIGluIGZhdm9yIG9mIHRoaXMuIE1hbnkgcGVvcGxlIGhhdmUgY2VydGlmaWNhdGVz IHdpdGggdmVyeSBsb25nIGxpZmV0aW1lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoaXMgd291bGQgZWZmZWN0aXZlbHkgbWVhbiB0aGF0 IHBlb3BsZSBjb3VsZCBub3QgZHJvcCBpbiBUTFMgMS4zIGZvciAxLjIgb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZWlyIHNlcnZlcnMsIHdo aWNoIHdvdWxkIGJlIGJhZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3b3VsZCBvZiBjb3Vyc2UgYmUgaW4gYWRk aXRpb24gdG8gZHJvcHBpbmcgYWxsIHN1cHBvcnQgZm9yIE1ENSwgd2hpY2ggSSB0aGluayBpcyBw cmV0dHkgbXVjaCBhIGdpdmVuIGF0IHRoaXMgcG9pbnQuPGJyPg0KPGJyPg0KSWYgaXQgd2VyZSB0 byBiZSBuZXcgcG9saWN5IHJpZ2h0IHRoaXMgc2Vjb25kLCB0aGF0IHdvdWxkbid0IGJlIGdyZWF0 LCBidXQgYnkgdGhlIHRpbWUgVExTIDEuMyBpcyByZWFkeSBmb3Igd2lkZXNwcmVhZCBhZG9wdGlv biBJIHRoaW5rIHRoYXQncyBhIHJlYXNvbmFibGUgZXhwZWN0YXRpb24uIExhdGVzdCBzdXJ2ZXkg c2hvd3MgdGhlIFNIQS0xIHRvIFNIQS0yIHJhdGlvIGF0IGFib3V0IDI6MyBhbmQgaW1wcm92aW5n IHN0ZWFkaWx5LiBTSEEtMg0KIHdpbGwgcHJvYmFibHkgYmUgdXNlZCBpbiB0aGUgbWFqb3JpdHkg d2l0aGluIGEgY291cGxlIG1vbnRocyBvciBzby48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RGF2ZTwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_19075EB00EA7FE49AFF87E5818D673D411463AF8PRODEXMB01Weagl_-- From nobody Tue Mar 17 11:21: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 1513B1A884F for ; Tue, 17 Mar 2015 11:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6dcaInMdDUu for ; Tue, 17 Mar 2015 11:21:27 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::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 A766D1A8846 for ; Tue, 17 Mar 2015 11:21:26 -0700 (PDT) Received: by labjg1 with SMTP id jg1so16133182lab.2 for ; Tue, 17 Mar 2015 11:21:25 -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=7JHt79PbRPo8Mpi5ZLP03UV7IoO7uZSKlS55J236Kps=; b=O0mM0CQCvEEwAj0VrMszqXip5t/Mls6TBKwnQoc74QQFnsRn+P7YSw86cAuC3zwnPG cqzODdN0wdgXZkMzv0hRt6NkGAhGU3fQH1AVNGWNEpfczRQcgJUIJXfoc1cb+irHhllE 5r9W7t2njzhlkoU7quvMh11bj9oGiBDwiXeRTNFGCbSIqj116YgUcZhccFh70WTptjge 1p5wH3jIKorh3JZqpOdHsDIscUTU8DUXH0eyae8hwyw7O5CY5MzsEBI2I9Dv2LcpdOuv UDMJKHvhdp7mDlf/3dcZk2Lq66FfLRRqVmwkYqQI61Dj1glcSnd4QF2I6tsICQu+iuJz 4Mhw== MIME-Version: 1.0 X-Received: by 10.152.181.197 with SMTP id dy5mr61647107lac.57.1426616485127; Tue, 17 Mar 2015 11:21:25 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.55.71 with HTTP; Tue, 17 Mar 2015 11:21:24 -0700 (PDT) In-Reply-To: <55086D3C.5090605@nthpermutation.com> References: <55086D3C.5090605@nthpermutation.com> Date: Tue, 17 Mar 2015 11:21:24 -0700 X-Google-Sender-Auth: bzuD1TiPS56BZAcpmrt8d3pvdEg Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:21:28 -0000 On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns wrote: > That works for the currently defined pure AEAD modes (CCM/GCM at least, > haven't looked at chacha). Will that work in all cases for constructed > AEAD modes? (e.g. where we build an AEAD mode out of an encryption mode and > an integrity mode and derive the E and I keys from a single key internal to > the constructed mode - say AES-CBC with CMAC for example). Short answer is > probably not. I believe that it will, although I welcome counterexamples. The AEAD interface requires only an nonce (i.e. unique, but not unpredictable) and, under this proposal, that's all that TLS will provide. CBC modes require an IV (i.e. unpredictable). If you wished to make an AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something like this: Define the key length to be twice as large as the AES key and split it internally into a CBC key and an IV key. For each record, generate the IV by AES(key = IV_key, block = nonce) then encrypt the plaintext using CBC with that IV and the CBC key. (And you might need extra key bytes for the HMAC too, but that's beside the point here.) Basically you can generate the IVs using AES-CTR as a PRNG. Cheers AGL From nobody Tue Mar 17 11:22: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 266681A1BB9 for ; Tue, 17 Mar 2015 11:22: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 nVGliuvR3-HU for ; Tue, 17 Mar 2015 11:22:51 -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 2A2DA1A1B92 for ; Tue, 17 Mar 2015 11:22:51 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so70333967wib.0 for ; Tue, 17 Mar 2015 11:22: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=bNVB2UExLgO4Cbbplmxmao4y4SNBuudw+C4Vu8HN3OA=; b=JgQafO2Om8hkI32nIy/hGUndokAxLv62VgM1kpq5tpxxj17qXsA5d7NjJP8xDQXzav vSIzW0TNct0AkwhlypeJfjK9GNRsiAgYT4yTuxWyTPSbDlfE2WeHpGZ8bvON04snUJH9 2X9K6m6mLMO2LktshhHAK2Tn5aRHQyhRpIL7kQ19J0ImM0Av7GkVWIRhPCo/6TSqW9LK nPheaHrkTs88qirGIgaXUsnY75x24jpeaMG87XF/Gpxogd/6A0cjePIQccYtVbrrOOw4 HjzmLardfeWGxboPPkpX9s0xUAsoBb/pSDr7L+YtBSVn4FQk9QolrMV+dvb/uVyZVqMq Xa+w== X-Gm-Message-State: ALoCoQl4tem9Kv9K0yUj4mqoRYb4ftHO4GwAEFVxVkfoNLJFKFOaR5vREeP5meUdpyNw22M7Hk7b X-Received: by 10.180.19.73 with SMTP id c9mr197064wie.10.1426616569726; Tue, 17 Mar 2015 11:22:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Tue, 17 Mar 2015 11:22:09 -0700 (PDT) In-Reply-To: <55086D3C.5090605@nthpermutation.com> References: <55086D3C.5090605@nthpermutation.com> From: Eric Rescorla Date: Tue, 17 Mar 2015 11:22:09 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=bcaec53d546fde9a290511800d4d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:22:54 -0000 --bcaec53d546fde9a290511800d4d Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns wrote: > Sorry for being pedantic but... > > The Nonce is the fixed (per connection) part of the quantity of bits that > are encrypted to produce one block of cipher text that's XOR'd with the > plain text to produce the encrypted message block. The Nonce plus the > message sequence number is the per-message initialization vector. The > Nonce plus the message sequence number plus the block number is the per > block value to be encrypted. At least for CCM and GCM. > > The Nonce is common across all messages within a session. (*sigh* the > more general meaning of nonce is that of a unique per-invocation value but > given that all per-message/per-block "nonce" usages contain the > per-connection nonce it would be useful to not overload this too much - > among other reasons: an IV is not always a nonce but can be, a nonce is > not usually an IV but can be, most messages require an IV, most blocks > don't). So maybe we call this the "Session Nonce" for clarity? > I realize that the terminology is confusing, but I'm using the terms from RFC 5116 section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this context, the nonce is not per-connection but rather per AEAD function invocation: A nonce N. Each nonce provided to distinct invocations of the Authenticated Encryption operation MUST be distinct, for any particular value of the key, unless each and every nonce is zero- length. In this context, the AEAD function is invoked once for each TLS record encryption. > So what you're proposing is to eliminate the determination of the Nonce as > part of the session negotiation and make it a fixed value. E.g., we have > an explicit nonce which is always zero which produces a per-message IV > based on the sequence number of '0's | | counter>. As a side effect that also eliminates the per-message IV field > (which aren't actually used by the currently defined AEAD modes AFAICT). > AES-GCM uses this field, which is the motivation for this change. > That works for the currently defined pure AEAD modes (CCM/GCM at least, > haven't looked at chacha). Will that work in all cases for constructed > AEAD modes? (e.g. where we build an AEAD mode out of an encryption mode > and an integrity mode and derive the E and I keys from a single key > internal to the constructed mode - say AES-CBC with CMAC for example). > Short answer is probably not. > > Basically, this complete eliminates the ability to use CBC (or any cipher > mode that requires an explicit per message IV) from TLS. Not arguing for > or against this at this point, but not clear that everyone understands the > side effects of this decision. > As discussed at the interim, I don't believe that this is correct. See AGL's message for a proposed construction. -Ekr Mike > > > > On 3/16/2015 7:54 PM, Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/155 > Target merge date: 3/21 > > Currently: > > - AES-GCM uses a partially explicit nonce > - The ChaCha20 draft uses the sequence number as the nonce. > > As Stephen Kent has observed, the idea behind the explicit IV is to > allow the > cryptographic module implementing the AEAD algorithm to ensure non-reuse > of the nonce. However, for ChaCha I believe we came to the conclusion that > it > was acceptable to use the sequence number as the nonce, as the module can > check for sequential usage. This saves 8 octets on the wire. > > In the interim in Seattle, we came to the conclusion that we should make > all AEAD algorithms behave this way, which also simplifies the spec some. > I've formatted this into a PR to verify the consensus on the list. Please > comment > here if you object and on the PR if you have editorial comments. > > https://github.com/tlswg/tls13-spec/pull/155 > > -Ekr > > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --bcaec53d546fde9a290511800d4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <= ;msj@nthpermuta= tion.com> wrote:
=20 =20 =20
Sorry for being pedantic but...

The Nonce is the fixed (per connection) part of the quantity of bits that are encrypted to produce one block of cipher text that'= s XOR'd with the plain text to produce the encrypted message block.=C2=A0=C2=A0 The Nonce plus the message sequence number is the per-message initialization vector.=C2=A0=C2=A0 The Nonce plus the mes= sage sequence number plus the block number is the per block value to be encrypted.=C2=A0=C2=A0 At least for CCM and GCM.

The Nonce is common across all messages within a session.=C2=A0=C2=A0 (*sigh* the more general meaning of nonce is that of a unique per-invocation value but given that all per-message/per-block "nonce" usages contain the per-connection nonce it would be= useful to not overload this too much - among other reasons:=C2=A0 an IV is n= ot always a nonce but can be, a nonce is not usually an IV but can be, most messages require an IV, most blocks don't).=C2=A0 So may= be we call this the "Session Nonce" for clarity?
<= /blockquote>

I realize that the terminology is confusing= , but I'm using the terms from RFC 5116
section 2.1 (https://tools.ietf.org= /html/rfc5116#section-2.1). In this context, the
nonce is not= per-connection but rather per AEAD function invocation:

=C2=A0 =C2=A0 =C2=A0 A nonce N.=C2=A0 Each nonce provided to distinc= t invocations of the
=C2=A0 =C2=A0 =C2=A0 Authenticated Encryptio= n operation MUST be distinct, for any
=C2=A0 =C2=A0 =C2=A0 partic= ular value of the key, unless each and every nonce is zero-
=C2= =A0 =C2=A0 =C2=A0 length.

In this context, the AEA= D function is invoked once for each TLS record
encryption.
<= div>
=C2=A0
So what you're proposing is to eliminate the determination of the Nonce as part of the session negotiation and make it a fixed value.=C2=A0 E.g., we have an explicit nonce which is always zero whi= ch produces a per-message IV based on the sequence number of '0'= s | <sequence counter> | <block counter>.=C2=A0 As a side effect that also eliminates the per-message IV field (which aren'= t actually used by the currently defined AEAD modes AFAICT).
<= /div>

AES-GCM uses this field, which is the= motivation for this change.

=C2=A0
That works for the currently defined pure AEAD modes (CCM/GCM at least, haven't looked at chacha).=C2=A0=C2=A0 Will that work in a= ll cases for constructed AEAD modes?=C2=A0 (e.g. where we build an AEAD mode o= ut of an encryption mode and an integrity mode and derive the E and I keys from a single key internal to the constructed mode - say=C2=A0 AES-CBC with CMAC for example).=C2=A0 Short answer is probably not.= =C2=A0

Basically, this complete eliminates the ability to use CBC (or any cipher mode that requires an explicit per message IV) from TLS.=C2=A0 Not arguing for or against this at this point, but not clear that everyone understands the side effects of this decision.

As discussed at the interim, I don't= believe that this is correct. See AGL's message
for a propos= ed construction.

-Ekr


Mike



On 3/16/2015 7:54 PM, Eric Rescorla wrote:
Target merge date: 3/21

Currently:

- AES-GCM uses a partially explicit nonce
- The ChaCha20 draft uses the sequence number as the nonce.

As Stephen Kent has observed, the idea behind the explicit IV is to allow the
cryptographic module implementing the AEAD algorithm to ensure non-reuse
of the nonce. However, for ChaCha I believe we came to the conclusion that it
was acceptable to use the sequence number as the nonce, as the module can
check for sequential usage. This saves 8 octets on the wire.

In the interim in Seattle, we came to the conclusion that we should make
all AEAD algorithms behave this way, which also simplifies the spec some.
I've formatted this into a PR to verify the consensus on the list. Please comment
here if you object and on the PR if you have editorial comments.


-Ekr



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


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


--bcaec53d546fde9a290511800d4d-- From nobody Tue Mar 17 11:23: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 39F771A1B92 for ; Tue, 17 Mar 2015 11:23:40 -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 TwyHME-QFPtA for ; Tue, 17 Mar 2015 11:23:38 -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 5C85F1A8866 for ; Tue, 17 Mar 2015 11:23:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6D6DA283011; Tue, 17 Mar 2015 18:23:29 +0000 (UTC) Date: Tue, 17 Mar 2015 18:23:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150317182329.GJ3223@mournblade.imrryr.org> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> <19075EB00EA7FE49AFF87E5818D673D411463AF8@PRODEXMB01W.eagle.usaa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D411463AF8@PRODEXMB01W.eagle.usaa.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Signature Algorithms 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, 17 Mar 2015 18:23:40 -0000 On Tue, Mar 17, 2015 at 06:10:25PM +0000, Mehner, Carl wrote: > If we want to drop MD5 EE-certs by removing MD5 from the signature > algorithms, and you want to keep your long term SHA-1 EE-cert that has a > chain which is capped by an MD5 root, you would not be able to send that > root in the certificate_list as the document is written today. The text > I suggested allows you to still send the root. It may be sensible to recognize that in many cases the server has a single certificate chain and can only send that regardles of what the client's signature algorithms extension indicates. Therefore, though when possible, the server should prefer to send something that the client is known to support, the server should be able to send whatever it has, and it is then up to the client to accept that, or not. At that point, the client may choose to only validate the signatures that matter. In particular self-signatures might not be validated, and their algorithm might be ignored. Similarly the signature of a DANE-TA(2) issuer CA (self-signed or not) would typically be ignored, because the trust-anchor vouching for that is DNSKEY of the zone with the TLSA RRset, and not the signer of the CA certificate. > If the client provided a "signature_algorithms" extension, then all > certificates provided by the server, except for the self-signed root > CA certificate, MUST be signed by a hash/signature algorithm pair that > appears in that extension. Therefore, even this is likely wrong. The server SHOULD try to send conformant chains, but is under no obligation to perform magic, and should not unilaterally abort the connection when it can't. This is what happens in practice anyway, servers send what they have, ignoring this requirement. The real question is what should clients do. -- Viktor. From nobody Tue Mar 17 11:27: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 BA6101A1B92 for ; Tue, 17 Mar 2015 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOidEnrRAWUT for ; Tue, 17 Mar 2015 11:27:48 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::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 4C45A1A1B86 for ; Tue, 17 Mar 2015 11:27:48 -0700 (PDT) Received: by qcto4 with SMTP id o4so16920729qct.3 for ; Tue, 17 Mar 2015 11:27:47 -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=2F+7XQ5owcoaa3vOglJX6gpieue7OsMgIDZQ/LIqC40=; b=kJOJnKdiPlAyeFSHEaFDXZ8vdnD022H2iu8nkUcb7s4mtFQbocon4MUO9lHdxE9bi7 OyyGvqHEAhkUwwa1MMj1Kvd7z/j1d5pgz++dkKxX9I8NXc77N7fYK+AZ6ujCnYRQ/30h RFxlcJpiGTbXOQx2W3z+TlHAVGV0TO8mLVC2YVUbt30vFuaSWnT4uxC0O8/cjaD7qZ4z cnGnO9+2+Mqj8dmyWiuO5RFxsL7Z74fuBphUh0sq1o0LIZ5QkDf1rZykAvlBiOdi/POa oU46SCPX9TrkiRwXWT7ULzPTXzpifejAXy9KlTjEXpd1mADHDFxof+T4DdI0kCL8hCZa gWtw== X-Received: by 10.140.23.134 with SMTP id 6mr81937253qgp.84.1426616867570; Tue, 17 Mar 2015 11:27:47 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j92sm10125245qkh.16.2015.03.17.11.27.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 17 Mar 2015 11:27:47 -0700 (PDT) From: Dave Garrett To: Eric Rescorla Date: Tue, 17 Mar 2015 14:27:45 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503171427.46280.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:27:49 -0000 On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett wrote: > What's the viability of having TLS 1.3 drop support for SHA-1 for > end-entity certificates? (not root or intermediary, yet) On Tuesday, March 17, 2015 01:59:58 pm Eric Rescorla wrote: > I would not be in favor of this. Many people have certificates with very long lifetimes > and this would effectively mean that people could not drop in TLS 1.3 for > 1.2 on their servers, which would be bad. On Tuesday, March 17, 2015 01:51:06 pm Mehner, Carl wrote: > My thoughts were that this would happen on or after the sunset date > (2017-01-01). Dropping SHA-1 for EE-certs is not something I am looking to > have mandated in this document, just allowed for. Ok, then putting strict sunset dates into the specification could be a good route instead. Dave From nobody Tue Mar 17 11:48: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 820451A1BC0 for ; Tue, 17 Mar 2015 11:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4EZjrJB-8g4 for ; Tue, 17 Mar 2015 11:48: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 08EFB1A1BDF for ; Tue, 17 Mar 2015 11:48:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C609E283011; Tue, 17 Mar 2015 18:48:32 +0000 (UTC) Date: Tue, 17 Mar 2015 18:48:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150317184832.GM3223@mournblade.imrryr.org> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> <201503171427.46280.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201503171427.46280.davemgarrett@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] Signature Algorithms 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, 17 Mar 2015 18:48:35 -0000 On Tue, Mar 17, 2015 at 02:27:45PM -0400, Dave Garrett wrote: > Ok, then putting strict sunset dates into the specification could > be a good route instead. This is a PKIX issue, not a TLS protocol issue. I don't think this belongs in the TLS protocol specification. Perhaps someone wants to write a sunset draft for SHA-1 that deprecates SHA-1 in PKIX (RFC 5280) for intermediate CA certificates where collision attacks matter. At the root the signature is irrelevant, and the leaf one needs a second-preimage attack, which I don't recall being on the horizon for SHA-1. -- Viktor. From nobody Tue Mar 17 13:20: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 768B21A88E0 for ; Tue, 17 Mar 2015 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23C_cqW6UGma for ; Tue, 17 Mar 2015 13:19:58 -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 A34621A88DE for ; Tue, 17 Mar 2015 13:19:57 -0700 (PDT) Received: by wixw10 with SMTP id w10so21026575wix.0 for ; Tue, 17 Mar 2015 13:19:56 -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=744jaDWuYdf+b2mZa2CYI8RYxZ8eJjasEV+g2LyyxOM=; b=jxizks1D4OXLhnTwVws3yF5kHOb+Ckfi9l67+uNv2Zj6ljQtrMMQNscyNIf+VTAKa8 cT1nyZ4M80xEroo7Pnw0yyrDNNr/HsUDB6IA2XNb4ljQrsRuGWfKA4HIuF0eR3zblWjM I6fNyu8Ys3kaqsOSkSeaNyTn04U/QgKmwOQtJltXOKlUIekzbyLUV4Le1g2JCUGrathd D2b0JFDvggX91TDIQaq1oUld4RVifs5a4Iko4LlYQkEZssZy4HD1eXfBn9t478c9MOEi PaGtekdzGuQaJnTfPBHLgCs5y+4YXfJNgKVd8MqubKpB3ld5uT4LTKst/Z4lgkws4XRj JJxg== X-Received: by 10.194.94.1 with SMTP id cy1mr132883554wjb.127.1426623596400; Tue, 17 Mar 2015 13:19:56 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id q6sm119298wix.3.2015.03.17.13.19.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:19:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 17 Mar 2015 22:19:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55086D3C.5090605@nthpermutation.com> To: Adam Langley X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:19:59 -0000 > On Mar 17, 2015, at 8:21 PM, Adam Langley = wrote: >=20 > On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns > wrote: >> That works for the currently defined pure AEAD modes (CCM/GCM at = least, >> haven't looked at chacha). Will that work in all cases for = constructed >> AEAD modes? (e.g. where we build an AEAD mode out of an encryption = mode and >> an integrity mode and derive the E and I keys from a single key = internal to >> the constructed mode - say AES-CBC with CMAC for example). Short = answer is >> probably not. >=20 > I believe that it will, although I welcome counterexamples. >=20 > The AEAD interface requires only an nonce (i.e. unique, but not > unpredictable) and, under this proposal, that's all that TLS will > provide. >=20 > CBC modes require an IV (i.e. unpredictable). If you wished to make an > AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something > like this: >=20 > Define the key length to be twice as large as the AES key and split it > internally into a CBC key and an IV key. For each record, generate the > IV by AES(key =3D IV_key, block =3D nonce) then encrypt the plaintext > using CBC with that IV and the CBC key. (And you might need extra key > bytes for the HMAC too, but that's beside the point here.) Basically > you can generate the IVs using AES-CTR as a PRNG. Right. Or you could do like in = https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 , = generate the IV randomly and locally and call it part of the ciphertext = (see appendix A). The AEAD interface has no requirement that the = ciphertext have the same length as the plaintext. In fact CBC requires = padding, so the ciphertext is larger anyway. I do like your way better, but it requires a larger state on both client = and server.=20 I=E2=80=99m also wondering if we can mass convert all the existing CBC = ciphersuites for TLS 1.3, so that ciphersuite 0x00,0x0a could be = TLS_RSA_WITH_3DES_EDE_CBC_SHA in TLS 1.2, but transform into one of = these AEAD constructions for TLS 1.3 without having to allocate new = identifiers. Yoav From nobody Tue Mar 17 15:11: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 E0F8A1A892C for ; Tue, 17 Mar 2015 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiudFR_0zGy1 for ; Tue, 17 Mar 2015 15:11:46 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [74.52.223.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695C81A892B for ; Tue, 17 Mar 2015 15:11:40 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id AE604A5DA4BBA; Tue, 17 Mar 2015 17:11:39 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id A0247A5DA4B67 for ; Tue, 17 Mar 2015 17:11:39 -0500 (CDT) Received: from [96.231.226.227] (port=57461 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YXzi1-0007yo-Od for tls@ietf.org; Tue, 17 Mar 2015 17:11:33 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> Date: Tue, 17 Mar 2015 18:11:32 -0400 To: "TLS@ietf.org (tls@ietf.org)" 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.226.227 X-Exim-ID: 1YXzi1-0007yo-Od X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.226.227]:57461 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 22:11:47 -0000 All, This message summarizes the TLS 1.3 MTI (mandatory to implement) = discussions we had at the Seattle TLS Interim meeting. We=92ll also be = discussing this in Dallas so this is just an FYI message. A couple of things to keep in mind: 1. Anything in [] is predicated on the CFRG proceeding on their current = course. In other words, we are not telling the CFRG these are what we = want we=92re just trying to read the tea leaves. 2. We fully expect that there will be profiles for specific = environments. 3. MTI is not mandatory to use. o Symmetric: MUST AES-GCM 128 [SHOULD ChaCha20-Poly1305] o Hash: MUST SHA-256 o Key Agreement: ECDH MUST P-256 [SHOULD 25519] o Signature: MUST ECDSA P-256 MUST RSA On a related note, we also discussed which curves to keep in the base = specification; when text from RFC 4492 was incorporated it included ~25 = curves. The code points will still exist they just won=92t be in the = base spec. The 4492-list would be pruned to P-256 and P-384 and then = obviously expanded to add [25519] and [448]. spt= From nobody Tue Mar 17 20:07: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 02B591A8A4A for ; Tue, 17 Mar 2015 20:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJJqg8vDq6MJ for ; Tue, 17 Mar 2015 20:07:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1751A8A3E for ; Tue, 17 Mar 2015 20:07:15 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 037A7F984; Tue, 17 Mar 2015 23:07:12 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0321A201D3; Tue, 17 Mar 2015 20:07:07 -0700 (PDT) From: Daniel Kahn Gillmor To: "Mehner\, Carl" , Eric Rescorla , Dave Garrett In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D411463AF8@PRODEXMB01W.eagle.usaa.com> References: <19075EB00EA7FE49AFF87E5818D673D41145FB0C@PRODEXMB01W.eagle.usaa.com> <201503171341.40315.davemgarrett@gmail.com> <19075EB00EA7FE49AFF87E5818D673D411463AF8@PRODEXMB01W.eagle.usaa.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Mar 2015 23:07:07 -0400 Message-ID: <87fv93knqc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Signature Algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 03:07:17 -0000 On Tue 2015-03-17 14:10:25 -0400, Mehner, Carl wrote: > I’m not arguing for TLS 1.3 to drop support for SHA-1 (that’s up to > the client configurer), I’m arguing for the TLS signature algorithms > extension to not specify the signature of a root. This same argument > applies for MD5 roots with long term SHA-1 end-entity certs. The signature algorithm used in the self-signature a root certificate shouldn't be relevant anywhere. The root is either already trusted by the peer (or identified via DANE-TA, in which case the digest restrictions belong in DANE), or it is not. TLS peers should never reject root certs on the grounds of the digest algorithm within the root cert itself. --dkg From nobody Wed Mar 18 00:38: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 C707B1A00A8 for ; Wed, 18 Mar 2015 00:38: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 QXpA51iL8nD9 for ; Wed, 18 Mar 2015 00:38:33 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c: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 E3BB91A00BF for ; Wed, 18 Mar 2015 00:38:32 -0700 (PDT) Received: by wifj2 with SMTP id j2so31598837wif.1 for ; Wed, 18 Mar 2015 00:38:31 -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=QOM1DP1rmxZ4QtK2rCti2QShJCb0P794PNhYQc8OH80=; b=0HX5LlYGV2gXGjjjbPkcrAgGMzKPp+nozAIPnogHlb9sc8H7mN/4bIuMD7cO9juXLY kxAFjmfK89sGJhX15H5XdZbnF0W88TVPWzvaSAd2EllkqbRZtTP6TCNfigwev8aA+gGM dH6F2XUhZ+DtBdjTU3GwT7v6pPxn7cgDiUnVVdDCwSLPO0DplqnAuqCKMgVpfdXmwxRb uFRF3j1/mI/v3bgmrnrfjDk4wPQVFKJrNw4rFHc9RKf8aED2+BG0zD7inkVDqzHLKRfn dv18b7yScdgDKU9N0X85bUek5YRx9ZuVlqWYxk9Yt4AV8w6j+olVinKxlfBlNIHRZ8JE Udww== X-Received: by 10.194.9.98 with SMTP id y2mr142655027wja.85.1426664311736; Wed, 18 Mar 2015 00:38:31 -0700 (PDT) Received: from [172.24.250.128] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id fo8sm1916292wib.14.2015.03.18.00.38.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 00:38:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> Date: Wed, 18 Mar 2015 09:38:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 07:38:35 -0000 > On Mar 18, 2015, at 12:11 AM, Sean Turner wrote: >=20 > All, >=20 > This message summarizes the TLS 1.3 MTI (mandatory to implement) = discussions we had at the Seattle TLS Interim meeting. We=92ll also be = discussing this in Dallas so this is just an FYI message. >=20 > A couple of things to keep in mind: >=20 > 1. Anything in [] is predicated on the CFRG proceeding on their = current course. In other words, we are not telling the CFRG these are = what we want we=92re just trying to read the tea leaves. >=20 > 2. We fully expect that there will be profiles for specific = environments. >=20 > 3. MTI is not mandatory to use. >=20 >=20 > o Symmetric: > MUST AES-GCM 128 > [SHOULD ChaCha20-Poly1305] Please note that CFRG is already done with ChaCha20-Poly1305. The = document is approved and in the RFC Editor=92s queue. The ball is not in this working group=92s court. It=92s time to decide = about draft-mavrogiannopoulos-chacha-tls. Yoav http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04= From nobody Wed Mar 18 02:11: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 7D86E1A1A4F for ; Wed, 18 Mar 2015 02:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7h2hbB57OZR for ; Wed, 18 Mar 2015 02:11:47 -0700 (PDT) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 7A52E1A0143 for ; Wed, 18 Mar 2015 02:11:46 -0700 (PDT) Received: (qmail 22327 invoked by uid 1004); 18 Mar 2015 09:11:44 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 18 Mar 2015 09:11:44 +0000 Received: (qmail 17439 invoked by uid 1000); 18 Mar 2015 09:11:44 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 18 Mar 2015 09:11:44 +0000 Message-ID: <55094150.2010800@comodo.com> Date: Wed, 18 Mar 2015 09:11:44 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yoav Nir , Sean Turner References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> In-Reply-To: <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 09:11:49 -0000 On 18/03/15 07:38, Yoav Nir wrote: >> On Mar 18, 2015, at 12:11 AM, Sean Turner wrote: > Please note that CFRG is already done with ChaCha20-Poly1305. The document is approved and in the RFC Editor’s queue. > > The ball is not in this working group’s court. It’s time to decide about draft-mavrogiannopoulos-chacha-tls. Yoav, s/not/now/ ? > Yoav > > http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Mar 18 04:52: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 71F8A1A007B for ; Wed, 18 Mar 2015 04:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elnoO0iLEsQq for ; Wed, 18 Mar 2015 04:52:28 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 70A2C1A004C for ; Wed, 18 Mar 2015 04:52:28 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so87967270wib.0 for ; Wed, 18 Mar 2015 04:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7NOCjLLSIs54JRtkRkRDzhypUcwmUNkhQJtudS5CuRo=; b=kHtu2UMA13VnpKYNK4lrhRuVOmRjJc42tgbr3LVAj770ZU4SQetVdq1y2SxAZK/X1u UW/bWour8pJKuakLJwbBjGLVUCcHP7sqU1A7pQg03KxSuDIYtwKOG5ePC7ZpvO8lSTCM IXc48k1lS3eCHAT79Rkxu2emVU8QOsAXGEiTfb+Fk3NKcR07M8eXd1w0ma+dKMpb0Ag7 h3qLkiUg+/BA/7G5zfJw8nXkBgbUIVyVc4rftPaECOsjTRC3S2AL0vW88KB+fDRo73Yu pCdDuLxEQhMTjom5DTaZmqMT97JD9JFNijRdKrw2LaohFEcZlgo1opzpbkn+NwvB7VLe sSWA== X-Received: by 10.194.158.39 with SMTP id wr7mr144212725wjb.118.1426679547225; Wed, 18 Mar 2015 04:52:27 -0700 (PDT) Received: from [172.24.250.128] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id vq9sm24167327wjc.6.2015.03.18.04.52.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 04:52:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <55094150.2010800@comodo.com> Date: Wed, 18 Mar 2015 13:52:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E1F10CB-E431-4954-9E21-218D0EEFBAFD@gmail.com> References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> <55094150.2010800@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 11:52:30 -0000 > On Mar 18, 2015, at 11:11 AM, Rob Stradling = wrote: >=20 > On 18/03/15 07:38, Yoav Nir wrote: >>> On Mar 18, 2015, at 12:11 AM, Sean Turner wrote: > >> Please note that CFRG is already done with ChaCha20-Poly1305. The = document is approved and in the RFC Editor=92s queue. >>=20 >> The ball is not in this working group=92s court. It=92s time to = decide about draft-mavrogiannopoulos-chacha-tls. >=20 > Yoav, >=20 > s/not/now/ Yeah. Sorry about that.= From nobody Wed Mar 18 08:31: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 AC5DA1A1AE3 for ; Wed, 18 Mar 2015 08:31:45 -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 d92tjisZEhG7 for ; Wed, 18 Mar 2015 08:31:43 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (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 091CA1A00B2 for ; Wed, 18 Mar 2015 08:31:43 -0700 (PDT) Received: by qgh62 with SMTP id 62so39973884qgh.1 for ; Wed, 18 Mar 2015 08:31:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ly+q3Xi7z25E4Qnyo/PqZwukoEKJ45cHh2Vdr02O39w=; b=nE6lPlG7CSHmgXoCQPsesucFOQDebX3Rt4EKGoJILh3IFrettgyZ5Fjyev0SLLWy6p 7l/a6XTkwK/j1zLFTLd1myyHeD9vfPBGY13u1gI0OW31ubtbPzOAgg7Tk6nR0HHUO6oD tv3OQQBwgTcsSQZGjGvwP14h1n0k+RPYUAK9rT2Ipo8NV+LPaFr25FA4YOYj42vpbaDr uBgSLGGDuA246iI9sz99AuC2fFU/x107Fv69PDo7UCXnWWeIvnqi2wsYy23L8dUcOYo3 XoIoZblpdYG6r6G715yB1Z0eGwihpNbO6ePOwve6KirfOYrUIlQd7nZHzgpLR/10lnbN iPFQ== X-Gm-Message-State: ALoCoQniDJgRrXb8YucaC3rlC73ayL6Z1EZYj9BD289SUuxzcGcdEYtjaqfr7iP7Vim9sfUcnto0 X-Received: by 10.140.150.19 with SMTP id 19mr43987469qhw.69.1426692702291; Wed, 18 Mar 2015 08:31:42 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:381:1ca7:409d:c366:febf? ([2601:a:2a00:381:1ca7:409d:c366:febf]) by mx.google.com with ESMTPSA id d85sm11994571qkh.45.2015.03.18.08.31.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 08:31:41 -0700 (PDT) Message-ID: <55099A60.5020709@nthpermutation.com> Date: Wed, 18 Mar 2015 11:31:44 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Adam Langley References: <55086D3C.5090605@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:31:45 -0000 On 3/17/2015 2:21 PM, Adam Langley wrote: > On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns > wrote: >> That works for the currently defined pure AEAD modes (CCM/GCM at least, >> haven't looked at chacha). Will that work in all cases for constructed >> AEAD modes? (e.g. where we build an AEAD mode out of an encryption mode and >> an integrity mode and derive the E and I keys from a single key internal to >> the constructed mode - say AES-CBC with CMAC for example). Short answer is >> probably not. > I believe that it will, although I welcome counterexamples. > > The AEAD interface requires only an nonce (i.e. unique, but not > unpredictable) and, under this proposal, that's all that TLS will > provide. > > CBC modes require an IV (i.e. unpredictable). If you wished to make an > AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something > like this: > > Define the key length to be twice as large as the AES key and split it > internally into a CBC key and an IV key. For each record, generate the > IV by AES(key = IV_key, block = nonce) then encrypt the plaintext > using CBC with that IV and the CBC key. (And you might need extra key > bytes for the HMAC too, but that's beside the point here.) Basically > you can generate the IVs using AES-CTR as a PRNG. I wouldn't use AES-CTR to generate IVs for AES-CBC, but I take your point. I was actually asking about more than CBC. See below. This is what I got from SP800-38A appendix C > For the CBC and CFB modes, the IVs must be unpredictable. In > particular, for any given plaintext, it must not be possible to > predict the IV that will be associated to the plaintext in advance of > the generation of the IV. > There are two recommended methods for generating unpredictable IVs. > The first method is to apply the forward cipher function, under the > same key that is used for the encryption of the plaintext, to a nonce. > The nonce must be a data block that is unique to each execution of the > encryption operation. For example, the nonce may be a counter, as > described in Appendix B, or a message number. The second method is to > generate a random data block using a FIPS-approved random number > generator. But that's what's defined for CBC and will work with the per-session nonce with per-message sequence number as described above. While at this time we've only got defined cipher suites for CBC, CCM and GCM, (and I should have stated my comment more to this point), will there never be other potential modes that provide some desired security characteristics not currently present that also require explicit per-message IVs? Eliminating the message-wrapping down to the AEAD construct is one thing as you can build AEAD modes out of other modes. I wonder that we're constraining the protocol so much that other, useful, modes might be excluded in the future. E.g. will any of the modes on this list http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html end up in TLS cipher suites at some point? Of these, which require per-message IVs that can't be generated as above? > > > Cheers > > AGL > > From nobody Wed Mar 18 08:48: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 188941A1B1E for ; Wed, 18 Mar 2015 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl66dN6p-dOP for ; Wed, 18 Mar 2015 08:48:38 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.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 04FEC1A1ADD for ; Wed, 18 Mar 2015 08:48:38 -0700 (PDT) Received: by qcbjx9 with SMTP id jx9so2836401qcb.0 for ; Wed, 18 Mar 2015 08:48:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=QDzUaqvoHZUSM6xg1AYRuxxsKkrGOCCsVXp5kbu8Taw=; b=Ey66OVF6tBSxx8XGDMS8Nb/YOqghPgoAqg13onm8+XkapXvEd4kFUby5FIv+8kh+Fk 5JhTxqCW/gwx/OtrxlUL45MMtyj5Ic+5+zL7Zl1FDTUDcsAIWnK924r9qYcLQA9ZDPt2 BGrjoKtJkutN4l5C/K6YZwHlJe3lYvYSGOmIq5t4/efSzzp4gfAMoFzmjQROS/TgVQO1 /qEYT1IVbBUwFdApOg1q3AOxJIQMLC302i3Scm82KlVkh5LYQbj7IiEWKEbfpzVEcNZL 4Yh9aTeLkj7YPeFEsTyXrT1KWMXj2sflouZo0Vuxd3ZsHTojvQDOnhWtPPxiis/tnz0I K5Ew== X-Gm-Message-State: ALoCoQkNsgihE9osd7/NmUIBl03uF1qFmqohO6IBfH7U7pZpo75IorXLi2X0rWK5eIPQ6vayinzP X-Received: by 10.55.23.86 with SMTP id i83mr98820139qkh.28.1426693717223; Wed, 18 Mar 2015 08:48:37 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:381:1ca7:409d:c366:febf? ([2601:a:2a00:381:1ca7:409d:c366:febf]) by mx.google.com with ESMTPSA id d135sm11121717qhc.7.2015.03.18.08.48.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 08:48:36 -0700 (PDT) Message-ID: <55099E57.6080008@nthpermutation.com> Date: Wed, 18 Mar 2015 11:48:39 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eric Rescorla References: <55086D3C.5090605@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000020400050109020306" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:48:41 -0000 This is a multi-part message in MIME format. --------------050000020400050109020306 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/17/2015 2:22 PM, Eric Rescorla wrote: > > > On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns > > wrote: > > Sorry for being pedantic but... > > The Nonce is the fixed (per connection) part of the quantity of > bits that are encrypted to produce one block of cipher text that's > XOR'd with the plain text to produce the encrypted message > block. The Nonce plus the message sequence number is the > per-message initialization vector. The Nonce plus the message > sequence number plus the block number is the per block value to be > encrypted. At least for CCM and GCM. > > The Nonce is common across all messages within a session. > (*sigh* the more general meaning of nonce is that of a unique > per-invocation value but given that all per-message/per-block > "nonce" usages contain the per-connection nonce it would be useful > to not overload this too much - among other reasons: an IV is not > always a nonce but can be, a nonce is not usually an IV but can > be, most messages require an IV, most blocks don't). So maybe we > call this the "Session Nonce" for clarity? > > > I realize that the terminology is confusing, but I'm using the terms > from RFC 5116 > section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this > context, the > nonce is not per-connection but rather per AEAD function invocation: > > A nonce N. Each nonce provided to distinct invocations of the > Authenticated Encryption operation MUST be distinct, for any > particular value of the key, unless each and every nonce is zero- > length. > > In this context, the AEAD function is invoked once for each TLS record > encryption. David used Nonce properly here, but it becomes confusing when taken to using the same key with multiple messages. Each message ALSO needs a Nonce - e.g. a unique value. But the other term for a per-message nonce is generally an IV. At the message level a nonce is always an IV but an IV isn't always a nonce. We form the per-message nonce (e.g. the IV) from the per-session nonce and the per-message sequence number and a fixed value. That's also the per-block nonce for the first block. So being clearer - using Session Nonce for the value that's the same with all messages and using IV (which is also a per-message Nonce for CCM and GCM and should be described as such) for the value used to initialize the per-message encryption/decryption/sign/verify would probably make things clearer rather than trying to figure out *which* Nonce we're talking about. > > So what you're proposing is to eliminate the determination of the > Nonce as part of the session negotiation and make it a fixed > value. E.g., we have an explicit nonce which is always zero which > produces a per-message IV based on the sequence number of '0's | > | . As a side effect that also > eliminates the per-message IV field (which aren't actually used by > the currently defined AEAD modes AFAICT). > > > AES-GCM uses this field, which is the motivation for this change. Yup. Forgot about that. Mainly because I thought implementers were interpreting the " The nonce_explicit MAY be the 64-bit sequence number." as if the GCMNonce package/explicit IV could be omitted. Didn't actually make sense not to do it that way. For this you're going to set the "SALT" to all zeroes instead of getting them from the IV field of the master secret expansion - correct? > > That works for the currently defined pure AEAD modes (CCM/GCM at > least, haven't looked at chacha). Will that work in all cases for > constructed AEAD modes? (e.g. where we build an AEAD mode out of > an encryption mode and an integrity mode and derive the E and I > keys from a single key internal to the constructed mode - say > AES-CBC with CMAC for example). Short answer is probably not. > > Basically, this complete eliminates the ability to use CBC (or any > cipher mode that requires an explicit per message IV) from TLS. > Not arguing for or against this at this point, but not clear that > everyone understands the side effects of this decision. > > > As discussed at the interim, I don't believe that this is correct. See > AGL's message > for a proposed construction. > Yup. > -Ekr > > > > Mike > > > > On 3/16/2015 7:54 PM, Eric Rescorla wrote: >> PR: https://github.com/tlswg/tls13-spec/pull/155 >> Target merge date: 3/21 >> >> Currently: >> >> - AES-GCM uses a partially explicit nonce >> - The ChaCha20 draft uses the sequence number as the nonce. >> >> As Stephen Kent has observed, the idea behind the explicit IV is >> to allow the >> cryptographic module implementing the AEAD algorithm to ensure >> non-reuse >> of the nonce. However, for ChaCha I believe we came to the >> conclusion that it >> was acceptable to use the sequence number as the nonce, as the >> module can >> check for sequential usage. This saves 8 octets on the wire. >> >> In the interim in Seattle, we came to the conclusion that we >> should make >> all AEAD algorithms behave this way, which also simplifies the >> spec some. >> I've formatted this into a PR to verify the consensus on the >> list. Please comment >> here if you object and on the PR if you have editorial comments. >> >> https://github.com/tlswg/tls13-spec/pull/155 >> >> -Ekr >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------050000020400050109020306 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/17/2015 2:22 PM, Eric Rescorla wrote:


On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Sorry for being pedantic but...

The Nonce is the fixed (per connection) part of the quantity of bits that are encrypted to produce one block of cipher text that's XOR'd with the plain text to produce the encrypted message block.   The Nonce plus the message sequence number is the per-message initialization vector.   The Nonce plus the message sequence number plus the block number is the per block value to be encrypted.   At least for CCM and GCM.

The Nonce is common across all messages within a session.   (*sigh* the more general meaning of nonce is that of a unique per-invocation value but given that all per-message/per-block "nonce" usages contain the per-connection nonce it would be useful to not overload this too much - among other reasons:  an IV is not always a nonce but can be, a nonce is not usually an IV but can be, most messages require an IV, most blocks don't).  So maybe we call this the "Session Nonce" for clarity?

I realize that the terminology is confusing, but I'm using the terms from RFC 5116
section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this context, the
nonce is not per-connection but rather per AEAD function invocation:

      A nonce N.  Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key, unless each and every nonce is zero-
      length.

In this context, the AEAD function is invoked once for each TLS record
encryption.

David used Nonce properly here, but it becomes confusing when taken to using the same key with multiple messages.


Each message ALSO needs a Nonce - e.g. a unique value.  But the other term for a per-message nonce is generally an IV.  At the message level a nonce is always an IV but an IV isn't always a nonce. 

We form the per-message nonce (e.g. the IV) from the per-session nonce and the per-message sequence number and a fixed value.  That's also the per-block nonce for the first block.


So being clearer - using Session Nonce for the value that's the same with all messages and using IV (which is also a per-message Nonce for CCM and GCM and should be described as such) for the value used to initialize the per-message encryption/decryption/sign/verify would probably make things clearer rather than trying to figure out *which* Nonce we're talking about.



 
So what you're proposing is to eliminate the determination of the Nonce as part of the session negotiation and make it a fixed value.  E.g., we have an explicit nonce which is always zero which produces a per-message IV based on the sequence number of '0's | <sequence counter> | <block counter>.  As a side effect that also eliminates the per-message IV field (which aren't actually used by the currently defined AEAD modes AFAICT).

AES-GCM uses this field, which is the motivation for this change.

Yup.  Forgot about that.  Mainly because I thought implementers were interpreting the "
The nonce_explicit MAY be the 64-bit sequence number." as if the GCMNonce package/explicit IV could be omitted.  Didn't actually make sense not to do it that way.

For this you're going to set the "SALT" to all zeroes instead of getting them from the IV field of the master secret expansion  - correct?

 
That works for the currently defined pure AEAD modes (CCM/GCM at least, haven't looked at chacha).   Will that work in all cases for constructed AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode and an integrity mode and derive the E and I keys from a single key internal to the constructed mode - say  AES-CBC with CMAC for example).  Short answer is probably not. 

Basically, this complete eliminates the ability to use CBC (or any cipher mode that requires an explicit per message IV) from TLS.  Not arguing for or against this at this point, but not clear that everyone understands the side effects of this decision.

As discussed at the interim, I don't believe that this is correct. See AGL's message
for a proposed construction.


Yup.

-Ekr



Mike



On 3/16/2015 7:54 PM, Eric Rescorla wrote:
Target merge date: 3/21

Currently:

- AES-GCM uses a partially explicit nonce
- The ChaCha20 draft uses the sequence number as the nonce.

As Stephen Kent has observed, the idea behind the explicit IV is to allow the
cryptographic module implementing the AEAD algorithm to ensure non-reuse
of the nonce. However, for ChaCha I believe we came to the conclusion that it
was acceptable to use the sequence number as the nonce, as the module can
check for sequential usage. This saves 8 octets on the wire.

In the interim in Seattle, we came to the conclusion that we should make
all AEAD algorithms behave this way, which also simplifies the spec some.
I've formatted this into a PR to verify the consensus on the list. Please comment
here if you object and on the PR if you have editorial comments.


-Ekr



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


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



--------------050000020400050109020306-- From nobody Wed Mar 18 08:59: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 2700B1A1B7A for ; Wed, 18 Mar 2015 08:59: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 FmF9jZl2nT2g for ; Wed, 18 Mar 2015 08:59:21 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.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 9F4AF1A1B13 for ; Wed, 18 Mar 2015 08:59:20 -0700 (PDT) Received: by weop45 with SMTP id p45so35951559weo.0 for ; Wed, 18 Mar 2015 08:59:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=20MI371EFPCjEi3Dr9g6GNagMpdXj5cMU4D+14TsncM=; b=EWIRXOEz64+8MTTWZ9hL9YAQELCyTJTAQaLTS9N+KcrXmeKNSerOW5tgNQ/yEXxFHI Zi9k2B9w5/cTklu58Z1fjz3zd1kvkbVGvHX0Xyl3s5Vl8HnR1E6UDzMZK7GJmLFeIxIv 3kqiyyZUnqgMIkBH2iEOlb1MdGRW1urEcuKDZFcmBJtkQyQ6bqMx5cLRR1VBYYI4LHTn 9GxKiyuoUg8fUXsoIhcf5Fk7JMyfLbvMk/Kpm1GVS6wH8rswW8nnmVBDo5H30IeuTlLe 4HPJiEhYaXUlWQ6hIwZmXPDIkQvrDm4aU2AwsxxhkVFoeQIkqk4QFbCjHuaVJHI7HbDo hPDg== X-Gm-Message-State: ALoCoQlQtTDpyeHs0HLeKjjNCdbPIqqrM+c7jJujjYwzy2VY+XZR6W1375rk/b8grX6bJT+Trah2 X-Received: by 10.180.106.68 with SMTP id gs4mr8058529wib.39.1426694359302; Wed, 18 Mar 2015 08:59:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 18 Mar 2015 08:58:39 -0700 (PDT) In-Reply-To: <55099E57.6080008@nthpermutation.com> References: <55086D3C.5090605@nthpermutation.com> <55099E57.6080008@nthpermutation.com> From: Eric Rescorla Date: Wed, 18 Mar 2015 08:58:39 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d04451a117d57f40511922a59 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:59:26 -0000 --f46d04451a117d57f40511922a59 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns wrote: > On 3/17/2015 2:22 PM, Eric Rescorla wrote: > > > > On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns > wrote: > >> Sorry for being pedantic but... >> >> The Nonce is the fixed (per connection) part of the quantity of bits that >> are encrypted to produce one block of cipher text that's XOR'd with the >> plain text to produce the encrypted message block. The Nonce plus the >> message sequence number is the per-message initialization vector. The >> Nonce plus the message sequence number plus the block number is the per >> block value to be encrypted. At least for CCM and GCM. >> >> The Nonce is common across all messages within a session. (*sigh* the >> more general meaning of nonce is that of a unique per-invocation value but >> given that all per-message/per-block "nonce" usages contain the >> per-connection nonce it would be useful to not overload this too much - >> among other reasons: an IV is not always a nonce but can be, a nonce is >> not usually an IV but can be, most messages require an IV, most blocks >> don't). So maybe we call this the "Session Nonce" for clarity? >> > > I realize that the terminology is confusing, but I'm using the terms > from RFC 5116 > section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this > context, the > nonce is not per-connection but rather per AEAD function invocation: > > A nonce N. Each nonce provided to distinct invocations of the > Authenticated Encryption operation MUST be distinct, for any > particular value of the key, unless each and every nonce is zero- > length. > > In this context, the AEAD function is invoked once for each TLS record > encryption. > > > David used Nonce properly here, but it becomes confusing when taken to > using the same key with multiple messages. > > > Each message ALSO needs a Nonce - e.g. a unique value. But the other term > for a per-message nonce is generally an IV. At the message level a nonce > is always an IV but an IV isn't always a nonce. > The term in RFC 5116 uses for this input is "nonce". I don't think it's helpful to use a different term here than is used in RFC 5116. Please note that all the ciphers here need to conform to the RFC5116 interface, so whatever the individual ciphers call their nonce inputs is not relevant here. We form the per-message nonce (e.g. the IV) from the per-session nonce and > the per-message sequence number and a fixed value. That's also the > per-block nonce for the first block. > In this PR there is no fixed value. We simply use the sequence number and pad to the left as required, so I don't think there should be much room for confusion. -Ekr --f46d04451a117d57f40511922a59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 3/17/2015 2:22 PM, Eric Rescorla wrote:


On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Sorry for being pedantic but...

The Nonce is the fixed (per connection) part of the quantity of bits that are encrypted to produce one block of cipher text that's XOR'd with the plain = text to produce the encrypted message block.=C2=A0=C2=A0 The N= once plus the message sequence number is the per-message initialization vector.=C2=A0=C2=A0 The Nonce plus the mes= sage sequence number plus the block number is the per block value to be encrypted.=C2=A0=C2=A0 At least for CCM and G= CM.

The Nonce is common across all messages within a session.=C2=A0=C2=A0 (*sigh* the more general meaning of = nonce is that of a unique per-invocation value but given that all per-message/per-block "nonce" usages c= ontain the per-connection nonce it would be useful to not overload this too much - among other reasons:=C2=A0 an IV is not always a nonce but can be, a nonce is not usually an IV but can be, most messages require an IV, most blocks don't).=C2=A0 So maybe we call this the "Session Nonce" for clarity?

I realize that the terminology is confusing, but I'm using the terms from RFC 5116
section 2.1 (https://tools.ietf.org/html/rfc5116#sectio= n-2.1). In this context, the
nonce is not per-connection but rather per AEAD function invocation:

=C2=A0 =C2=A0 =C2=A0 A nonce N.=C2=A0 Each nonce provided = to distinct invocations of the
=C2=A0 =C2=A0 =C2=A0 Authenticated Encryption operation MU= ST be distinct, for any
=C2=A0 =C2=A0 =C2=A0 particular value of the key, unless e= ach and every nonce is zero-
=C2=A0 =C2=A0 =C2=A0 length.

In this context, the AEAD function is invoked once for each TLS record
encryption.

 David used Nonce properly here, but it becomes confusing when taken to using the same key with multiple messages.


Each message ALSO needs a Nonce - e.g. a unique value.=C2=A0 But the other term for a per-message nonce is generally an IV.=C2=A0 At the message level a nonce is always an IV but an IV isn't always a nonce.=C2=A0

The term in RFC= 5116 uses for this input is "nonce". I don't think it's = helpful
to use a different term here than is used in RFC 5116. Pl= ease note that
all the ciphers here need to conform to the RFC511= 6 interface, so whatever
the individual ciphers call their nonce = inputs is not relevant here.


We form the per-message nonce (e.g. the IV) from the per-session nonce and the per-message sequence number and a fixed value.=C2=A0 That= 's also the per-block nonce for the first block.

In this PR there is no fixed value. We simply use the sequ= ence number and pad to
the left as required, so I don't think= there should be much room for confusion.

-Ekr

--f46d04451a117d57f40511922a59-- From nobody Wed Mar 18 10:42: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 6F3F61A879A for ; Wed, 18 Mar 2015 10:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9sN0NEV_Whb for ; Wed, 18 Mar 2015 10:42:22 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 0C3E11A1B5E for ; Wed, 18 Mar 2015 10:42:22 -0700 (PDT) Received: by lagg8 with SMTP id g8so42359917lag.1 for ; Wed, 18 Mar 2015 10:42:20 -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 :content-transfer-encoding; bh=0VQV6egmI3NJCW7725KJs2VMrg25lGRmG3DUuNIOx6o=; b=rOWvvvq6MM1gClIMqEff9jrrXBxh3OE2UGd08mOI9fLm1KInxOQ1dCBAcw+oC2yiC5 RMCDnC3YzIn4uolU1LoxDAc8Krr0zOQGYAkmGvCDLvspSjbYNRSonnMSjQW1aJH83+vX DRdWn2LxfdZOyj5Ta6Ndbj5tabXhMccb6nsK7SOrIXcXYbCCP3JH1dp2tigAKa57EnI3 JJQ+JdKsrx1lUREOdUKtfvKksdEiSElHHr5xTa1OWivGwbJmUwS47aSoYqeL0laiKphc 1OnLbIX5+1L/FcLTrUPU0Il/nCzKguddi8Q05wGiWXVNI9LLrAI4t06GtKsYDad7vhZ5 F7VA== MIME-Version: 1.0 X-Received: by 10.112.154.3 with SMTP id vk3mr33716451lbb.26.1426700540401; Wed, 18 Mar 2015 10:42:20 -0700 (PDT) Received: by 10.112.204.5 with HTTP; Wed, 18 Mar 2015 10:42:20 -0700 (PDT) Date: Wed, 18 Mar 2015 18:42:20 +0100 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Handshake padding in TLS 1.3 (PR #147) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 17:42:23 -0000 Hi. I've taken a look at the feasibility of adding handshake padding as currently drafted in PR #147 to my implementation of TLS 1.3. >From the PR draft: > handshake_messages > > : All of the data from all messages in this handshake up to, but not incl= uding, > this message. This is only data visible at the handshake layer and does n= ot > include record layer headers. For encrypted handshake records, the hash > includes the two bytes specifying the length of the padding, as well as a= ny > padding present. handshake_messages is the concatenation of all the > Handshake structures as defined in {{handshake-protocol}}, exchanged thus > far. {:br } The above seems to assume that packet breaks (ie the places where padding is inserted) and handshake message breaks align. This is not true in the general case, and the above is a protocol layering violation. The problem shows up clearly if you have distinct layers of code for handling coalescing (and apparently padding) of packets and the handling of handshake messages, and the higher layer is about to send a Finished message; to be able to calculate the payload for the packet, it needs to know in advance where the lower layer will break the packets, and what padding it will insert as this will affect the handshake_messages hash. The recipient also runs into trouble, as it can no longer just add all handshake packet payloads to a buffer from which it extracts a message at a time, as it also needs to keep track of any padding (which may appear in the middle of messages). Adding such complexity is likely to frustrate implementators and lead to even buggier implementations. I believe that the easiest way to reduce the complexity while still retaining the features of padding, would be to move the padding from the handshake packet layer to the handshake message layer. Ie introduce a handshake_padding message (allocated from HandshakeType) which may be sent at any point in the handshake, and which only affects the handshake_messages hash. This would be trivial to implement on the recipient side, have no overhead if padding isn't used, and be reasonably simple to implement on the sender side. The down side is that the minimum padding would be 4 bytes and not 2. /grubba --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Wed Mar 18 11:16: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 D3B5C1A9022 for ; Wed, 18 Mar 2015 11:16:03 -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 L2ylrdbfMQF9 for ; Wed, 18 Mar 2015 11:16:02 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (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 2B6DC1A878A for ; Wed, 18 Mar 2015 11:16:02 -0700 (PDT) Received: by wggv3 with SMTP id v3so42358953wgg.1 for ; Wed, 18 Mar 2015 11:16:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=dIaVT6AB8tb1Ikd3KVAqgn1ZmiUCIxIoinBOlMx3vY8=; b=Vf084ZXIFemZU/fyWsLTxWt8MWQHADgR02J9YbFkJ0U2bzfRnGXe83nJFCr2phbTO/ cceFKHCXjhqWsHf4XyYYWb4SZys7ND9dWovgkD5yISULf1XWcc8i/hFOEzZSv8/7ep0s BLIP/v1+GXX0wHUZxLngAh6fAZ1SUeJ7/TBXuXMgqCn+/T9xlw/vJd1XHNAvYl4xH4vJ x9ScU2SATaPvRPR0CiRpGCpJ3zqVMoEdyXXMNtKU0yDgmKqDfFYpaBLR3Zk7Pt7E21wb oOP0DaikJVv4bsFclGiCluGyfQEBgaJLsRdYanut8nUpvkzL/iqvoZUETRcIg7XHcwxH NKCg== X-Gm-Message-State: ALoCoQkFE3ilt09JC/EiYHkzT6hjVJWR5uQDSXKosxDSWpjKOPDD4dKSwyWmf7aWGA18qFgvG8Xn X-Received: by 10.180.79.232 with SMTP id m8mr9237607wix.81.1426702560825; Wed, 18 Mar 2015 11:16:00 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id ps4sm25510409wjc.31.2015.03.18.11.15.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 11:15:59 -0700 (PDT) Message-ID: <5509C0DB.3000105@azet.org> Date: Wed, 18 Mar 2015 19:15:55 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Sean Turner References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> In-Reply-To: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig5808BCE1885CFA59BD08A99C" Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:16:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5808BCE1885CFA59BD08A99C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Sean Turner wrote: >=20 > o Signature: > MUST ECDSA P-256 > MUST RSA >=20 Was there any discussion on adding [EdDSA]? Thanks, Aaron --------------enig5808BCE1885CFA59BD08A99C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCcDcAAoJEOTbZJL9ubXV9rcP/RVAkEh7V+SpA9AYYMUj05LD 6XTeNObiIhLZnXrs0OPAJJdyLOwx0ZfRiZpHyFcByIqzobXesea95Cvu3lpUPscu cU2JO8e29BNp4SyAwgHUcgF9vW7bodZQ6dskT7OxxWfH2k6U4Px+RMsTvqcfGtKj zqHwuz99nGwBn8TLGDGqxGsGrucrS3GswNe4HDG4fb2P2SyChn6mO9mLr+gHa2cl XNdHgK6xU+zQ9EBCpYW30ys2a3rFyyOCe5tCGs2i0aTeHMcdAoNgGK/Z5Uoh9dyT BKn5JnBe3nSsqnH7x7zuFORU4Z97plkiS4E9qLxURNA7sFuveUFl7ie3YvlXukGE hbRLIgG5dzRKnqdIqHtrJZNGFy3/DOfauXNRdMgGWhrnxfN3BerLvW+kPub/TNRj zDAHuV0PeRV8FA7Wxes5tuM+WslFcJZlpTZ7h2i8rUy0AXVSzpCG9FAHtiO6/kSr oKNF0caRopA6RrpnI2QI+kdMSYwwzrSfkqsuEU5pJGvdjSzbfr8MItw8EHsun/sA bTnmc3yrTxho4H8ddzZ8HqcoNeMrln3TU3S+7uFLDloTS0On0+piTo93jeOl47mT UAAkCTPvLB6d9WQV7yr6+Jju525+182xhxLl79WIraOAOVR0kA+RQ5JhGtXVt9LZ cFwIjxWSdow2nj2Pu7g9 =BQfm -----END PGP SIGNATURE----- --------------enig5808BCE1885CFA59BD08A99C-- From nobody Wed Mar 18 11:20: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 002501A9037 for ; Wed, 18 Mar 2015 11:20: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 pzsQ31LRHGsT for ; Wed, 18 Mar 2015 11:20:13 -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 643E31A9042 for ; Wed, 18 Mar 2015 11:20:13 -0700 (PDT) Received: by wixw10 with SMTP id w10so47383224wix.0 for ; Wed, 18 Mar 2015 11:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3WC/2v1bpL+gOhgfudDmqQ8El+orXJ4GCMAPG8LVVLw=; b=g5SZioyLIsp6IqCmKwB8BBNjWMq/8bhazEGBeO2m5l15P8zmLvSyWDUnuNEQS4KBKx poR3GYkbI6guER6bDYco9o72O2HkeSWHiHs5XuoIiP2vSsHSPx26GsQFbZ/VEcbRYp4q KuORswfmTUy7bcbeuqsHmRBUnBetVcHQ62+bnHqhBTnrt1lMjUE0iezfCrKlDoYjiHta FG0JPIGO9hDjoAR6r1H9e8dOvf9JXfiy6KjTXQrk1xCeBon9qVTPSw1xPuGzM1xYndnM KHh5hcgcPGjy4fpYKTty4ubm11zYbjq3HYhaiR95iiM8PH/O8aKmzHFbDwchf+RUZuwp +dwg== X-Gm-Message-State: ALoCoQlG3/0UO8UpOIaGDlIOuAx6nB+An7a3VE5SylsqPVH0JGI7gdfuZQ8gzyPb61dGtMs9G0XS X-Received: by 10.194.191.228 with SMTP id hb4mr147582081wjc.116.1426702812122; Wed, 18 Mar 2015 11:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 18 Mar 2015 11:19:31 -0700 (PDT) In-Reply-To: <5509C0DB.3000105@azet.org> References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <5509C0DB.3000105@azet.org> From: Eric Rescorla Date: Wed, 18 Mar 2015 11:19:31 -0700 Message-ID: To: Aaron Zauner Content-Type: multipart/alternative; boundary=047d7b8750be51406c0511942253 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:20:17 -0000 --047d7b8750be51406c0511942253 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 11:15 AM, Aaron Zauner wrote: > Hi, > > Sean Turner wrote: > > > > o Signature: > > MUST ECDSA P-256 > > MUST RSA > > > > Was there any discussion on adding [EdDSA]? My understanding is that CFRG hasn't even really taken signatures yet, so the feeling was that even discussing it was premature. -Ekr --047d7b8750be51406c0511942253 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2015 at 11:15 AM, Aaron Zauner <azet@azet.org> wrote:
Hi,

Sean Turner wrote:
>
> o Signature:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST ECDSA P-256
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST RSA
>

Was there any discussion on adding [EdDSA]?

My understanding is that CFRG hasn't even really taken signatur= es yet,
so the feeling was that even discussing it was premature.=

-Ekr

--047d7b8750be51406c0511942253-- From nobody Wed Mar 18 11:29: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 BD2A71A9042 for ; Wed, 18 Mar 2015 11:29:45 -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 QP8hzbVH3BR6 for ; Wed, 18 Mar 2015 11:29:44 -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 A6BC11A9040 for ; Wed, 18 Mar 2015 11:29:44 -0700 (PDT) Received: by wibg7 with SMTP id g7so97681489wib.1 for ; Wed, 18 Mar 2015 11:29: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=6sjymZLrv2IzLL0IkOlm9D2VMXbSMIB+l+kx/4eu/rE=; b=FB2Vr/tjGSXsl9NKxY/xRYglkCTes7CzYywh+nywlUkmymCkF4sw6eQWbSoFYJTYB7 9MLdoE0d5Lk3b1bJx1GBjzWLaa+x9MNhfbfQEVLXuW567BlEVFlEShhAoZ0lTV4QJFuT 7/0n9i85cheRDZRtHNqNRr7Dqsyfmg7FgQzxo04dZDcsxK54f/lElQoqQo8r1Pg0w1Gq EpR8IcMpEk2CTammoV4gT3SpKF3WgypO9M807cWeL/M0nWLWeyCO7J/fosDFwXcEwO2W cHMMGNMaRUb8b+vXxIewim+fYiZzZFKc08vlTn0uRRYcR6Eih2MpRFdFgCAYm0Rnqumb S1lA== X-Gm-Message-State: ALoCoQlIXNItThZIzZzFiGO8hZcX6FpsZJnbsP2XW5MQes7xTl8KKB20Mcmkgup5FuEzwd6SYmUA X-Received: by 10.194.222.197 with SMTP id qo5mr142451613wjc.142.1426703383289; Wed, 18 Mar 2015 11:29:43 -0700 (PDT) Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id l6sm25555089wjx.33.2015.03.18.11.29.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 11:29:42 -0700 (PDT) Message-ID: <5509C412.2090909@azet.org> Date: Wed, 18 Mar 2015 19:29:38 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Eric Rescorla References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <5509C0DB.3000105@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBA0C2184840BBA0EB11339A0" Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:29:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBA0C2184840BBA0EB11339A0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Eric Rescorla wrote: >=20 > My understanding is that CFRG hasn't even really taken signatures yet, > so the feeling was that even discussing it was premature. >=20 Correct. It came up a couple of times recently, but I don't see CFRG recommending a specific signature scheme very soon as well. Thanks for the update. Aaron --------------enigBA0C2184840BBA0EB11339A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCcQTAAoJEOTbZJL9ubXVjHsQAKdGKZa+RVnsSN2BuLWauIv4 qo3NINmCD5unRYyJr9rASQZ7w40ctY8hqRU/hTAoYwssBmmFT51WF70NaaJ1tk5T dKjkLmKfjurR8gaJ6LlvDjVHQA2O/D6Uu/Kt+pp1d+I2n7+2I33ibeUdEv9JbeVi xk9SyCar2YgvoO+659U+/DH0SjgDLuUw59H72LLC1Bm4LZ9GDkE3aVC9QwvZrugM ZJ/bpxYD83yv3fctgWZuGdjWCQLXY211ZqcRW5GXnJbqs4KzH0V/CPUOxAjudiIq rG6KyGu0oDYk1hIh/V+MAHaGvsF0RWiDkiA1m9KifInY/2vH5CvrEgcma9FXVGBt EqcqzbMJ0zSAJ90Thcxy8P3mAfTcbuU/8OOWbF+QZCInx/BQj22AGIojnKajxa9L eynYw1H2BKuE1ZSnYxTOEHgrRgo9VzF4UJjfX4E1yit1WoIumXhrr4SC3PW/Q00x mreaTuJIVpmqrnP/DnWvVm+0BNhwD5XvnYzVli6MemxOvty2QfOilykP84FnSye8 nKy52xt7+YXbgkTU/o7qHEjez/qocSehJ9kX8FhyZa7htPp7xVIxNi9owcdW+6NG S0eaNVxrykBzkzpd13MT1vgaixNIoVeS/L50+x8yyOfgb1i92Goge1xy+t6/xFem bB2ny7LioZn8Kb8EARLU =HWl9 -----END PGP SIGNATURE----- --------------enigBA0C2184840BBA0EB11339A0-- From nobody Wed Mar 18 14:06: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 4FFC71A9125 for ; Wed, 18 Mar 2015 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM0PYfRmo9Ve for ; Wed, 18 Mar 2015 14:06:07 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (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 8DD5C1A90CD for ; Wed, 18 Mar 2015 14:06:06 -0700 (PDT) Received: by webcq43 with SMTP id cq43so42144259web.2 for ; Wed, 18 Mar 2015 14:06:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qX4iDmyUHk6lLREyTpmlkBY2F7aVgvfXD9ww2fUmgqE=; b=YVRyebE5PgnJeu4dM1ZHqxfVCv2iIfWPOKDzpbdCpr9eSiu0cud/j+9c6RwS+ZRs/B CRaMbfoEEaSV0It25osScSJ0xtBUgnM77qtj+rO5EU2sv7YZodX42JVNzsuUOGAoCsKC pIu6RXyPXutLxtBIGdrGrUHU5jKpeowj8rpzvnVXIFJbZ5LcEPeHGb2qlLX+5aENUG5x G0z0UrRpiOWbOz5RlRHrVceiLaqyIxJe7rKW1vmFCLPF8HPKxhwegcTSYD9kHkFDOdWJ Z3Be11Y1fE17gC8h0Y40ayxa9wx7DaHX9BMZ4A6WN8vAlQ4vCxoDHCe+Ke6t1jOn4sHn aXQw== X-Gm-Message-State: ALoCoQlhG3sN4aQlZ2IzueJtjgEYfbrzGSHEhvwVSPKeouIDUjoNbq3HFDu9H7R1v4isgQYmbAaB X-Received: by 10.180.98.67 with SMTP id eg3mr10476236wib.11.1426712765306; Wed, 18 Mar 2015 14:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 18 Mar 2015 14:05:25 -0700 (PDT) In-Reply-To: <55094150.2010800@comodo.com> References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> <55094150.2010800@comodo.com> From: Eric Rescorla Date: Wed, 18 Mar 2015 14:05:25 -0700 Message-ID: To: Rob Stradling Content-Type: multipart/alternative; boundary=f46d0444025492aeb005119673eb Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 21:06:09 -0000 --f46d0444025492aeb005119673eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 18, 2015 at 2:11 AM, Rob Stradling wrote: > On 18/03/15 07:38, Yoav Nir wrote: > >> On Mar 18, 2015, at 12:11 AM, Sean Turner wrote: >>> >> > >> Please note that CFRG is already done with ChaCha20-Poly1305. The >> document is approved and in the RFC Editor=E2=80=99s queue. >> >> The ball is not in this working group=E2=80=99s court. It=E2=80=99s time= to decide about >> draft-mavrogiannopoulos-chacha-tls. > > I await the chair's action on this. In the meantime, I see that we have developed a conflict between this draft and https://github.com/tlswg/tls13-spec/pull/155 Because this PR prescribes a specific mechanism for generating the nonce (left-padding the record sequence number) which conflicts with the one for this draft. Assuming that people feel that the approach we arrived at in the interim is appropriate, we will probably want to adjust this draft prio= r to acceptance. -Ekr Yoav, > > s/not/now/ > > ? > > Yoav >> >> http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0444025492aeb005119673eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 18, 2015 at 2:11 AM, Rob Stradling <rob.stradling@comod= o.com> wrote:
On 18/03/1= 5 07:38, Yoav Nir wrote:
On Mar 18, 2015, at 12:11 AM, Sean Turner <TurnerS@ieca.com> wrote:
 <snip>
Please note that CFRG is already done with ChaCha20-Poly1305. The document = is approved and in the RFC Editor=E2=80=99s queue.

The ball is not in this working group=E2=80=99s court. It=E2=80=99s time to= decide about draft-mavrogiannopoulos-chacha-tls.

I await the chair's action on this.

In the meantime, I see that we have developed a con= flict between this draft and


Because this PR prescribes a specific me= chanism for generating the nonce
(left-padding the record sequenc= e number) which conflicts with the one for
this draft. Assuming t= hat people feel that the approach we arrived at in
the interim is= appropriate, we will probably want to adjust this draft prior
to= acceptance.

-Ekr

Yoav,

s/not/now/

?

Yoav

http://tools.ietf.org/html/draft-mavrogiannopoul= os-chacha-tls-04

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


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

--f46d0444025492aeb005119673eb-- From nobody Wed Mar 18 15:37: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 632C01A8905 for ; Wed, 18 Mar 2015 15:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNO8vnUWVPL8 for ; Wed, 18 Mar 2015 15:36:57 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 BE0F11A8904 for ; Wed, 18 Mar 2015 15:36:56 -0700 (PDT) Received: by qgfa8 with SMTP id a8so50985687qgf.0 for ; Wed, 18 Mar 2015 15:36:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=kIANId1lnyzz1KR+hhzUOVETs/MKkH3zoOuYTQn0WJ0=; b=fKUtZS1irH9MPgRrCVrPWXCwfxtN0D/BSe1BNvsDoOmv5V4JPrvEyJLmboHHf+aVqJ PqCecqeE+lYNMwnqoW7zI08b0vv0fpBBK/RNYj/+Y9RCN4PU2qZaiMVoUaBVdEwr7UEh Xxdht2nKs88WId+z6dLD/IATyDujkKpojjm4R0A2KnxWFbnx//5yhpeHeNM9t5vAA/vu i/+OWzZs5/i5D2+/5vwXafXftoLqyxX2bEOmI8pvqnDfQu65hpeX784Xosov0FGCWImc 3B23EEvH5h1Xj/CBs7XneCjeiiOuD51odVlVdOILW53XM+74Wrj2IbZ2tGCzUqjZSmuN RRzw== X-Gm-Message-State: ALoCoQkT/bk0Vodxx3JKDkfwH8vind3BnN3GAlVv7HPklxq/2YP9cFJaMA9n5br51FDfqi3ytRw2 X-Received: by 10.229.80.3 with SMTP id r3mr91730880qck.23.1426718215958; Wed, 18 Mar 2015 15:36:55 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:381:1ca7:409d:c366:febf? ([2601:a:2a00:381:1ca7:409d:c366:febf]) by mx.google.com with ESMTPSA id 9sm12812841qgo.38.2015.03.18.15.36.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Mar 2015 15:36:55 -0700 (PDT) Message-ID: <5509FE0A.4060903@nthpermutation.com> Date: Wed, 18 Mar 2015 18:36:58 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eric Rescorla References: <55086D3C.5090605@nthpermutation.com> <55099E57.6080008@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070007060708080001060901" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 22:37:01 -0000 This is a multi-part message in MIME format. --------------070007060708080001060901 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/18/2015 11:58 AM, Eric Rescorla wrote: > > > On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns > > wrote: > > > > David used Nonce properly here, but it becomes confusing when > taken to using the same key with multiple messages. > > > Each message ALSO needs a Nonce - e.g. a unique value. But the > other term for a per-message nonce is generally an IV. At the > message level a nonce is always an IV but an IV isn't always a nonce. > > > The term in RFC 5116 uses for this input is "nonce". I don't think > it's helpful > to use a different term here than is used in RFC 5116. Please note that > all the ciphers here need to conform to the RFC5116 interface, so whatever > the individual ciphers call their nonce inputs is not relevant here. David used David's language for 5116. It's instructive to note Russ's language in the CCM RFC matches what ended up in the NIST version, but that David's language in his GCM RFC didn't match what ended up in the document he sent proposing GCM to NIST nor what NIST finally published as the mode. I'm not sure why that is. From David's GCM submission: > The primary purpose of the IV is to be a nonce, that is, to be > distinct for each invocation of the encryption operation for a fixed key. Then there's the mixture of the IV with the salt to form a nonce in the GCM IPSEC document that's yet another different way of putting it. If you say "IV" or Initialization Vector - I know that's the value I need to begin encryption or decryption of a message. If you say Nonce, I have no idea of whether its an IV, a value mixed in to indicate timeliness (e.g. a challenge nonce), a per-session/per-sender nonce that's used as part of the IV to allow the same key to be used by multiple senders or what. Ah well.... > > > We form the per-message nonce (e.g. the IV) from the per-session > nonce and the per-message sequence number and a fixed value. > That's also the per-block nonce for the first block. > > > In this PR there is no fixed value. We simply use the sequence number > and pad to > the left as required, so I don't think there should be much room for > confusion. This is kind of sophistry. Padding to the left is exactly equivalent to "fixed nonce of zeros". > > -Ekr > --------------070007060708080001060901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/18/2015 11:58 AM, Eric Rescorla wrote:


On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns <msj@nthpermutation.com> wrote:


 David used Nonce properly here, but it becomes confusing when taken to using the same key with multiple messages.


Each message ALSO needs a Nonce - e.g. a unique value.  But the other term for a per-message nonce is generally an IV.  At the message level a nonce is always an IV but an IV isn't always a nonce. 

The term in RFC 5116 uses for this input is "nonce". I don't think it's helpful
to use a different term here than is used in RFC 5116. Please note that
all the ciphers here need to conform to the RFC5116 interface, so whatever
the individual ciphers call their nonce inputs is not relevant here.

David used David's language for 5116.  It's instructive to note Russ's language in the CCM RFC matches what ended up in the NIST version, but that David's language in his GCM RFC didn't match what ended up in the  document he sent proposing GCM to NIST nor what NIST finally published as the mode.  I'm not sure why that is.   From David's GCM submission:

The primary purpose of the IV is to be a nonce, that is, to be distinct for each invocation of the encryption operation for a fixed key.

Then there's the mixture of the IV with the salt to form a nonce in the GCM IPSEC document that's yet another different way of putting it.

If you say "IV" or Initialization Vector - I know that's the value I need to begin encryption or decryption of a message.  If you say Nonce, I have no idea of whether its an IV, a value mixed in to indicate timeliness (e.g. a challenge nonce), a per-session/per-sender nonce that's used as part of the IV to allow the same key to be used by multiple senders or what.

Ah well....




We form the per-message nonce (e.g. the IV) from the per-session nonce and the per-message sequence number and a fixed value.  That's also the per-block nonce for the first block.

In this PR there is no fixed value. We simply use the sequence number and pad to
the left as required, so I don't think there should be much room for confusion.

This is kind of sophistry.  Padding to the left is exactly equivalent to "fixed nonce of zeros".


-Ekr


--------------070007060708080001060901-- From nobody Wed Mar 18 15:40: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 199411A8913 for ; Wed, 18 Mar 2015 15:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G7-dtcyzurM for ; Wed, 18 Mar 2015 15:40:08 -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 A00801A8905 for ; Wed, 18 Mar 2015 15:40:07 -0700 (PDT) Received: by wixw10 with SMTP id w10so71432502wix.0 for ; Wed, 18 Mar 2015 15:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YZ6OUjdHeqCRb97e58YXhmCb/M65gcP0/oMbxBnmHwo=; b=cfqD8vWs+Uep8e2EvKtDWEBdCICCRfqP2sQXqEnkvmjofsswXLz3McoGyRMlNB8ZWl CRrH/Q2m0B9yllqcLwOtY+6xbk8b+Lt3F3h5Jqgu7rYtgj93qfHLKzrI3pQ2iJEnNVHr U1J1WU9FvKywitZAeS7yravMmegyWO80H9TvaM7VdEi9RbZjaLNuuSLUvFwmbxMx4iqD jKZKPAZITCS03QaMKXiQFESTnmtheHf1bLjxRZCgkby5bZDdUH5I+k9IbTeHECQgzE7N seOwRQPCWs1Tyau842V15Rorgdrl97EoD8j40/mGJ6WnIcegYCqqNjDmg2jXAaT7q6/U ULaQ== X-Gm-Message-State: ALoCoQmaF89RlXKGLTETYipr5tHteusyaY6mS0FzGhcwAuMKRVOxXPFWx8LLKAeSEROqGvP/nXGl X-Received: by 10.194.235.71 with SMTP id uk7mr148007758wjc.13.1426718406172; Wed, 18 Mar 2015 15:40:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 18 Mar 2015 15:39:25 -0700 (PDT) In-Reply-To: <5509FE0A.4060903@nthpermutation.com> References: <55086D3C.5090605@nthpermutation.com> <55099E57.6080008@nthpermutation.com> <5509FE0A.4060903@nthpermutation.com> From: Eric Rescorla Date: Wed, 18 Mar 2015 15:39:25 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=089e01493afacb7bb5051197c327 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 22:40:09 -0000 --089e01493afacb7bb5051197c327 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 18, 2015 at 3:36 PM, Michael StJohns wrote: > On 3/18/2015 11:58 AM, Eric Rescorla wrote: > > > > On Wed, Mar 18, 2015 at 8:48 AM, Michael StJohns > wrote: > >> >> >> David used Nonce properly here, but it becomes confusing when taken to >> using the same key with multiple messages. >> >> >> Each message ALSO needs a Nonce - e.g. a unique value. But the other >> term for a per-message nonce is generally an IV. At the message level a >> nonce is always an IV but an IV isn't always a nonce. >> > > The term in RFC 5116 uses for this input is "nonce". I don't think it's > helpful > to use a different term here than is used in RFC 5116. Please note that > all the ciphers here need to conform to the RFC5116 interface, so whatever > the individual ciphers call their nonce inputs is not relevant here. > > > David used David's language for 5116. > Perhaps, but this is the document we are normatively referencing for AEAD. -Ekr --089e01493afacb7bb5051197c327 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2015 at 3:36 PM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
On 3/18/2015 11:58 AM, Eric Rescorla wrote:


On Wed, Mar 18, 2015 = at 8:48 AM, Michael StJohns <msj@nthpermutation.com> wrote:


 David used Nonce properly here, but it becomes confusing when taken to using the same key with multiple messages.


Each message ALSO needs a Nonce - e.g. a unique value.=C2= =A0 But the other term for a per-message nonce is generally an IV.=C2=A0 At the message level a nonce is always an IV b= ut an IV isn't always a nonce.=C2=A0

The term in RFC 5116 uses for this input is "nonce&qu= ot;. I don't think it's helpful
to use a different term here than is used in RFC 5116. Please note that
all the ciphers here need to conform to the RFC5116 interface, so whatever
the individual ciphers call their nonce inputs is not relevant here.

David used David's language for 5116.

Perhaps, but this is the document we are normatively referencing f= or AEAD.

-Ekr

--089e01493afacb7bb5051197c327-- From nobody Wed Mar 18 15:56: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 937CF1A8925 for ; Wed, 18 Mar 2015 15:56:04 -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 mqRzpc50ZR8q for ; Wed, 18 Mar 2015 15:56:02 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::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 637671A8908 for ; Wed, 18 Mar 2015 15:56:02 -0700 (PDT) Received: by wggv3 with SMTP id v3so47674409wgg.1 for ; Wed, 18 Mar 2015 15:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pZtOt9ZaeEJ3mnxhW/JtgSdXs1mfBlGJiPtlY3necHw=; b=GFvcxjg83iP8LvXXu8rltHAxecm4VBZPPvzfRKJPulB03a5U9na0HqNwDMjmYr6KyP e0VXeh325xLGdkXXrhCtQPgmtRl1kN6vDRE8EcyNSOc+6/xyCex91U4qMd6+W2Pdx9mY 2T4ZNV57c8Yxq7kah3rvd7vm/gJFoinoOKwS5cKt6nLP23svxnCONV03ZNSuNgBkgYyw Yh5KDWcfdYW2S87R0MPNHRDpd/e/kawyxr6kcpUl08tuY71dEiOiK9E0VRS/4vhvTO+/ yk28bb7R0JHk7ERYyKmVeKg9ux7owERQnD8EQ5aBGVo21tk1TFIIxmKbj+vr50RrLn6k GctQ== X-Received: by 10.180.102.130 with SMTP id fo2mr11025997wib.30.1426719361150; Wed, 18 Mar 2015 15:56:01 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id e18sm26340040wjz.27.2015.03.18.15.55.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 15:56:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1015C41E-111D-49D8-AE7B-B27602DC46D2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 19 Mar 2015 00:55:58 +0200 Message-Id: References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> <55094150.2010800@comodo.com> To: Eric Rescorla X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 22:56:04 -0000 --Apple-Mail=_1015C41E-111D-49D8-AE7B-B27602DC46D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 18, 2015, at 11:05 PM, Eric Rescorla wrote: >=20 >=20 > On Wed, Mar 18, 2015 at 2:11 AM, Rob Stradling = > wrote: > On 18/03/15 07:38, Yoav Nir wrote: > On Mar 18, 2015, at 12:11 AM, Sean Turner > wrote: > > Please note that CFRG is already done with ChaCha20-Poly1305. The = document is approved and in the RFC Editor=E2=80=99s queue. >=20 > The ball is not in this working group=E2=80=99s court. It=E2=80=99s = time to decide about draft-mavrogiannopoulos-chacha-tls. >=20 > I await the chair's action on this. >=20 > In the meantime, I see that we have developed a conflict between this = draft and >=20 > https://github.com/tlswg/tls13-spec/pull/155 = >=20 > Because this PR prescribes a specific mechanism for generating the = nonce > (left-padding the record sequence number) which conflicts with the one = for > this draft. Assuming that people feel that the approach we arrived at = in > the interim is appropriate, we will probably want to adjust this draft = prior > to acceptance. The draft is suitable for TLS 1.2 as well, so I=E2=80=99m not sure it = needs to comply with the nonce generation procedure of TLS 1.3. It=E2=80=99= s better for it to be like other AEADs such as AES-GCM, and then get = adapted to TLS 1.3 just like AES-GCM. Yoav --Apple-Mail=_1015C41E-111D-49D8-AE7B-B27602DC46D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 18, 2015, at 11:05 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Wed, Mar 18, 2015 at 2:11 AM, Rob = Stradling <rob.stradling@comodo.com> wrote:
On 18/03/15 07:38, Yoav Nir wrote:
On Mar 18, 2015, at 12:11 = AM, Sean Turner <TurnerS@ieca.com> wrote:
<snip>
Please note that CFRG is already done with = ChaCha20-Poly1305. The document is approved and in the RFC Editor=E2=80=99= s queue.

The ball is not in this working = group=E2=80=99s court. It=E2=80=99s time to decide about = draft-mavrogiannopoulos-chacha-tls.

I await the chair's = action on this.

In the meantime, I see that we have developed a = conflict between this draft and

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

Because this PR = prescribes a specific mechanism for generating the nonce
(left-padding the = record sequence number) which conflicts with the one for
this draft. Assuming = that people feel that the approach we arrived at in
the interim is = appropriate, we will probably want to adjust this draft prior
to = acceptance.

The draft = is suitable for TLS 1.2 as well, so I=E2=80=99m not sure it needs to = comply with the nonce generation procedure of TLS 1.3.  It=E2=80=99s = better for it to be like other AEADs such as AES-GCM, and then get = adapted to TLS 1.3 just like AES-GCM.

Yoav

= --Apple-Mail=_1015C41E-111D-49D8-AE7B-B27602DC46D2-- From nobody Wed Mar 18 16:02: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 EAFD11A8908 for ; Wed, 18 Mar 2015 16:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GntjHD47f10L for ; Wed, 18 Mar 2015 16:02:05 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.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 A02A71A8920 for ; Wed, 18 Mar 2015 16:02:04 -0700 (PDT) Received: by wgra20 with SMTP id a20so47662931wgr.3 for ; Wed, 18 Mar 2015 16:02:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4rw0vWItWnQCLzMYebcjY9OmPqs3Jg+Zc8b2ziQCPvE=; b=hs2Vk8xBrgJHUIZ3y3aDDxdcyliJvooJB3Yy9lMZZ8pWkMTs/Ibxtl/aAUlROTpK+/ 4m6aZ/VC17g6kBEIPHjv0c66mbIonRvoXBTDWRzuyfH/I+JQl32PXTrrmclP/Cfdp9ww Gps0robL+5Su5k9qikK2K++ilhJ398JqFS/sCdLLxnVl634gQuITv6pAg3nlYiyFFGqW wuAH+tr0oMZcFuzEv3eWXOPtx/TusGaHOStuV5xNaPgazxki13yl35ODjnczZrjCJndu 0uJpPQAnt1l72XM3sL405JJgUwNs5DDID8p1NQkx6h8BDv4b64OwuZFSUxacR6Llc+Ea Nw2g== X-Gm-Message-State: ALoCoQmsigCQAP2oALckycPR10hoQTNDbYDcT0B6oEcSVoGbgCAPUGxH16JFQg/LcuXNoPBP1oQX X-Received: by 10.180.208.107 with SMTP id md11mr11375670wic.10.1426719723380; Wed, 18 Mar 2015 16:02:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 18 Mar 2015 16:01:23 -0700 (PDT) In-Reply-To: References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> <55094150.2010800@comodo.com> From: Eric Rescorla Date: Wed, 18 Mar 2015 16:01:23 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c3898e4e803305119812bd Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 23:02:07 -0000 --001a11c3898e4e803305119812bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 18, 2015 at 3:55 PM, Yoav Nir wrote: > > On Mar 18, 2015, at 11:05 PM, Eric Rescorla wrote: > > > On Wed, Mar 18, 2015 at 2:11 AM, Rob Stradling > wrote: > >> On 18/03/15 07:38, Yoav Nir wrote: >> >>> On Mar 18, 2015, at 12:11 AM, Sean Turner wrote: >>>> >>> >> >>> Please note that CFRG is already done with ChaCha20-Poly1305. The >>> document is approved and in the RFC Editor=E2=80=99s queue. >>> >>> The ball is not in this working group=E2=80=99s court. It=E2=80=99s tim= e to decide about >>> draft-mavrogiannopoulos-chacha-tls. >> >> > I await the chair's action on this. > > In the meantime, I see that we have developed a conflict between this > draft and > > https://github.com/tlswg/tls13-spec/pull/155 > > Because this PR prescribes a specific mechanism for generating the nonce > (left-padding the record sequence number) which conflicts with the one fo= r > this draft. Assuming that people feel that the approach we arrived at in > the interim is appropriate, we will probably want to adjust this draft > prior > to acceptance. > > > The draft is suitable for TLS 1.2 as well, so I=E2=80=99m not sure it nee= ds to > comply with the nonce generation procedure of TLS 1.3. It=E2=80=99s bett= er for it > to be like other AEADs such as AES-GCM, and then get adapted to TLS 1.3 > just like AES-GCM. > Well, it's already not like GCM because the GCM draft uses a partially explicit nonce (64 bits) that is carried separately in the record whereas this draft uses the record sequence number in that location. What I am proposing is that instead of using an IV generated from the master secret as the upper 32 bits of the nonce, ChaCha20 should just use 0s. This would make it like TLS 1.3. Alternately, I suppose you could make it like GCM, but it seems like the WG is moving towards saving those bits, so that seems odd. -Ekr --001a11c3898e4e803305119812bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 18, 2015 at 3:55 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

On Mar= 18, 2015, at 11:05 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Mar 18, 2015 at 2:11 AM, Ro= b Stradling=C2=A0<rob.stradling@comodo= .com>=C2= =A0wrote:<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;tex= t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s= pacing:0px">
On 18/03/15 07:38, Yoav Nir wrote:
On Mar 18, 2015, at 12:11 AM, Sean Turner &l= t;TurnerS@ieca.com> wrote:
<snip>
Please note that CFRG is already done with ChaCha20-Poly1305. = The document is approved and in the RFC Editor=E2=80=99s queue.

The = ball is not in this working group=E2=80=99s court. It=E2=80=99s time to dec= ide about draft-mavrogiannopoulos-chacha-tls.





=

Well, it's already not like GCM becaus= e the GCM draft uses a partially
explicit nonce (64 bits) that is= carried separately in the record whereas
this draft uses the rec= ord sequence number in that location. What I am
proposing is that= instead of using an IV generated from the master secret
as the u= pper 32 bits of the nonce, ChaCha20 should just use 0s. This
woul= d make it like TLS 1.3.

Alternately, I suppose you= could make it like GCM, but it seems like the
WG is moving towar= ds saving those bits, so that seems odd.

-Ekr

--001a11c3898e4e803305119812bd-- From nobody Wed Mar 18 21:00: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 AA4921A8735 for ; Wed, 18 Mar 2015 21:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtLFQg1S_pN1 for ; Wed, 18 Mar 2015 21:00:19 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 0D0501A8701 for ; Wed, 18 Mar 2015 21:00:19 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so46003241obb.1 for ; Wed, 18 Mar 2015 21:00:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g8tMWdmkrAKKXzii+2Y+vM5wpdT+tHxv7nlIvFll1zg=; b=cySmXurf+LGtzRarG3vrjD0yTGLH84psxhdv8N9vAUne9mtKgtU/HHs+yeB3edQ2uG jGww8Vn1PEoljjgW2Fdw064jvigpD7yIqNnEQNlkd6vXgCRSD5uZb+QDxN5XriKFVSLD tHeWfC1KEfHUgnvfAMfCldnFFDyWS2Nf8vVJTRHlY53Yt63LfdzsGVceMhBV6HGYczDr exvvH6pSQIvM/nWK3U5DbC4yNjL9pjWb34m4md6n/wCguoovLDfqsUFOmw+EN5FM3kW5 ru5PxssTDlAlZ89noyRqVRKC/PzJ3ib+zNtGIF3VOluDrh/rehs3ZjLmRpTB22cXwSaD vWeg== X-Gm-Message-State: ALoCoQlP7lm2F0wWd1F8bIyEfM2aIVm8MN7Tqz+VGS+Ud4C3xsc2wOIkUZMwlyrV12lOpfteF+Tj MIME-Version: 1.0 X-Received: by 10.60.63.238 with SMTP id j14mr2418498oes.3.1426737618506; Wed, 18 Mar 2015 21:00:18 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Wed, 18 Mar 2015 21:00:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 21:00:18 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:00:19 -0000 I don't object, but for the sake of debate I do want to ask how much deference we owe to RFC5116 here? From nobody Wed Mar 18 21:13: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 DE8D21A8770 for ; Wed, 18 Mar 2015 21:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjb8ic3zIFaf for ; Wed, 18 Mar 2015 21:12:58 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 CCE681A8993 for ; Wed, 18 Mar 2015 21:10:08 -0700 (PDT) Received: by oier21 with SMTP id r21so55578017oie.1 for ; Wed, 18 Mar 2015 21:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G6BclB6NT8uzFEfBsbIFR6OTpravF3bkomRNoGDPjTc=; b=HlxGVIh9RBSzwQZVzWDuDj3U5TIxzZg9npepIoCaZB3F86NHlJW4qDZSx46tEY6Vzg a9+n0Pnxcl+5GkOzcpAvVN+V2JHWSONupT4MEFsaIrE0fEmW7Lpbg/X17T3125/LAQ0a PjyNbL0F4+StnLELKiAesEJ4Z0YTatNV+1KT9ns6r8snjicUFfMfHwJ0PxeVOpabxyM6 65yflgdJlcCoqgeMEsyidPxQ1E3aWd9N6WsLCMVfTc7yKT7KbQ3Oob8P9pPDu1lZpQZ6 hYt2cUFfUOIDzAyIUxY8Q0Bpwuls205mlq+//fmNwqd6ucojgV4QHme36/JywgfDlHI+ BfAg== MIME-Version: 1.0 X-Received: by 10.182.97.41 with SMTP id dx9mr60381637obb.4.1426738208368; Wed, 18 Mar 2015 21:10:08 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Wed, 18 Mar 2015 21:10:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 21:10:08 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:12:59 -0000 On 18 March 2015 at 21:00, Colm MacC=C3=A1rthaigh wrote= : > I don't object, but for the sake of debate I do want to ask how much > deference we owe to RFC5116 here? Only as much as we need to get the job done. It establishes terminology for a thing we use (i.e., the AEAD "API"). I don't see any reason not to use the term "nonce" as used in RFC 5116. It's not imprecise in any way. It's arguably more correct than "IV", which has conflicting connotations. From nobody Wed Mar 18 21:21: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 98D081A877C for ; Wed, 18 Mar 2015 21:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D-REB5XOf5c for ; Wed, 18 Mar 2015 21:21:35 -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 223F61A8766 for ; Wed, 18 Mar 2015 21:21:35 -0700 (PDT) Received: by ykfc206 with SMTP id c206so24242306ykf.1 for ; Wed, 18 Mar 2015 21:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J7gyU4k2577TX/sS0yMZ6kbJUuyiJuCBXU5FFRVWmgE=; b=MP2myD8k34nsn0dw2i6QyNwDERhlL3qOQJADfOg4z4INyWBXqHUWWfL/Z6TF5dWCjI 1SRTFAffEzFXwf7bCyph7FZWPAaALyTbk3mj+ejwtwWrjm7nTKyFXLf+oynUiv8SLH1D EipsqjxcLDnDlS4dY/tBT1ayFKo2Wz8fohOkLrW0QdgVHdAYtbCy6NwkdO9rm48AGwYO oyZgx+Aa8cXrdiClXIrgPTHNRpikTbbn1P/cWfYMMHfc++d6BHhKS8flD3M1/TOZ+O1h En0uuZng7nPxgeltSmp6aLqU2at25YhdTOVQICkhviiAJDxcnmdAMTRqOPH+3rhm0ylA bjZQ== MIME-Version: 1.0 X-Received: by 10.170.46.3 with SMTP id 3mr85157008yko.24.1426738894435; Wed, 18 Mar 2015 21:21:34 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Wed, 18 Mar 2015 21:21:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 21:21:34 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:21:36 -0000 I'm afraid that by radically changing the record layer we may be working ourselves into a corner. If we're going to make a change this radical, why not make equally radical changes to simplify the protocol further if that's possible? I'm also not sure what we're supposed to be gaining from this change: while it's true that we don't need to send the explicit nonce, I don't know that we are losing anything from having it. Yes, I know the ChaCha draft does it a seemingly more sensible way, but the last thing we need is to further increase the codesize of TLS implementations. I do know that a recently implemented extension to FreeBSD won't work anymore without some changes. (see http://2015.asiabsdcon.org/timetable.html.en#P7A for an abstract) Sincerely, Watson Ladd From nobody Wed Mar 18 21:24: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 72EFD1A8770 for ; Wed, 18 Mar 2015 21:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR4dYFZpyD_B for ; Wed, 18 Mar 2015 21:24:21 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.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 6A18B1A876F for ; Wed, 18 Mar 2015 21:24:21 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so26120859obc.2 for ; Wed, 18 Mar 2015 21:24:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y9OoomU0NdjdBvwlWUOA6uGeT2tMc+rgz3DPdQwKHJ4=; b=a6bcPralCuJ9g6XSjXA4ceCKWCn176StPwK0H8Gxnyp+zp1Rzw+tx7WDePpnQDyQ4f 2p3VBHnh0selOXLlfBq5x2F365T9VpkwI2EoBJ48Vc3zURyOFUqAx7TQSWKa3LoyTZ/f gU2fbUEgEhc8cJJDXLmcZyYyctzVAREvIpiMY09FTn90SBXCglekGe6Tnyz93OHNtyKL Uyu8HtknlnjgXle2PHr7V1P+ag5OWOQPEnHiENi7r1aajmydTm4FMrWZlNwJD2sh7J1e 7/OXCymbU/u7UJwQ60L/13cGjd7bYUz/k+CT5gl9548dep4rALiebJfvvY+72rP2Si7O s2SQ== X-Gm-Message-State: ALoCoQnkiyzQXFleNZbqx3l5on98M4oTEct86goOHcIUIRogTfOfCAcd3/zD2TPEcvO7wduRTlou MIME-Version: 1.0 X-Received: by 10.182.24.202 with SMTP id w10mr60992111obf.9.1426739060886; Wed, 18 Mar 2015 21:24:20 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Wed, 18 Mar 2015 21:24:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 21:24:20 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:24:22 -0000 Why would the extension break? On Wed, Mar 18, 2015 at 9:21 PM, Watson Ladd wrote: > I'm afraid that by radically changing the record layer we may be > working ourselves into a corner. If we're going to make a change this > radical, why not make equally radical changes to simplify the protocol > further if that's possible? I'm also not sure what we're supposed to > be gaining from this change: while it's true that we don't need to > send the explicit nonce, I don't know that we are losing anything from > having it. Yes, I know the ChaCha draft does it a seemingly more > sensible way, but the last thing we need is to further increase the > codesize of TLS implementations. > > I do know that a recently implemented extension to FreeBSD won't work > anymore without some changes. (see > http://2015.asiabsdcon.org/timetable.html.en#P7A for an abstract) > > Sincerely, > Watson Ladd -- Colm From nobody Wed Mar 18 21:43:34 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 8CFA21A8790 for ; Wed, 18 Mar 2015 21:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpWgt0LUhCX3 for ; Wed, 18 Mar 2015 21:43:32 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::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 46DA71A8715 for ; Wed, 18 Mar 2015 21:43:32 -0700 (PDT) Received: by yhle43 with SMTP id e43so10000223yhl.2 for ; Wed, 18 Mar 2015 21:43:31 -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=f5hRoXNXFKNYlMa1lE/e/OZPUu5I1p9TP1OATi2wYiI=; b=wamGJtpjuIU+mlEZTrvFwAy3a8dKPcnKRx7uTJaYhxO8zKaX6kkvbBTA/R/L1tdVQe jZo9xdtXLNhgaIiKVV2DmzYIwf8TwWU+YmIEpS+/GlNYINHshPmdSjVIdUwcrOUIrheZ tPpnulpkHhQhi3ZzFgWYTLK2Tc1mYLUouL3lgcCtwXyou7cxQaOel91Bmkq8hFvsGVme XMNfqM3/FnFNqKVkVcUU/ihE1iLCuArXhiUtBxCm7rFupVVxDwNhd5AewQUGy6Veywye N7QAdvrTQM4fLL+wFNG4R6uJnc5n+1FEsfBztfv9mdaKp5hxt5nIoTFW0tmzQdPbiUnC ZJjw== MIME-Version: 1.0 X-Received: by 10.236.220.65 with SMTP id n61mr75279910yhp.44.1426740211635; Wed, 18 Mar 2015 21:43:31 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Wed, 18 Mar 2015 21:43:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 21:43:31 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 04:43:33 -0000 On Wed, Mar 18, 2015 at 9:24 PM, Colm MacC=C3=A1rthaigh = wrote: > Why would the extension break? Because it currently supports the TLS 1.2 record layer and AEAD mode, not the now different TLS 1.3 one. I confirmed this would be a minor issue with the author yesterday. Sure, we can say that for any implementation, and this hasn't yet made it into the wild yet, but now both the kernel and userland sides need changes for TLS 1.3. Add in some release cycles and LTS releases, and you get some more sites that will not upgrade for a long time. It's not the only example: I've heard rumors that some implementations do the record layer in more unusual ways, while having the handshake in more softwarelike things. I'm not claiming this is a particularly big nit, rather something that tells me to lean on the conservative side when changing things related to the record layer as compared to the handshake. Sincerely, Watson Ladd > > On Wed, Mar 18, 2015 at 9:21 PM, Watson Ladd wrot= e: >> I'm afraid that by radically changing the record layer we may be >> working ourselves into a corner. If we're going to make a change this >> radical, why not make equally radical changes to simplify the protocol >> further if that's possible? I'm also not sure what we're supposed to >> be gaining from this change: while it's true that we don't need to >> send the explicit nonce, I don't know that we are losing anything from >> having it. Yes, I know the ChaCha draft does it a seemingly more >> sensible way, but the last thing we need is to further increase the >> codesize of TLS implementations. >> >> I do know that a recently implemented extension to FreeBSD won't work >> anymore without some changes. (see >> http://2015.asiabsdcon.org/timetable.html.en#P7A for an abstract) >> >> Sincerely, >> Watson Ladd > > > > -- > Colm --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 19 04:34: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 0667B1A89AD for ; Thu, 19 Mar 2015 04:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70ZUBFIW7-mZ for ; Thu, 19 Mar 2015 04:34:26 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.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 DE36D1A89A1 for ; Thu, 19 Mar 2015 04:33:57 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so52081745obc.0 for ; Thu, 19 Mar 2015 04:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gVKNJEia/NAwg7fOsefTxoizlbfjgfEUxIudkDV8D5I=; b=fA7WGQ4lElsLD8IvfEdoljuvixRSGO2lBMDhb0zqdOL0uCvm345VhdUtPkGMISaD8g G8YqI3x7KGMrEKXGbNmVc+EgB5N5+r+47cXDfDHn4twaHBRgPxO/VULV0nCkEqM/KSAs bzVOE/rtbpBc4gpLUg58wxZgfK4TYVTd+6iLnfmSqs+1+HsKWs5nJ7++h+3tjVl/z4Dk HoQCOpw4+QPHDivDSuraGBT8nQYxDO422QMCFUuEOWb/IeJMvvHNChlM4Ykmffl22/qH Uzc8lvWvz+CpwzoN4WdwxciOfaVmyZqHKu84OxFDGT6Hr9/5woOyu2R3wCb+f6L+5PmL a4ug== X-Gm-Message-State: ALoCoQn38k2jHHZQcXyH8NMpal/Y/iyEYFQRIj8xQA0WmL3KVLgF+j7ehCTyPSTgDfcayJPDVvBu MIME-Version: 1.0 X-Received: by 10.60.82.10 with SMTP id e10mr2822358oey.85.1426764837329; Thu, 19 Mar 2015 04:33:57 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Thu, 19 Mar 2015 04:33:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 01:33:57 -1000 Message-ID: From: Brian Smith To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:34:28 -0000 Watson Ladd wrote: > If we're going to make a change this > radical, why not make equally radical changes to simplify the protocol > further if that's possible? That's already happening. > I'm also not sure what we're supposed to > be gaining from this change: while it's true that we don't need to > send the explicit nonce, I don't know that we are losing anything from > having it. 1. The explicit nonce is a place to potentially leak secret data. 2. The explicit nonce is a place where a PRNG could be used poorly, and/or a poor PRNG could be used. 3. Security properties of an explicit nonce cannot practically be verified by the receiver, whereas the receiver could (and in fact would have to) verify that an implicit nonce based on the record sequence number is safe. 4. The implicit IV reduces per-record overhead on the wire by 16 or 32 bytes. For some applications that's substantial. There are other advantages that aren't so simple to describe. > Yes, I know the ChaCha draft does it a seemingly more > sensible way, but the last thing we need is to further increase the > codesize of TLS implementations. This change would not contribute substantial complexity to most TLS libraries that would implement it. Most TLS libraries already have similar logic to deal with implicit vs. explicit IVs in CBC mode for SSL3/TLS1 vs. TLS 1.1+. Also, the proposed changes to the handshake state machine for TLS 1.3 are much larger. It seems we can't substantially simplify the protocol proportionately increasing the complexity of implementations that need to also implement earlier versions. Cheers, Brian From nobody Thu Mar 19 04:48: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 1B2161A1ADA; Thu, 19 Mar 2015 04:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWKt13S5iVgI; Thu, 19 Mar 2015 04:48:27 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B61A0193; Thu, 19 Mar 2015 04:48:26 -0700 (PDT) Received: from [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2] (unknown [IPv6:2602:43:2da:6400:f9c1:b626:6a91:92e2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0E000203C1; Thu, 19 Mar 2015 12:48:25 +0100 (CET) Message-ID: <550AB788.2040701@acm.org> Date: Thu, 19 Mar 2015 05:48:24 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" , tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] rfc5764 design meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:48:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FYI, we will have a design meeting on Sunday around 9pm in Dallas to put together a proposal about the 5764 multiplexing scheme. The plan is to present this proposal in the avtcore WG session on Tuesday. Anybody with opinions on how to solve this problem should join us. I'll send another email when I know the place and exact time. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVCreIAAoJECnERZXWan7E0i8P/2h5E6wxdCpvqbyy863TfXqa KwS7zb9LBvRWzHB0tEHm41NdCK+IAggRvNrDsJQKJIeddMwh+8vQWckpvk8t5M5f UCS286hkOUKAUF7I3Cl/qGstYu/TmxcjK7yzq5UUY98xl0D3U+d0mLJAc7ZuSthj VZ+9MVO+MmaAxqNZFKQpZzQZ1fNTo807tRwGUhXatJDj1lH4+SIQrftNpEk1UHm9 UH4Siv4y/kZonMK9mZc2IK4zNGSwYHv9jc5IjaPLzZLdNL6lP7gc177TWOYj6Axz W6JWX+17oTNEXRFQ4G+lAAaNw0C7zivsIs4M1rdtlGBArkfO5Nf4UuiewjATZGP0 JzMwh7FZNtufEy5PxavBoJ6kN/iQigP6xVKaQC+j3EkSzcksyEB2cj8BxOFvwrSL V68oyR/ohoGvK39yl+6K9RIcbYsvHzocJyj31LZHuhkctMNzR5HRVquvSoWW904i +N4aNI1Igl9rIY3keVdaAuhtya2ZS+yEeP+/O61UHRLcmOwOAlLHCcrqsbOFyrIO 7H+vZMjV8DnGwZrUeKbxim5iWxIWNP7tqsQ8nLiPdzaLzMxrGXdPFWacOcw8D5g3 b4SzHkdhXUAbtZMKY1f0FydvoUUuBchSDW9N2oGDRaEaVpsY9i16am2EoHMSrMXE AHHqU6Y199nz/e+0Jr66 =RAQh -----END PGP SIGNATURE----- From nobody Thu Mar 19 05:28:45 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 EAFA61A89A5 for ; Thu, 19 Mar 2015 05:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAHCXzWKAFH9 for ; Thu, 19 Mar 2015 05:28:42 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [67.18.65.30]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0BD1A8997 for ; Thu, 19 Mar 2015 05:28:42 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 3C9358A08BA0E; Thu, 19 Mar 2015 07:28:42 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 2E4068A08B9EA for ; Thu, 19 Mar 2015 07:28:42 -0500 (CDT) Received: from [96.231.226.227] (port=60806 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YYZZ3-0005f7-7q; Thu, 19 Mar 2015 07:28:41 -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: <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@gmail.com> Date: Thu, 19 Mar 2015 08:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8BFBD8B2-8803-47FB-B48C-7BAD39006F7E@ieca.com> References: <7B0B2402-6D04-48B3-BB25-1B6FC6FBC61D@ieca.com> <90A9B6DC-A775-4E4C-BA58-E40260F9BF55@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.226.227 X-Exim-ID: 1YYZZ3-0005f7-7q X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.226.227]:60806 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 12:28:44 -0000 On Mar 18, 2015, at 03:38, Yoav Nir wrote: > Please note that CFRG is already done with ChaCha20-Poly1305. The = document is approved and in the RFC Editor=92s queue. >=20 > The ball is not in this working group=92s court. It=92s time to decide = about draft-mavrogiannopoulos-chacha-tls. >=20 > Yoav Yesterday I sent a heads up to the authors of the draft you referenced. = This is going to be one of the topics of discussion the chairs will = raise during the status portion of our welcome/agenda/bash/status = slides. spt=20= From nobody Thu Mar 19 08:37: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 1574C1A1A02 for ; Thu, 19 Mar 2015 08:37:32 -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 aImcRwqw4akT for ; Thu, 19 Mar 2015 08:37:29 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.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 94D961A037B for ; Thu, 19 Mar 2015 08:37:29 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so69476841qcb.2 for ; Thu, 19 Mar 2015 08:37: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:date:message-id:subject:from:to :content-type; bh=R7H5+VMu6Qlr3Pq7J08NO/ntA8uEEzGV08wFnXZmWWI=; b=k+5+pKdtZdIwwwwIIF2yff1xpFf4G5dHDHpMte8+N4wzevi6u44gBwXsWYRJXtVblH kXYbv70gEPVQTs3DW8p+FAKwGPNUQ+kWzfNJRdNw6ui47uezGUWmjKXmDd2ycR+OUWRF fP5xlRz9KDqacklL5ZX9iBkwt67yw9hPm9qy0ixOy0eplnnEyfJfbYb4jmZPXYcILNEV BfOsuHt92fT5AxNmetqZy16L3oaLAYap1ABEE4tLWO20HWjZRyNrcLg3xzV5yp+dnQxz GKp8QFr1xijx6nelLAs9G9VqoW+T3tUAHAQ4jQ9nc9ZborMKh0kxj+Ns2J51b4IZdTMC /0NQ== X-Gm-Message-State: ALoCoQmgbAqi+uB4+g03sruHWq4GCn82OPRriYBd9/dHZ6fRxczBKinft/bBDKi0QUdP/fFDzF1B MIME-Version: 1.0 X-Received: by 10.140.82.176 with SMTP id h45mr93377020qgd.75.1426779448790; Thu, 19 Mar 2015 08:37:28 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Thu, 19 Mar 2015 08:37:28 -0700 (PDT) X-Originating-IP: [50.206.82.175] Date: Thu, 19 Mar 2015 08:37:28 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c130f237e65f0511a5fade Archived-At: Subject: [TLS] TLS Agenda for IETF 92 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:37:32 -0000 --001a11c130f237e65f0511a5fade Content-Type: text/plain; charset=UTF-8 Agenda for TLS session at IETF-92 has been uploaded and copied below for your reference: IETF 92 TLS Working Group Meeting Date: THURSDAY, March 26, 2015, 0900-1130 (CDT) Location: Oak, Fairmont Dallas, Dallas, TX, USA Version: 1.2 ======================================================= - Welcome, note takers, blue sheets, note well (5 min) [Chairs] - Document Status (10 Min) [Chairs] - Backwards compatibility pull request 107 (10 Min) [] - OPTLS (30 Min) [EKR,KRAWCZYK] - 0-RTT Issues (replay, PFS, etc) (30 Min) [EKR] - Update/Rekey (10 Min) [EKR] - Client Auth (15 Min) [EKR,POPOV] - AOB (padding, MTI, PSS, PSK, cached info, 4492) (30 Min) [Chairs] Cheers, Joe --001a11c130f237e65f0511a5fade Content-Type: text/html; charset=UTF-8
Agenda for TLS session at IETF-92 has been uploaded and copied below for your reference:

IETF 92 TLS Working Group Meeting
Date: THURSDAY, March 26, 2015, 0900-1130 (CDT)
Location: Oak, Fairmont Dallas, Dallas, TX, USA
Version: 1.2
=======================================================

- Welcome, note takers, blue sheets, note well (5 min) [Chairs]
- Document Status (10 Min) [Chairs]
- Backwards compatibility pull request 107 (10 Min) []
- OPTLS (30 Min) [EKR,KRAWCZYK] 
- 0-RTT Issues (replay, PFS, etc) (30 Min)  [EKR]
- Update/Rekey (10 Min) [EKR]
- Client Auth (15 Min) [EKR,POPOV]
- AOB (padding, MTI, PSS, PSK, cached info, 4492) (30 Min) [Chairs]


Cheers,

Joe
--001a11c130f237e65f0511a5fade-- From nobody Thu Mar 19 09:21: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 ECC7A1ACE2F for ; Thu, 19 Mar 2015 09:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn_UWim5xZfN for ; Thu, 19 Mar 2015 09:20:56 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::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 AF2AC1ACE30 for ; Thu, 19 Mar 2015 09:20:55 -0700 (PDT) Received: by yhpt93 with SMTP id t93so28262652yhp.0 for ; Thu, 19 Mar 2015 09:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4WryrL+FeNPw5imVn7y0n5P2cd1DRNsAj9LUoGJLEE8=; b=a1ngmu8IEvvxH00x6rse3N7wEVjE/uUX7Jgdyi7d3MS8IynsvBe00WUMT8rnp1Ydjq +QvnGOU6ZsOHIQmhVZ2S2Hepy9OkZdnp5jCEBdEpUPe0FPugUpE13jJrPwT3QqNbQCSA +0DjoPqbFEnj/Ya2ugbMTT+jD9R6hwvRvo0i97lCFxa+tDNL49r58+nx/5LXlKhHRa2F 5ViO7hwgN+VWxnMZd84Yop2HB93q+oCp+tXVg8Mh5TX1INrEA2I1hKVRNveGviwAiqwh 1kiG6+7zXgbuBbh7yonChuVCCc/xWq+/9LsdGGQnJiPnM5d0iWGwmA/PtrRy+aFZ4aPa UtLA== MIME-Version: 1.0 X-Received: by 10.236.220.65 with SMTP id n61mr77884738yhp.44.1426782055016; Thu, 19 Mar 2015 09:20:55 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 09:20:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 09:20:54 -0700 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:20:59 -0000 On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith wrote: > Watson Ladd wrote: >> If we're going to make a change this >> radical, why not make equally radical changes to simplify the protocol >> further if that's possible? > > That's already happening. No it's not: the draft is still longer than the TLS 1.2 RFC, and seems to demand support for every single usecase. This seems at odds with absolute simplification, where we would throw out less important features, and radically reduce the complexity. > >> I'm also not sure what we're supposed to >> be gaining from this change: while it's true that we don't need to >> send the explicit nonce, I don't know that we are losing anything from >> having it. > > 1. The explicit nonce is a place to potentially leak secret data. > 2. The explicit nonce is a place where a PRNG could be used poorly, > and/or a poor PRNG could be used. You are not supposed to use random nonces with GCM. > 3. Security properties of an explicit nonce cannot practically be > verified by the receiver, whereas the receiver could (and in fact > would have to) verify that an implicit nonce based on the record > sequence number is safe. The receiver cannot determine that the sender isn't sending an extra copy to the secret police anyway. Of course, this implicit nonce strategy will prevent certain bugs involving being unable to count, and may be worth it. > 4. The implicit IV reduces per-record overhead on the wire by 16 or 32 > bytes. For some applications that's substantial. This is an actual advantage. > > There are other advantages that aren't so simple to describe. > >> Yes, I know the ChaCha draft does it a seemingly more >> sensible way, but the last thing we need is to further increase the >> codesize of TLS implementations. > > This change would not contribute substantial complexity to most TLS > libraries that would implement it. Most TLS libraries already have > similar logic to deal with implicit vs. explicit IVs in CBC mode for > SSL3/TLS1 vs. TLS 1.1+. A million here, a million there: pretty soon you start spending real money. > > Also, the proposed changes to the handshake state machine for TLS 1.3 > are much larger. It seems we can't substantially simplify the protocol > proportionately increasing the complexity of implementations that need > to also implement earlier versions. Adding new states and transitions to a state machine doesn't increase complexity that much: if the transition doesn't apply, you don't take it. But adding additional special casing all over the place to deal with TLS 1.3 does increase complexity much more. Sincerely, Watson Ladd > > Cheers, > Brian -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Mar 19 09:26: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 0F7D61ACE31 for ; Thu, 19 Mar 2015 09:26: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 gVstXErVLhXb for ; Thu, 19 Mar 2015 09:26: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 561731A7005 for ; Thu, 19 Mar 2015 09:26:29 -0700 (PDT) Received: by wixw10 with SMTP id w10so12531440wix.0 for ; Thu, 19 Mar 2015 09:26: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=9zSeDCL2+fo7JfakpQztLM5nMkkhaJetXfrvMlAUqF0=; b=FyubQYqRwSF/GKYMXzL+W+BWifLfSwxGE7Lq5hdHFxRUyZP9/34ssKP/KwzbUL9ZIl okysTtFqjyJJ3eMMHjYS+4s57xhHmTgTrPv0Z6+pykC1gxFap3K83VnIkWdz00ouOMJs XFaj03J5MDWIdOz9m7XnKbI/U2DcWXRESdLawmkVTberELh8ydCUolnhv7kM/NB/gHHC RLrVW401rknHAblwx7/JWW4DKgna5TOHQ4p790pHSbIQgLm5QfIofgPp0Nn9RonBrSlf XOLArHKTZLdC0wU43v3CfxoKJtZQu4xA2rBwH/90hBD1h0aUJhYOWsK3WJmi2PFVPDH4 IFDQ== X-Gm-Message-State: ALoCoQmvgdsWkT3PFMAs8Y5sgyNa+82PQnCHY9zAORpifj1Z2CyTIsqXefxRdozsU9n541FFK4va X-Received: by 10.194.120.230 with SMTP id lf6mr151588555wjb.78.1426782388065; Thu, 19 Mar 2015 09:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 09:25:47 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 19 Mar 2015 09:25:47 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e0115fe2469ac800511a6a98d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:26:31 -0000 --089e0115fe2469ac800511a6a98d Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 9:20 AM, Watson Ladd wrote: > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith wrote: > > Watson Ladd wrote: > >> If we're going to make a change this > >> radical, why not make equally radical changes to simplify the protocol > >> further if that's possible? > > > > That's already happening. > > No it's not: the draft is still longer than the TLS 1.2 RFC, The TLS 1.3 draft is 91 pages long ( https://tools.ietf.org/html/draft-ietf-tls-tls13-05) RFC 5246 is 103 pages long (https://tools.ietf.org/html/rfc5246) -Ekr --089e0115fe2469ac800511a6a98d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 9:20 AM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
On Thu, Mar 19= , 2015 at 4:33 AM, Brian Smith <= brian@briansmith.org> wrote:
> Watson Ladd <watsonbladd@g= mail.com> wrote:
>> If we're going to make a change this
>> radical, why not make equally radical changes to simplify the prot= ocol
>> further if that's possible?
>
> That's already happening.

No it's not: the draft is still longer than the TLS 1.2 RFC,

The TLS 1.3 draft is 91 pages long (https://tools.ietf.or= g/html/draft-ietf-tls-tls13-05)
RFC 5246 is 103 pages long (<= a href=3D"https://tools.ietf.org/html/rfc5246">https://tools.ietf.org/html/= rfc5246)

-Ekr

=
--089e0115fe2469ac800511a6a98d-- From nobody Thu Mar 19 10:02: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 36DF11A1AFC for ; Thu, 19 Mar 2015 10:02: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 93MX7Q8bpyag for ; Thu, 19 Mar 2015 10:02:40 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::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 930CC1A1A47 for ; Thu, 19 Mar 2015 10:02:40 -0700 (PDT) Received: by yhim52 with SMTP id m52so341278yhi.2 for ; Thu, 19 Mar 2015 10:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uv1UjQcHJMc6+dU5xZIZUT+7mSSa3hPJBm9K6qFXXoo=; b=pBCSutqVlppE9UPovez84JDjy2I0h8ZAeIWugeXG8kPvKmEuZ6uHfNQtGGXiYppRFa hXwpVArh50lbd7TAKNe2Kjei7yVg0qv0WLXlsMitVLSyOTxTv/dwpMuEx7Va21z32t02 W8QxtReg9UA64LFE0OEJJW6n+RfvOTZ2qgl+34YiRJrhMUvqjZceOLmAQd9nB980HPKu 8rhcz++MCGHX5HHO3nrHdbxn1gW0U8PHx2GdVUEkuCyAG7TU8NvYNfMbX9Zj4YS6HJnS OX+YUWIKvk02oDTfV76laWPcHwTHppFwm4GdB9bXJ3ccy8153JbjexteEXxl9zmwpGsq vJWA== MIME-Version: 1.0 X-Received: by 10.236.63.6 with SMTP id z6mr80050350yhc.65.1426784559553; Thu, 19 Mar 2015 10:02:39 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:02:39 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:02:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 10:02:39 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e01294ff0d7e32f0511a72a04 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:02:42 -0000 --089e01294ff0d7e32f0511a72a04 Content-Type: text/plain; charset=UTF-8 On Mar 19, 2015 9:26 AM, "Eric Rescorla" wrote: > > > > On Thu, Mar 19, 2015 at 9:20 AM, Watson Ladd wrote: >> >> On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith wrote: >> > Watson Ladd wrote: >> >> If we're going to make a change this >> >> radical, why not make equally radical changes to simplify the protocol >> >> further if that's possible? >> > >> > That's already happening. >> >> No it's not: the draft is still longer than the TLS 1.2 RFC, > > > The TLS 1.3 draft is 91 pages long ( https://tools.ietf.org/html/draft-ietf-tls-tls13-05) > RFC 5246 is 103 pages long (https://tools.ietf.org/html/rfc5246) > Thanks for the correction. > -Ekr --089e01294ff0d7e32f0511a72a04 Content-Type: text/html; charset=UTF-8


On Mar 19, 2015 9:26 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
>
>
> On Thu, Mar 19, 2015 at 9:20 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith <brian@briansmith.org> wrote:
>> > Watson Ladd <watsonbladd@gmail.com> wrote:
>> >> If we're going to make a change this
>> >> radical, why not make equally radical changes to simplify the protocol
>> >> further if that's possible?
>> >
>> > That's already happening.
>>
>> No it's not: the draft is still longer than the TLS 1.2 RFC,
>
>
> The TLS 1.3 draft is 91 pages long (https://tools.ietf.org/html/draft-ietf-tls-tls13-05)
> RFC 5246 is 103 pages long (https://tools.ietf.org/html/rfc5246)
>

Thanks for the correction.
> -Ekr

--089e01294ff0d7e32f0511a72a04-- From nobody Thu Mar 19 10:40: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 9C67D1A86FE for ; Thu, 19 Mar 2015 10:40:07 -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 GizIZo-2efBO for ; Thu, 19 Mar 2015 10:40:04 -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 7A5FA1A8033 for ; Thu, 19 Mar 2015 10:40:04 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B37BB1887AC; Thu, 19 Mar 2015 19:40:01 +0200 (EET) Date: Thu, 19 Mar 2015 19:40:01 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150319174001.GA3690@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] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:40:07 -0000 On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote: > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith wrote: > > Watson Ladd wrote: > >> If we're going to make a change this > >> radical, why not make equally radical changes to simplify the protocol > >> further if that's possible? > > > > That's already happening. > > No it's not: the draft is still longer than the TLS 1.2 RFC, and seems > to demand support for every single usecase. This seems at odds with > absolute simplification, where we would throw out less important > features, and radically reduce the complexity. Got examples of features that could be removed or at least rendered truly optional (besides things like 0RTT[1])? > > Also, the proposed changes to the handshake state machine for TLS 1.3 > > are much larger. It seems we can't substantially simplify the protocol > > proportionately increasing the complexity of implementations that need > > to also implement earlier versions. > > Adding new states and transitions to a state machine doesn't increase > complexity that much: if the transition doesn't apply, you don't take > it. But adding additional special casing all over the place to deal > with TLS 1.3 does increase complexity much more. Unfortunately, to fix the TLS handshaking mechanism, calls for handshake totally different from one TLS 1.2 has. The overall architecture of TLS 1.3 handshake looks good to me, the divisions it makes look to harden the handshake a lot against various attacks. Unfortunately, the handshake currently looks to have rather large implementation security gap. Additionally, in practice, the capablity to send a handshake that can be downnegotiated is needed. [1] If 0RTT was an extension with positive acknowledgement, server could just leave it unimplemented and things would still work, albeit possibly with extra RTT. -Ilari From nobody Thu Mar 19 10:53: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 E4B8D1A8769 for ; Thu, 19 Mar 2015 10:53:01 -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 73VHWkC0Qqli for ; Thu, 19 Mar 2015 10:53:00 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.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 2E30A1A82E2 for ; Thu, 19 Mar 2015 10:53:00 -0700 (PDT) Received: by weop45 with SMTP id p45so63636234weo.0 for ; Thu, 19 Mar 2015 10:52:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aYgPcEHhEiuC3lFrxBNdhQMIVYe4ZgVcK/f4furGlOA=; b=D3+l0BO27jEk8WafqUvUFj2nY5UxNqaZ7rX90OqffgNMOiFQon38UcDES5LwqTQxBZ 2xCcUhnIOx7hrekl8xjncKRKl1hki1/v+cbBZiXyNPK5SOZeQtqd4SO6hSo4wgGVtSi0 pD5jYSkZQQm7mzJzIg12bldj5h8LBe7B/By+B7XUmsGvaHWKflWzWhf+YXHdjan796QX l5KmClC9fxoIbAi3RTdukaW8QNMBDqUPoL3rcoUJz34FfrkokJ2G7YZ60LaCO0yu7Rbo BXEygFwWrCa5PLTiT9KpltZndId+DAQ5lNw5sb4tcpsRYpRdIX+iz14F824wfXrkB+NE /27w== X-Gm-Message-State: ALoCoQnGWa4tguV1aO4PUhVUFp+26bGbRFaIhbnmGk9Gt+NKd6iD+GSKnTDvEBmxktGzaYXToQqf X-Received: by 10.194.62.198 with SMTP id a6mr156663383wjs.90.1426787578900; Thu, 19 Mar 2015 10:52:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 10:52:18 -0700 (PDT) In-Reply-To: <20150319174001.GA3690@LK-Perkele-VII> References: <20150319174001.GA3690@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 19 Mar 2015 10:52:18 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7ba97e4ecf88a10511a7de90 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:53:02 -0000 --047d7ba97e4ecf88a10511a7de90 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 10:40 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > > [1] If 0RTT was an extension with positive acknowledgement, server could > just leave it unimplemented and things would still work, albeit possibly > with extra RTT. I agree it must be possible to do a server that does not do 0-RTT. -Ekr > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7ba97e4ecf88a10511a7de90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 10:40 AM, Ilari Liusvaara <= ;ilari.liu= svaara@elisanet.fi> wrote:
[1] If 0RTT was an extension with positive acknowledgement, server could just leave it unimplemented and things would still work, albeit possibly with extra RTT.

I agree it must be possible= to do a server that does not do 0-RTT.

-Ekr
=
=C2=A0



-Ilari

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

--047d7ba97e4ecf88a10511a7de90-- From nobody Thu Mar 19 10:56: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 E75731A87E3 for ; Thu, 19 Mar 2015 10:55: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 NXfwYYDvTTup for ; Thu, 19 Mar 2015 10:55:55 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::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 8D95B1A8778 for ; Thu, 19 Mar 2015 10:55:55 -0700 (PDT) Received: by yhch68 with SMTP id h68so29179599yhc.1 for ; Thu, 19 Mar 2015 10:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FGvApu22WwqeZ50tATUpLQNgJ9JOL1Ghc92IqoMt1Mw=; b=pqPgcd9CU7muA1WckMY+VZlB7wbyfMSkhr9PVbMLOpE0Qx83UsuJhvFfZeKKBwunzA 6Dw/PHNOkMWm+0CxksE/4joB/m1lhieNIhQMi0n59jT93rQDg0sp6ajf6yUB8OjPitWr qCjalWw3jK+a0mHO7Vp0Eo9teQT/RA0W9bXS0xb1YFlZBhZEpPw2RG1v3HmUrefZ4Uk8 Km529bAzLYFPLLkFvaAeCxLD1DbCmjZldu6WPmPFDgxDnnF647Mm4h0cmHzdp4ld1nZK jnKFqisioNkx/Ub7UYeDrv9u8mHJomNgFm11S7PPVvsTWjY+9+KUgBeNdteLEoTiQqtP n5NA== MIME-Version: 1.0 X-Received: by 10.170.185.133 with SMTP id b127mr64000250yke.28.1426787754960; Thu, 19 Mar 2015 10:55:54 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:55:54 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Thu, 19 Mar 2015 10:55:54 -0700 (PDT) In-Reply-To: <20150319174001.GA3690@LK-Perkele-VII> References: <20150319174001.GA3690@LK-Perkele-VII> Date: Thu, 19 Mar 2015 10:55:54 -0700 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1139d34a4def4a0511a7e9f5 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:55:58 -0000 --001a1139d34a4def4a0511a7e9f5 Content-Type: text/plain; charset=UTF-8 On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" wrote: > > On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote: > > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith wrote: > > > Watson Ladd wrote: > > >> If we're going to make a change this > > >> radical, why not make equally radical changes to simplify the protocol > > >> further if that's possible? > > > > > > That's already happening. > > > > No it's not: the draft is still longer than the TLS 1.2 RFC, and seems > > to demand support for every single usecase. This seems at odds with > > absolute simplification, where we would throw out less important > > features, and radically reduce the complexity. > > Got examples of features that could be removed or at least rendered > truly optional (besides things like 0RTT[1])? Update: most connections are short-lived. Changing client auth state during a connection: restarting works fine. The 1 RTT idea being proposed involves remembering unnecessary state. AGL mentioned the ability to have fragmentation of Client Hellos in the record layer. > > > > Also, the proposed changes to the handshake state machine for TLS 1.3 > > > are much larger. It seems we can't substantially simplify the protocol > > > proportionately increasing the complexity of implementations that need > > > to also implement earlier versions. > > > > Adding new states and transitions to a state machine doesn't increase > > complexity that much: if the transition doesn't apply, you don't take > > it. But adding additional special casing all over the place to deal > > with TLS 1.3 does increase complexity much more. > > Unfortunately, to fix the TLS handshaking mechanism, calls for handshake > totally different from one TLS 1.2 has. > > The overall architecture of TLS 1.3 handshake looks good to me, the > divisions it makes look to harden the handshake a lot against various > attacks. Unfortunately, the handshake currently looks to have rather large > implementation security gap. > > Additionally, in practice, the capablity to send a handshake that can > be downnegotiated is needed. This should be doable without increasing the complexity of current code that much. The issue with the handshake isn't so much the parsing ( although nested length encoding is a bad idea, compared to length encoded tokens) but the state machine. Adding new transitions and states carefully shouldn't be too bad. Most implementations already keep a ruuning hash, so the enhanced handshake prorocol can fit in. We should tighten up the description significantly, explaining exactly which steps are expected when. Sincerely, Watson Ladd > > > > [1] If 0RTT was an extension with positive acknowledgement, server could > just leave it unimplemented and things would still work, albeit possibly > with extra RTT. > > > > -Ilari --001a1139d34a4def4a0511a7e9f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi> wrote: >
> On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote:
> > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith <brian@briansmith.org> wrote:
> > > Watson Ladd <wat= sonbladd@gmail.com> wrote:
> > >> If we're going to make a change this
> > >> radical, why not make equally radical changes to simplif= y the protocol
> > >> further if that's possible?
> > >
> > > That's already happening.
> >
> > No it's not: the draft is still longer than the TLS 1.2 RFC, = and seems
> > to demand support for every single usecase. This seems at odds wi= th
> > absolute simplification, where we would throw out less important<= br> > > features, and radically reduce the complexity.
>
> Got examples of features that could be removed or at least rendered > truly optional (besides things like 0RTT[1])?

Update: most connections are short-lived. Changing client au= th state during a connection: restarting works fine. The 1 RTT idea being p= roposed involves remembering unnecessary state.

AGL mentioned the ability to have fragmentation of Client He= llos in the record layer.

>
> > > Also, the proposed changes to the handshake state machine fo= r TLS 1.3
> > > are much larger. It seems we can't substantially simplif= y the protocol
> > > proportionately increasing the complexity of implementations= that need
> > > to also implement earlier versions.
> >
> > Adding new states and transitions to a state machine doesn't = increase
> > complexity that much: if the transition doesn't apply, you do= n't take
> > it. But adding additional special casing all over the place to de= al
> > with TLS 1.3 does increase complexity much more.
>
> Unfortunately, to fix the TLS handshaking mechanism, calls for handsha= ke
> totally different from one TLS 1.2 has.
>
> The overall architecture of TLS 1.3 handshake looks good to me, the > divisions it makes look to harden the handshake a lot against various<= br> > attacks. Unfortunately, the handshake currently looks to have rather l= arge
> implementation security gap.
>
> Additionally, in practice, the capablity to send a handshake that can<= br> > be downnegotiated is needed.

This should be doable without increasing the complexity of c= urrent code that much. The issue with the handshake isn't so much the p= arsing ( although nested length encoding is a bad idea, compared to length = encoded tokens) but the state machine. Adding new transitions and states ca= refully shouldn't be too bad.

Most implementations already keep a ruuning hash, so the enh= anced handshake prorocol can fit in. We should tighten up the description s= ignificantly, explaining exactly which steps are expected when.

Sincerely,
Watson Ladd

>
>
>
> [1] If 0RTT was an extension with positive acknowledgement, server cou= ld
> just leave it unimplemented and things would still work, albeit possib= ly
> with extra RTT.
>
>
>
> -Ilari

--001a1139d34a4def4a0511a7e9f5-- From nobody Thu Mar 19 11:28: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 3BE351A8AB6 for ; Thu, 19 Mar 2015 11:28:32 -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 PO18mwSqeWl6 for ; Thu, 19 Mar 2015 11:28:30 -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 700191A8AAE for ; Thu, 19 Mar 2015 11:28:30 -0700 (PDT) Received: by wifj2 with SMTP id j2so77024300wif.1 for ; Thu, 19 Mar 2015 11:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FbGEdTYcrAos+/qGnvFOvfQuheD1PhvxUkAbZSTc6eM=; b=PZLQxDir/dvnwuwAudq1vEk4pGWDUwJD6DcRkTNYIAcvRZ5m/QeWGwFqFvWJUxIpOJ 94RGKs3Kc13w5WE30rE2SbF9T7M2zqC1P/hta261eoaFiS3SRqPwinE5jDUq3RhTnxoX +5vaIKcZz/0vXU3GAF29TYd/L5UN1a0UOQQSmSOdLe6Vjv917SSDoK/FrjS3TPp5scQx 8QAGt4CXKeMZ/KFW9Q/6ijmUSraJUaKPpQSernBONelyPXDsFgXlMa6J4BDQWnnvkABS bmlMcwYK2pxAlTXc0WXOxe9OeOCVI3WOoKbF90nPuS8ammBfdv3VxKELsRSTMOhGl3rf jSFQ== X-Gm-Message-State: ALoCoQk7XjRGpKQLccZUEAJ47E7Lwlp1M5MkLYNI59UbQM6Rm6AmHZ57tcn8i0bY8K/SiYqJKS4W X-Received: by 10.180.77.19 with SMTP id o19mr18392974wiw.90.1426789709195; Thu, 19 Mar 2015 11:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 11:27:49 -0700 (PDT) In-Reply-To: References: <20150319174001.GA3690@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 19 Mar 2015 11:27:49 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d043c7f54c9403c0511a85d57 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:28:32 -0000 --f46d043c7f54c9403c0511a85d57 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 10:55 AM, Watson Ladd wrote: > > On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" > wrote: > > > > On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote: > > > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith > wrote: > > > > Watson Ladd wrote: > > > >> If we're going to make a change this > > > >> radical, why not make equally radical changes to simplify the > protocol > > > >> further if that's possible? > > > > > > > > That's already happening. > > > > > > No it's not: the draft is still longer than the TLS 1.2 RFC, and seems > > > to demand support for every single usecase. This seems at odds with > > > absolute simplification, where we would throw out less important > > > features, and radically reduce the complexity. > > > > Got examples of features that could be removed or at least rendered > > truly optional (besides things like 0RTT[1])? > > Update: most connections are short-lived. > At the interim we discussed having a simple re-key mechanism that was less general than Update. I think we could have that but nothing would also probably be fine. Changing client auth state during a connection: restarting works fine. > Would that this were so. Unfortunately, there are existing HTTP-based systems which rely on this feature and will be fairly put out if we don't supply it. That may not be a totally dispositive argument, but re-starting is not really a drop-in replacement. -Ekr --f46d043c7f54c9403c0511a85d57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 10:55 AM, Watson Ladd <watsonbladd@gmail.c= om> wrote:


On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi= > wrote:
>
> On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote:
> > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith <brian@briansmith.org> wrot= e:
> > > Watson Ladd <watsonbladd@gmail.com> wrote:
> > >> If we're going to make a change this
> > >> radical, why not make equally radical changes to simplif= y the protocol
> > >> further if that's possible?
> > >
> > > That's already happening.
> >
> > No it's not: the draft is still longer than the TLS 1.2 RFC, = and seems
> > to demand support for every single usecase. This seems at odds wi= th
> > absolute simplification, where we would throw out less important<= br> > > features, and radically reduce the complexity.
>
> Got examples of features that could be removed or at least rendered > truly optional (besides things like 0RTT[1])?

Update: most connections are short-lived.

At the interim we discussed having a simple re-key mechanism tha= t
was less general than Update. I think we could have that but no= thing
would also probably be fine.

Changing client auth state during a con= nection: restarting works fine.


Would = that this were so. Unfortunately, there are existing HTTP-based systems
which rely on this feature and will be fairly put out if we don'= t supply it. That may
not be a totally dispositive argument, but = re-starting is not really a drop-in
replacement.

-Ekr

--f46d043c7f54c9403c0511a85d57-- From nobody Thu Mar 19 11:31: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 080E91A87AB for ; Thu, 19 Mar 2015 11:31:14 -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 QqLdZDLkYE3a for ; Thu, 19 Mar 2015 11:31:08 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB90E1A8AB4 for ; Thu, 19 Mar 2015 11:31:07 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 70E21817FB; Thu, 19 Mar 2015 20:31:05 +0200 (EET) Date: Thu, 19 Mar 2015 20:31:05 +0200 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20150319183105.GA4192@LK-Perkele-VII> References: <20150319174001.GA3690@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] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:31:14 -0000 On Thu, Mar 19, 2015 at 10:55:54AM -0700, Watson Ladd wrote: > On Mar 19, 2015 10:40 AM, "Ilari Liusvaara" > wrote: > > > > On Thu, Mar 19, 2015 at 09:20:54AM -0700, Watson Ladd wrote: > > > On Thu, Mar 19, 2015 at 4:33 AM, Brian Smith > wrote: > > > > Watson Ladd wrote: > > > >> If we're going to make a change this > > > >> radical, why not make equally radical changes to simplify the > protocol > > > >> further if that's possible? > > > > > > > > That's already happening. > > > > > > No it's not: the draft is still longer than the TLS 1.2 RFC, and seems > > > to demand support for every single usecase. This seems at odds with > > > absolute simplification, where we would throw out less important > > > features, and radically reduce the complexity. > > > > Got examples of features that could be removed or at least rendered > > truly optional (besides things like 0RTT[1])? > > Update: most connections are short-lived. Changing client auth state during > a connection: restarting works fine. The 1 RTT idea being proposed involves > remembering unnecessary state. Update as an extension? I think splitting the secrets for both directions is a good idea: The secrets can be derived just before being needed (which cuts down oppurtunity for errors) and one can just derive the symmetric keys from both. Additionally, changing client auth state during a connection can be very dangerous (it depends on protocol riding on top and the context it runs in). Client-to-server IRCS? OK. HTTP/2 from web browser? Ouch. > AGL mentioned the ability to have fragmentation of Client Hellos in the > record layer. Doesn't seem to be really needed, except for certificate messages. No other messages seem to be large enough to warrant record-layer fragmentation under reasonable conditions. Heck, even dh8k keyshare message (which is likely the largest handshake message in practice aside of certificates) easily fits inside one IPv6 minMTU datagram, complete with all the needed headers. > > Unfortunately, to fix the TLS handshaking mechanism, calls for handshake > > totally different from one TLS 1.2 has. > > This should be doable without increasing the complexity of current code > that much. The issue with the handshake isn't so much the parsing ( > although nested length encoding is a bad idea, compared to length encoded > tokens) but the state machine. Adding new transitions and states carefully > shouldn't be too bad. > > Most implementations already keep a ruuning hash, so the enhanced handshake > prorocol can fit in. We should tighten up the description significantly, > explaining exactly which steps are expected when. Agreed, the endpoints should always know what is to be sent or received next (and anything else is an protocol error). A few weeks back I tried to construct a state machine for TLS 1.3. The nasty problem I ran into was handling the handshake "restart" (the state machine can't ever be allowed to loop). Also, client certificate handling caused problems. -Ilari From nobody Thu Mar 19 12:54: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 C489B1A8F40 for ; Thu, 19 Mar 2015 12:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN6YczmJ12Vc for ; Thu, 19 Mar 2015 12:53:55 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.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 1DCCD1A8848 for ; Thu, 19 Mar 2015 12:53:55 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so62946840obc.0 for ; Thu, 19 Mar 2015 12:53:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WtABsQURnUuoQ56VstGDzIg3+nVIrZtos8RF1zI6dZ0=; b=WqbfxaQ5XqXYnn9Yu4VwTHD39BTfta7I6PBMMOAL6Qt75EaEH1p4/gAWUWWywjWvkJ FnVDSszAi89huc62yek1OOUtxENeXuDTgg/MM2nnYUNL/MsDQGaWOO3gwQ06xKoq5ltM eyeKOUSHqh2pbO9LbHsbiQ4mYXsGXD8j2AiaVpw0EmBlRaUe6czUZCk6jm7JVxXMK0MP RjsabFjz3JggM6Vt1FVPEsXHemMUHtx3/vIjUTV0/lVFyI7POvX8b+G99ik6a23eNIxL XFWNnZ+jMQn1Ho6/8M2w7OfTGjx6PvaPEm3tGN4xPx8+VkOQn1Po/5+RYv0G+bAM7zIr emsA== X-Gm-Message-State: ALoCoQnKAxpjtCYgN3BaNyhKOC7JlEMAYk5uKwwZtjQ6JKLonkky5J4+GYv4AAeQV4M6qvn7dMET MIME-Version: 1.0 X-Received: by 10.182.85.225 with SMTP id k1mr27832222obz.20.1426794834624; Thu, 19 Mar 2015 12:53:54 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Thu, 19 Mar 2015 12:53:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 09:53:54 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:53:58 -0000 Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/155 > Target merge date: 3/21 My concern about this is the same one already raised on the CFRG mailing list: http://www.ietf.org/mail-archive/web/cfrg/current/msg04867.html in response to: http://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html In particular, massively parallel attacks on many keys at once seem like the most promising way to break AES-128. It seems bad to have popular endpoints encrypting the same plaintext block (e.g. "GET / HTTP/1.1\r\n") with the same nonce (1) with different keys. That seems like exactly the recipe for making such attacks succeed. It seems like it would be better, instead, to require that the initial nonces to be calculated from the keyblock established during key agreement, and then have them incremented as counters (with wraparound) in the same fashion as being proposed. This, combined with the fact that the key agreement will always be using ephemeral keys, should prevent any such massively-parallel attack from working. Note that this is a concern more for AES-128 than it is for ChaCha20 because ChaCha20 mitigates the issue by using a 256-bit key. Other than disagreeing with how the initial nonce is determined, I agree that the implicit counter approach is better than the explicit per-record nonce approach. I think this issue should be addressed before this change is made. Cheers, Brian From nobody Thu Mar 19 12:59: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 B65AB1A8F3E for ; Thu, 19 Mar 2015 12:59: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 z-usiasMnzUZ for ; Thu, 19 Mar 2015 12:59:12 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.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 BB9EC1A8881 for ; Thu, 19 Mar 2015 12:59:11 -0700 (PDT) Received: by wegp1 with SMTP id p1so66167502weg.1 for ; Thu, 19 Mar 2015 12:59: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=1fPtgCSfW5fsYioeQBBmxwCB4YmAFtG1z7g8+Cs/h5w=; b=QcJyMmm2/WuOivy6mHN5xdjjT1EGoHNoUKm+RNTi7ZU7tghOCl7bbWmOgErVnKE+4F HSNkMo/Tuxs/AbwcxA9S0e8nN42goICKBrqC6nS8FY3T/OUMZBwdhVcXzyJ7nMiRyMOb +GZc0J+mMwQ3jp/sPLX3wit3VOQpkcDUcyanongPtR0Zu8NeYaomhBOVHtCcDUWLSi7g lBFiAHfG128mIyyNHflo3E4vQbg4UeEwi+OBBbMkbZEUtekEHn9x8l80y+UMlhiDSKCx wSsB1eUtnZKtdJyVeXBw2nnXc+S5zR2l8xkbFHyY9r3imN3yKTalgbqsusXMEjHpKx+h LLGA== X-Gm-Message-State: ALoCoQmE3IThx3D9Oc+L3PTYZ+bzphSq9nFIQeS2kH7DK52xoghVpk0o2qZIgRNbSXt50Ip6mATm X-Received: by 10.194.185.68 with SMTP id fa4mr151925176wjc.111.1426795150469; Thu, 19 Mar 2015 12:59:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 12:58:30 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 19 Mar 2015 12:58:30 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=047d7bacb11e1cb5db0511a9a26a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:59:13 -0000 --047d7bacb11e1cb5db0511a9a26a Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith wrote: > Eric Rescorla wrote: > > PR: https://github.com/tlswg/tls13-spec/pull/155 > > Target merge date: 3/21 > > My concern about this is the same one already raised on the CFRG mailing > list: > http://www.ietf.org/mail-archive/web/cfrg/current/msg04867.html > in response to: > http://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html > > In particular, massively parallel attacks on many keys at once seem > like the most promising way to break AES-128. It seems bad to have > popular endpoints encrypting the same plaintext block (e.g. "GET / > HTTP/1.1\r\n") with the same nonce (1) with different keys. That seems > like exactly the recipe for making such attacks succeed. > Are other people concerned about this issue? I seem to remember this being discussed in the interim and AGL being opposed to this change. > It seems like it would be better, instead, to require that the initial > nonces to be calculated from the keyblock established during key > agreement, Is there any reason why these should be derived from the keyblock as opposed to from purely public information such as the random values? > and then have them incremented as counters (with > wraparound) in the same fashion as being proposed. Can you explain why you think they need to change? I note that TLS 1.2 currently does not behave in this fashion. -Ekr --047d7bacb11e1cb5db0511a9a26a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith <brian@briansmith.org= > wrote:
Eric Rescorla &= lt;ekr@rtfm.com> wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/155
> Target merge date: 3/21

My concern about this is the same one already raised on the CFRG mai= ling list:
=C2=A0 =C2=A0http://www.ietf.org/mail-archive/web/cfrg/c= urrent/msg04867.html
in response to:
=C2=A0 =C2=A0http://www.ietf.org/mail-archive/web/cfrg/c= urrent/msg04820.html

In particular, massively parallel attacks on many keys at once seem
like the most promising way to break AES-128. It seems bad to have
popular endpoints encrypting the same plaintext block (e.g. "GET /
HTTP/1.1\r\n") with the same nonce (1) with different keys. That seems=
like exactly the recipe for making such attacks succeed.

Are other people concerned about this issue? I seem to re= member this
being discussed in the interim and AGL being opposed = to this change.

=C2=A0
It seems like it would be better, instead, to require that the initial
nonces to be calculated from the keyblock established during key
agreement,

Is there any reason why these sh= ould be derived from the keyblock
as opposed to from purely publi= c information such as the random
values?

=C2=A0
and then have them incremented as counters (= with
wraparound) in the same fashion as being proposed.

Can you explain why you think they need to change? I note that TLS= 1.2
currently does not behave in this fashion.

-Ekr

--047d7bacb11e1cb5db0511a9a26a-- From nobody Thu Mar 19 13:11:45 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 784761A88BD for ; Thu, 19 Mar 2015 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mofzBXVP5bke for ; Thu, 19 Mar 2015 13:11:42 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (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 3AFD81A1B56 for ; Thu, 19 Mar 2015 13:11:41 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so43099744obc.2 for ; Thu, 19 Mar 2015 13:11:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h4TvR/4qsEpcLyRxwQmkLfjPNR+5vSygkfdHa1qFXd0=; b=UXxI/rHdE9U/kBuUt2E/XygSuhmo3m1Aw/lirHiLBftfrRBI+RywPrrVesJTFie0HY tNPs/QcN5MljxtFCtcqe2InLJmlKTTI1ZuGo0t14lonhXTm2t7zJbURGenU43t1F59vA vyt+QpBULjy1fffnxlhcdFHTynClZ90laHQa3LlX0tw+R91zvkOfXPYw2kvxa9fA0dMx rWWWlFmIbpRC/QQOJKEAh/FVbCPPuIKNvcYvmmiC8SHd9G1/bnBuoAlJAVFMRlbDdQ67 hrtMILQqSxrC3OQsa7IExmM1ZV01QVm9k9n/5pKHfyBcjW3svIdL0RpUvbZsEjaR/ejw fvYA== X-Gm-Message-State: ALoCoQlnLmJcJetJa/0+pD4JP41o+NTZNAzVYzgWwsqsSs09ipxlzA39bHqtVLjuRqGd9+/Yn/IG MIME-Version: 1.0 X-Received: by 10.182.85.225 with SMTP id k1mr27884615obz.20.1426795900492; Thu, 19 Mar 2015 13:11:40 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Thu, 19 Mar 2015 13:11:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 10:11:40 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:11:43 -0000 Eric Rescorla wrote: > On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith wrote: >> It seems like it would be better, instead, to require that the initial >> nonces to be calculated from the keyblock established during key >> agreement, > > Is there any reason why these should be derived from the keyblock > as opposed to from purely public information such as the random > values? Intuitively, I expect the attacker to have more difficulty if they don't know the nonce than if they do. In general, we should not divulge more than the minimum amount of information in cleartext. And, in particular, one of the design goals is to encrypt as much of the handshake as possible, and the nonce selection is part of the handshake. I wouldn't be surprised if somebody pointed out a good reason to avoid deriving them out of the key block, though I don't know of one now. >> and then have them incremented as counters (with >> wraparound) in the same fashion as being proposed. > > Can you explain why you think they need to change? I note that TLS 1.2 > currently does not behave in this fashion. I think you interpreted my suggested as || . I just mean that the per-record nonce should be calculated as + . It seems better to start all the initial bits of the nonce in a randomly-chosen state, instead of just a prefix, if there's no conflicting considerations to do otherwise. Cheers, Brian From nobody Thu Mar 19 13:18: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 941791A901F for ; Thu, 19 Mar 2015 13:18:44 -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 j3n7HXAHOjdq for ; Thu, 19 Mar 2015 13:18:43 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (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 7A74C1A1B56 for ; Thu, 19 Mar 2015 13:18:34 -0700 (PDT) Received: by wgra20 with SMTP id a20so72303849wgr.3 for ; Thu, 19 Mar 2015 13:18:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lyQUgIO8dTWl4M8USFt/u/p4/IuB52rXVGRd8WMQ+Lw=; b=TH/KEeADTzahMpF5sQUpOvINPt4pYzOuQPEZXMIMmhztZ2DSLERZr8Ggt4XuferwjN k95iNVT/EMwzk0aFYGQsZOFurNUXmMsj56utxzUhbUJjgKS/jzWQAOJ95QAe8DR0R+mt pjcMkFFQP6+gpZbBCAUd2pjcO1B/ktNZlZetp+ExVIAOSne4DwFgbQ69ypKsCtFBVel4 2n/3bHAb2AzRup76XRRO5/6i9ZM5LItf3HVd6P5UiHhYwyzmJCAz5PEhXlM8ctYoWPnB NgH4w1apkqJ3l6YyXwHqwi2nmRRmQOled4SKuwni8UON7vXYVgd0OXCpdvswDjCDKLd6 56JQ== X-Gm-Message-State: ALoCoQlZLfT+fgIVMx6qvyqdLdWaYDcRij+Rz4anWi2JtG4sZ77xstnToxPBmvcsF5U+fD6QkBYZ X-Received: by 10.194.159.105 with SMTP id xb9mr103441512wjb.156.1426796313194; Thu, 19 Mar 2015 13:18:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Thu, 19 Mar 2015 13:17:51 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 19 Mar 2015 13:17:51 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=001a11c3aa586a47480511a9e761 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:18:44 -0000 --001a11c3aa586a47480511a9e761 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 1:11 PM, Brian Smith wrote: > Eric Rescorla wrote: > > On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith > wrote: > >> It seems like it would be better, instead, to require that the initial > >> nonces to be calculated from the keyblock established during key > >> agreement, > > > > Is there any reason why these should be derived from the keyblock > > as opposed to from purely public information such as the random > > values? > > Intuitively, I expect the attacker to have more difficulty if they > don't know the nonce than if they do. In general, we should not > divulge more than the minimum amount of information in cleartext. And, > in particular, one of the design goals is to encrypt as much of the > handshake as possible, and the nonce selection is part of the > handshake. > > I wouldn't be surprised if somebody pointed out a good reason to avoid > deriving them out of the key block, though I don't know of one now. > > >> and then have them incremented as counters (with > >> wraparound) in the same fashion as being proposed. > > > > Can you explain why you think they need to change? I note that TLS 1.2 > > currently does not behave in this fashion. > > I think you interpreted my suggested as || sequence number>. I did. It doesn't help here that TLS uses '+' for concatenation :( > I just mean that the per-record nonce should be > calculated as + . It seems > better to start all the initial bits of the nonce in a randomly-chosen > state, instead of just a prefix, if there's no conflicting > considerations to do otherwise. > So to be clear we would generate a random V of length N_MIN and then for each record the nonce would be SN + V? -Ekr > Cheers, > Brian > --001a11c3aa586a47480511a9e761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 1:11 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith <brian@briansmith.org> wrote:
>> It seems like it would be better, instead,= to require that the initial
>> nonces to be calculated from the keyblock established during key >> agreement,
>
> Is there any reason why these should be derived from the keyblock
> as opposed to from purely public information such as the random
> values?

Intuitively, I expect the attacker to have more difficulty if they don't know the nonce than if they do. In general, we should not
divulge more than the minimum amount of information in cleartext. And,
in particular, one of the design goals is to encrypt as much of the
handshake as possible, and the nonce selection is part of the
handshake.

I wouldn't be surprised if somebody pointed out a good reason to avoid<= br> deriving them out of the key block, though I don't know of one now.

>> and then have them incremented as counters (with
>> wraparound) in the same fashion as being proposed.
>
> Can you explain why you think they need to change? I note that TLS 1.2=
> currently does not behave in this fashion.

I think you interpreted my suggested as <initial-nonce> || <= ;record
sequence number>.

I did. It doesn't= help here that TLS uses '+' for concatenation :(


=C2=A0
I just m= ean that the per-record nonce should be
calculated as <initial-nonce> + <record sequence number>. It se= ems
better to start all the initial bits of the nonce in a randomly-chosen
state, instead of just a prefix, if there's no conflicting
considerations to do otherwise.

So to b= e clear we would generate a random V of length
N_MIN and then for= each record the nonce would be=C2=A0
SN + V?


-Ekr
=C2=A0
Cheers,
Brian

--001a11c3aa586a47480511a9e761-- From nobody Thu Mar 19 13:25: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 AB7241A9060 for ; Thu, 19 Mar 2015 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df-bC7S7jnS7 for ; Thu, 19 Mar 2015 13:25:22 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 E6B461A905F for ; Thu, 19 Mar 2015 13:25:21 -0700 (PDT) Received: by lamx15 with SMTP id x15so71852903lam.3 for ; Thu, 19 Mar 2015 13:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5DtTS3qQZ0zIQeau8xXaMMS5YdQlw/hfceUGSdQfj58=; b=1G/5uST2t6SxcAQd/UxH/MBVZXLjHDiNmMYg4XVUvXcj9CjaFCyPC5vVQZ9il+3ZNi WXy4tt41ZNtcuLvKHT8iOj3jr5CIPdT1/1zR3vPZ9BKvivOYRhJ5R6cSkZtPsEZ8jPjA yUU/3EA9tmpZW8aA1PDfzT9iip9n3ciqCLzjN9CdFCyH4IQafHqk26SjAV7KI7cQIS+y sEKHHU25gTmT8pb6zrGRghw09dGfgGjzruC77/EebZ5gqu8cR99NLoNfMMgqrTf6HONH 7w5kAxb8ZhGWScxW+XnmAlsPj2sxzaQtF89+XCutffrCUztBWkv0n6jj1frF/2na9zbq IBtg== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr71366989lad.124.1426796720380; Thu, 19 Mar 2015 13:25:20 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.55.71 with HTTP; Thu, 19 Mar 2015 13:25:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Mar 2015 13:25:20 -0700 X-Google-Sender-Auth: GP3HT1_kzrnBJqIblkRHqr0xfP0 Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:25:23 -0000 On Thu, Mar 19, 2015 at 12:58 PM, Eric Rescorla wrote: > Are other people concerned about this issue? I seem to remember this > being discussed in the interim and AGL being opposed to this change. I would phrase it as an extended key to the AEAD and keep the nonce the same, but I'm not opposed so starting at a random point in the nonce space and counting from there. However, since the AES-GCM AEAD is already defined I can see the practical argument for having TLS do the nonce masking. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 19 13:31: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 771B41A906D for ; Thu, 19 Mar 2015 13:31:45 -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 OzFbuRhfQ6bm for ; Thu, 19 Mar 2015 13:31:43 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F451A9067 for ; Thu, 19 Mar 2015 13:31:42 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 2F8B781807; Thu, 19 Mar 2015 22:31:41 +0200 (EET) Date: Thu, 19 Mar 2015 22:31:41 +0200 From: Ilari Liusvaara To: Brian Smith Message-ID: <20150319203141.GA10457@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] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:31:45 -0000 On Thu, Mar 19, 2015 at 10:11:40AM -1000, Brian Smith wrote: > Eric Rescorla wrote: > > On Thu, Mar 19, 2015 at 12:53 PM, Brian Smith wrote: > >> It seems like it would be better, instead, to require that the initial > >> nonces to be calculated from the keyblock established during key > >> agreement, > > > > Is there any reason why these should be derived from the keyblock > > as opposed to from purely public information such as the random > > values? > > Intuitively, I expect the attacker to have more difficulty if they > don't know the nonce than if they do. In general, we should not > divulge more than the minimum amount of information in cleartext. And, > in particular, one of the design goals is to encrypt as much of the > handshake as possible, and the nonce selection is part of the > handshake. > > I wouldn't be surprised if somebody pointed out a good reason to avoid > deriving them out of the key block, though I don't know of one now. As to what other protocols do with GCM, both SSH and IPSec do derive initial nonce out of key block (like TLS 1.2 does). As to supporting "hardware", there are values in TLS that are both public and have to be derived from key block, so any HSM has to know about TLS to be able to know what should be exportable and what isn't. And if the HSM accepts arbitrary nonces, one can break the encryption fast. > >> and then have them incremented as counters (with > >> wraparound) in the same fashion as being proposed. > > > > Can you explain why you think they need to change? I note that TLS 1.2 > > currently does not behave in this fashion. > > I think you interpreted my suggested as || sequence number>. I just mean that the per-record nonce should be > calculated as + . It seems > better to start all the initial bits of the nonce in a randomly-chosen > state, instead of just a prefix, if there's no conflicting > considerations to do otherwise. As to what other protocols do with GCM, SSH derives a full block and increments that. IPSec derives just a prefix (like TLS 1.2). -Ilari From nobody Sat Mar 21 11:58: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 864501A1BF5 for ; Sat, 21 Mar 2015 11:58: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 eMddYOBXlOqb for ; Sat, 21 Mar 2015 11:58:48 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 84B861A3BA5 for ; Sat, 21 Mar 2015 11:58:47 -0700 (PDT) Received: by wgra20 with SMTP id a20so114648825wgr.3 for ; Sat, 21 Mar 2015 11:58:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kqkUDjuvcMJ9771uVevtaHjdwWSDhhgoBuNBn4ZuGA0=; b=hp/9Oul0XkTm9lCSuQ+0FpXVGS4XTVWnlcowerlE0dPHlqAJkYc40g7GGEcQsavqN+ iN5Pym4YWMBdJa/nnaydgc+NUCxKbr/x0/p0cjz0lCx2fU+0FyqR2h86KlrRfDpAgs4D jbR85p9YBN1/h1sdc70ikyHWf+4CJmRUxBF82QI/lsLNNvLEl3kBfazYySywzG9h24aC 6B5fm+XJ9jhk0zKfWaIl1sW1ECVfCc+E/dzbiyqmXUDXSFZkX3rAfc6sS4ZiRj9SeivL 1FdEbmVNWiXwSATYnEVws5AopzPvoFjCXL4a1YcWAoZfBjjEnaFNVbMGzWCHHk9jztaA 2/Fg== X-Gm-Message-State: ALoCoQmynLUqf+FHupc/ujgjYIn3TdV64tecn4J6zDX2HrJcDL7+xoNjKHQmxbPOOqfOKAB3afiC X-Received: by 10.180.19.73 with SMTP id c9mr6433062wie.10.1426964326288; Sat, 21 Mar 2015 11:58:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 21 Mar 2015 11:58:06 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 21 Mar 2015 11:58:06 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=bcaec53d546fc6a3160511d1050f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2015 18:58:49 -0000 --bcaec53d546fc6a3160511d1050f Content-Type: text/plain; charset=UTF-8 Adam, Brian, what would you think of XOR rather than addition? E.g., generate a per-connection value V and then do: Nonce = Seq XOR V? -Ekr On Thu, Mar 19, 2015 at 1:25 PM, Adam Langley wrote: > On Thu, Mar 19, 2015 at 12:58 PM, Eric Rescorla wrote: > > Are other people concerned about this issue? I seem to remember this > > being discussed in the interim and AGL being opposed to this change. > > I would phrase it as an extended key to the AEAD and keep the nonce > the same, but I'm not opposed so starting at a random point in the > nonce space and counting from there. However, since the AES-GCM AEAD > is already defined I can see the practical argument for having TLS do > the nonce masking. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > --bcaec53d546fc6a3160511d1050f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam, Brian, what would you think of XOR rather than addit= ion?

E.g., generate a per-connection value V and then do= :

Nonce =3D Seq XOR V?

-Ekr=


On Thu, Mar 19, 2015 at 1:25 PM, Adam Langley <agl@i= mperialviolet.org> wrote:
<= span class=3D"">On Thu, Mar 19, 2015 at 12:58 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Are other people concerned about this issue? I seem to remember this > being discussed in the interim and AGL being opposed to this change.
I would phrase it as an extended key to the AEAD and keep the nonce<= br> the same, but I'm not opposed so starting at a random point in the
nonce space and counting from there. However, since the AES-GCM AEAD
is already defined I can see the practical argument for having TLS do
the nonce masking.


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https:/= /www.imperialviolet.org

--bcaec53d546fc6a3160511d1050f-- From nobody Sat Mar 21 12:20: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 31CF81A7023 for ; Sat, 21 Mar 2015 12:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpDytiCzef7E for ; Sat, 21 Mar 2015 12:20:29 -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 26D2A1A7021 for ; Sat, 21 Mar 2015 12:20:26 -0700 (PDT) Received: by labon10 with SMTP id on10so8069429lab.2 for ; Sat, 21 Mar 2015 12:20:24 -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=r51VzgehTAdDJFaFYYrqaWanC3N1uTtAZfdchqxbCis=; b=MjWK3OqRpQA1ohA+yESsUjwhLdWLVXALp19vcA/DkGpXpkbPOUY5DAeyzCMWUyjtws +rHBDVXkomy3JYtNLmDMmfyDIwtDeWUNhqfJEGnm6o7CzG3k0DFYNM6IgKuOH1QNE7oT ta5nyu3oU5vj7bIFA3SSjwtcspNjuR0LYH6Ebdoe9z/XODouwlwqUx519rTiO/29qc8S ieVDf6M+d4PzM6pAUlruwOl/o6++zswk8uUmyqJC6ODGWGDcME0Rbl0JtPCyaqKRNryQ 6cDIfbUZDoRVTazyJYLNSe16kMrRjBmp4jml2HaIfcNSvwbmYxpItuMY7EIUQjfzIoyq MBUw== MIME-Version: 1.0 X-Received: by 10.152.181.197 with SMTP id dy5mr78302149lac.57.1426965624685; Sat, 21 Mar 2015 12:20:24 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.55.71 with HTTP; Sat, 21 Mar 2015 12:20:24 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Mar 2015 12:20:24 -0700 X-Google-Sender-Auth: Qb4cNNhBvGiYlKpnIJilrvLMjE0 Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2015 19:20:30 -0000 On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla wrote: > Adam, Brian, what would you think of XOR rather than addition? > > E.g., generate a per-connection value V and then do: > > Nonce = Seq XOR V? It's invertable so can't break uniqueness. So that would be ok too. Is V a 12-byte (or whatever) value and thus fixes the upper 4 (or whatever) bytes of the nonce? Cheers AGL From nobody Sat Mar 21 12:23: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 654771A86E3 for ; Sat, 21 Mar 2015 12:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKxX8n355J9T for ; Sat, 21 Mar 2015 12:23:26 -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 F3D511A7D82 for ; Sat, 21 Mar 2015 12:23:25 -0700 (PDT) Received: by wixw10 with SMTP id w10so10839366wix.0 for ; Sat, 21 Mar 2015 12:23:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5NgAfhY1V/Tn0B0p3Bn2ek6ifiQSxaoA5Vuiczs/BqI=; b=W3+wFBlzLXegzanpFHMr++T374v7zchNArRO2rVf48Kw7jy6z/Z6StKjNYVJo/CmNk stjF5/2j9R605d3g1CgvgRL2N/TES1buTeaahnQJ2dOpm9KpXU9hBbqcCBmRzn2GOn+S ZAvryeHdEvG9yNnLv/yKfMOrK+oFQpzlSdR1LvEnATgXrMuOuhRp6rs4lQ2vhcw5Tq1C C78cDHCF056Ext2IllZaPIsngZSD9HNu72RKjK/fO2hRC6lQ8dLDK1XMp5oV2ilrjepy 2JoAgtrjfq21EmINQLufVrV1RlQIsA7+3nipr3VkDR4FzfDfxrElCc9tHFx02+SMTtny y+VQ== X-Gm-Message-State: ALoCoQn9SlgJtba5cmFOLeKuHK0TCaibjLcv7X98dqYxj0QxCq+6+IDvpiVrChBGJkFNy1hvD95T X-Received: by 10.180.106.103 with SMTP id gt7mr6389199wib.59.1426965804741; Sat, 21 Mar 2015 12:23:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 21 Mar 2015 12:22:44 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 21 Mar 2015 12:22:44 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=f46d04428f44e60d2a0511d15da8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2015 19:23:27 -0000 --f46d04428f44e60d2a0511d15da8 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 21, 2015 at 12:20 PM, Adam Langley wrote: > On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla wrote: > > Adam, Brian, what would you think of XOR rather than addition? > > > > E.g., generate a per-connection value V and then do: > > > > Nonce = Seq XOR V? > > It's invertable so can't break uniqueness. So that would be ok too. Is > V a 12-byte (or whatever) value and thus fixes the upper 4 (or > whatever) bytes of the nonce? > I was thinking that we would generate an N_MIN long V and XOR it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed. -Ekr --f46d04428f44e60d2a0511d15da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 21, 2015 at 12:20 PM, Adam Langley <agl@imperialviole= t.org> wrote:
On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Adam, Brian, what would you think of XOR rather than addition?
>
> E.g., generate a per-connection value V and then do:
>
> Nonce =3D Seq XOR V?

It's invertable so can't break uniqueness. So that would be = ok too. Is
V a 12-byte (or whatever) value and thus fixes the upper 4 (or
whatever) bytes of the nonce?

I was thi= nking that we would generate an N_MIN long V and XOR
it with Seq.= So, yes, N_MAX - 8 bytes would be effectively fixed.

<= div>-Ekr


--f46d04428f44e60d2a0511d15da8-- From nobody Sat Mar 21 12:54: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 95F2F1A0193 for ; Sat, 21 Mar 2015 12:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_51=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEQZfD__SBR8 for ; Sat, 21 Mar 2015 12:54:00 -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 DE4381A001C for ; Sat, 21 Mar 2015 12:53:59 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id B32C71A25CF; Sat, 21 Mar 2015 21:53:56 +0200 (EET) Date: Sat, 21 Mar 2015 21:53:56 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150321195356.GA5190@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: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2015 19:54:01 -0000 On Sat, Mar 21, 2015 at 12:22:44PM -0700, Eric Rescorla wrote: > On Sat, Mar 21, 2015 at 12:20 PM, Adam Langley > wrote: > > > On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla wrote: > > > Adam, Brian, what would you think of XOR rather than addition? > > > > > > E.g., generate a per-connection value V and then do: > > > > > > Nonce = Seq XOR V? > > > > It's invertable so can't break uniqueness. So that would be ok too. Is > > V a 12-byte (or whatever) value and thus fixes the upper 4 (or > > whatever) bytes of the nonce? > > > > I was thinking that we would generate an N_MIN long V and XOR > it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed. A few thing to note: - RFC5116 allows N_MIN=0, which means the scheme can operate without nonces, but there doesn't seem to be any such registered algorithms. - There are registred AEAD algorithms with N_MIN<8, N_MAX>8. - Some registered algorithms have huge N_MAX. -Ilari From nobody Sat Mar 21 13:04: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 567741A8A95 for ; Sat, 21 Mar 2015 13:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_51=1, 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 LpJ90qR0F8Rg for ; Sat, 21 Mar 2015 13:04:45 -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 142621A8782 for ; Sat, 21 Mar 2015 13:04:45 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so20446322wib.1 for ; Sat, 21 Mar 2015 13:04: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=6ZvyQaN08b8tMByXeozlUFxCRCDOLh7HIS+d0wgAx+o=; b=NY1ufl24tBGzsA2ESKTiNVEIzYbn0Us/2knexiTAGikA2+3ycwPqca2WKQZLmS1Rtj velUNG+9VEW2lEkAVcwVfUTjCz3ZDJXGDkQgI1f2m60ScQ89cr6M+espCdIFR3x4MbzW KTOg9kdFQ98WKU+OnopF3tzxRavhju2lc2N+c4P9CrV2GvHiKWOt4l0AlEiy8U/UaHDL 0DRX3+U0WVbOtVlYfTUiVd5Dn5xbQ4ZiW1k1JSOFUcTYvVFG1d8L9d7t/nefm1OVc8AF ZUz10XLsCdiu6uH6fPgAnpae1G4GGUDJnZNSBZnUfIp9ZQBP6AqJhca9ZPKIdiFtMa5j 9ljg== X-Gm-Message-State: ALoCoQnvkpcnCMeug9D9O5EkGL1G3GZidzlySli94GAE0i1zxTHpPZTMTQpW/rIc7eYiO20I7pm5 X-Received: by 10.194.235.71 with SMTP id uk7mr173445773wjc.13.1426968283816; Sat, 21 Mar 2015 13:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sat, 21 Mar 2015 13:04:03 -0700 (PDT) In-Reply-To: <20150321195356.GA5190@LK-Perkele-VII> References: <20150321195356.GA5190@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 21 Mar 2015 13:04:03 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e01493afaa9bdfa0511d1f14b Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2015 20:04:46 -0000 --089e01493afaa9bdfa0511d1f14b Content-Type: text/plain; charset=UTF-8 On Sat, Mar 21, 2015 at 12:53 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Sat, Mar 21, 2015 at 12:22:44PM -0700, Eric Rescorla wrote: > > On Sat, Mar 21, 2015 at 12:20 PM, Adam Langley > > wrote: > > > > > On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla wrote: > > > > Adam, Brian, what would you think of XOR rather than addition? > > > > > > > > E.g., generate a per-connection value V and then do: > > > > > > > > Nonce = Seq XOR V? > > > > > > It's invertable so can't break uniqueness. So that would be ok too. Is > > > V a 12-byte (or whatever) value and thus fixes the upper 4 (or > > > whatever) bytes of the nonce? > > > > > > > I was thinking that we would generate an N_MIN long V and XOR > > it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed. > I meant N_MIN here, btw. > A few thing to note: > > - RFC5116 allows N_MIN=0, which means the scheme can operate without > nonces, but there doesn't seem to be any such registered algorithms. > - There are registred AEAD algorithms with N_MIN<8, N_MAX>8. > This is the one that concerns me (though the general problem is a concern for all of these). Perhaps instead use max(N_MIN, 8)? -Ekr > - Some registered algorithms have huge N_MAX. --089e01493afaa9bdfa0511d1f14b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 21, 2015 at 12:53 PM, Ilari Liusvaara <= ;ilari.liu= svaara@elisanet.fi> wrote:
=
On Sat, Mar 21, 2015 at 12:22:44PM = -0700, Eric Rescorla wrote:
> On Sat, Mar 21, 2015 at 12:20 PM, Adam Langley <agl@imperialviolet.org>
> wrote:
>
> > On Sat, Mar 21, 2015 at 11:58 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> > > Adam, Brian, what would you think of XOR rather than additio= n?
> > >
> > > E.g., generate a per-connection value V and then do:
> > >
> > > Nonce =3D Seq XOR V?
> >
> > It's invertable so can't break uniqueness. So that would = be ok too. Is
> > V a 12-byte (or whatever) value and thus fixes the upper 4 (or > > whatever) bytes of the nonce?
> >
>
> I was thinking that we would generate an N_MIN long V and XOR
> it with Seq. So, yes, N_MAX - 8 bytes would be effectively fixed.
<= /div>

I meant N_MIN here, btw.
<= div>
=C2=A0
A few thing to note:

- RFC5116 allows N_MIN=3D0, which means the scheme can operate without
=C2=A0 nonces, but there doesn't seem to be any such registered algorit= hms.
- There are registred AEAD algorithms with N_MIN<8, N_MAX>8.

This is the one that concerns me (though the ge= neral problem is a concern
for all of these).

Perhaps instead use max(N_MIN, 8)?

-Ekr

=C2=A0
- Some registered algorithms have huge N_MAX.


--089e01493afaa9bdfa0511d1f14b-- From nobody Sun Mar 22 02:39: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 A6B561A1B71; Sat, 21 Mar 2015 23:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 qVgJUdzdyUeE; Sat, 21 Mar 2015 23:29:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C661A1B1C; Sat, 21 Mar 2015 23:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3695; q=dns/txt; s=iport; t=1427005786; x=1428215386; h=from:to:cc:subject:date:message-id:mime-version; bh=5lVpdEC/8mmclqnk/tKQ4N8EoPuseh2LJDLKadts1fA=; b=eoMlu3NM7vjTafGsw3VtY3GrRERY+XVou5Y7wRdF5IjKo/jTQUOdYfxi 5iGBchShw77RgQdNSXECXjwhaV2T6JSIysmi6Vz5b+9BTlqTUYvXTJLE6 S3mICu2dA72phQTj1DFEGcY34fTvtHV/acci/6pPDFNFFU/WSnT2f1YDO o=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBQCqaeJU/5BdJa1RCoMGgTCCf8UugRpDAQEBAQEBfIQTI1YSAUoCNCcEDhMGiBm3KJcNAQEBAQEBAQEBAQEBAQEBAQEbjxcGCwFQgm8ugRQFjziBWoEuhi+BGIsuhkcigX0FHIFQgXo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,445,1422921600"; d="asc'?scan'208";a="405431452" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 22 Mar 2015 06:29:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2M6TjDr015022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Mar 2015 06:29:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 01:29:45 -0500 From: "Fred Baker (fred)" To: "ops-dir@ietf.org" Thread-Topic: ops review of draft-ietf-tls-sslv3-diediedie Thread-Index: AQHQZGmWpARkpZLGW0mpB3eKsQYLpw== Date: Sun, 22 Mar 2015 06:29:44 +0000 Message-ID: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.4.20] Content-Type: multipart/signed; boundary="Apple-Mail=_F33CC1A6-747E-40F3-93F3-037D207CCC16"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 02:39:16 -0700 Cc: "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" , "tls@ietf.org" Subject: [TLS] ops review of draft-ietf-tls-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 06:29:47 -0000 --Apple-Mail=_F33CC1A6-747E-40F3-93F3-037D207CCC16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the Operational directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call = may be included in AD reviews during the IESG review. Document editors = and WG chairs should treat these comments just like any other last call = comments. Summary: The document, as set forth in its name, makes a specific recommendation = regarding SSL v3 and by extension all of its versions: "die die die=E2=80=9D= . It gives specific reasons for that recommendation, in terms of = manifest insecurity, attacks, and general unworthiness of trust. It also answers a question I have had, which is why TLS didn't naturally = replace SSL a long time ago. Specific parameters necessary to that = negotiation had not been adequately specified. The document makes an = assertion that I understand to be the long-standing consensus of the = security community: that any version of TLS is more secure than any = version of SSL, and as version numbers increase, TLS itself becomes more = secure. In short, it recommends that implementations that use SSL update to use = TLS, and that operators of applications using SSL lean on their vendors = or implementors to make the conversion or change to other software = packages. Operational impact: By implication, administrators of applications need to determine whether = their applications are using SSL, and if so upgrade them. The audit is = probably most easily accomplished using a web page lookup or email = exchange; the specifications for the application will say what they use, = and if they have made the conversion, identify in what release they did = so. It should then be straightforward for the administrator to determine = what version they are running. One implication that the document doesn=E2=80=99t bring out directly, = but which follows from the discussion of the attacks, is that any key or = certificate that has been exchanged using SSL may have been compromised = via a man-in-the-middle attack, and is therefore suspect. Such = certificates and keys should be replaced. The upgrade process itself may be more painful; the administrator will = need to qualify the updated software for his/her use case, and may need = to correspond with the vendor or author. This is something = administrators generally know how to do, however, so it should not be a = blocking issue. My assessment: The document is clearly written and well argued, and the = issues are clearly laid out. It is therefore good to go. --Apple-Mail=_F33CC1A6-747E-40F3-93F3-037D207CCC16 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVQ4vc59ieig10VPpAQIU8Af9Gn4Oo4dEs39PRHQ/m9vqhjXBwHzMf3Sb 3u+iKjDjuJt+Yxz3xhVAdHlj+M2H66qPsEmwKZrAVUJ2Cvv6e2Oo0Uxx1Ln43v+a aQ7rRBZj3KwqzoJ+o2Q2C33TI5uW1X35YeWAwWpekJiSPngi1scs7rhhxPUw2fHq qpK6Clc4WToN4Zo5k9cqYgIflny+eYEaWVP2p38JRsHOdiZa0KkClBJHbOfWTDfH gr3uqJX96vZnvabOCu2kE+bfGpYwiVBH9Q9RA52s1lxweppHEc0VWqI338CCCirq e8tMJXoJpEUuLPSnikNEm78Z9V3EYgk8BaVHVGjX3M7WqndZio5KJA== =QYIa -----END PGP SIGNATURE----- --Apple-Mail=_F33CC1A6-747E-40F3-93F3-037D207CCC16-- From nobody Sun Mar 22 05:30: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 5E53C1A908E; Sun, 22 Mar 2015 05:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T0CZ727gizx; Sun, 22 Mar 2015 05:30:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 B862E1A908F; Sun, 22 Mar 2015 05:30:45 -0700 (PDT) Received: from mb-aye.local (ip-64-134-6-222.public.wayport.net [64.134.6.222]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2MCUfm8001322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Mar 2015 12:30:42 GMT (envelope-from joelja@bogus.com) To: "Fred Baker (fred)" , "ops-dir@ietf.org" references: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> From: joel jaeggli message-id: <550EB5EB.2080609@bogus.com> Date: Sun, 22 Mar 2015 07:30:35 -0500 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIsibiwWufo32VcwfHxMm931Ts0soeBkf" Archived-At: Cc: "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [OPS-DIR] ops review of draft-ietf-tls-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 12:30:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DIsibiwWufo32VcwfHxMm931Ts0soeBkf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks fred! joel On 3/22/15 1:29 AM, Fred Baker (fred) wrote: > I have reviewed this document as part of the Operational directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call = may be included in AD reviews during the IESG review. Document editors an= d WG chairs should treat these comments just like any other last call com= ments. >=20 > Summary: >=20 > The document, as set forth in its name, makes a specific recommendation= regarding SSL v3 and by extension all of its versions: "die die die=94. = It gives specific reasons for that recommendation, in terms of manifest i= nsecurity, attacks, and general unworthiness of trust. >=20 > It also answers a question I have had, which is why TLS didn't naturall= y replace SSL a long time ago. Specific parameters necessary to that nego= tiation had not been adequately specified. The document makes an assertio= n that I understand to be the long-standing consensus of the security com= munity: that any version of TLS is more secure than any version of SSL, a= nd as version numbers increase, TLS itself becomes more secure. >=20 > In short, it recommends that implementations that use SSL update to use= TLS, and that operators of applications using SSL lean on their vendors = or implementors to make the conversion or change to other software packag= es. >=20 > Operational impact: >=20 > By implication, administrators of applications need to determine whethe= r their applications are using SSL, and if so upgrade them. The audit is = probably most easily accomplished using a web page lookup or email exchan= ge; the specifications for the application will say what they use, and if= they have made the conversion, identify in what release they did so. It = should then be straightforward for the administrator to determine what ve= rsion they are running. >=20 > One implication that the document doesn=92t bring out directly, but whi= ch follows from the discussion of the attacks, is that any key or certifi= cate that has been exchanged using SSL may have been compromised via a ma= n-in-the-middle attack, and is therefore suspect. Such certificates and k= eys should be replaced. >=20 > The upgrade process itself may be more painful; the administrator will = need to qualify the updated software for his/her use case, and may need t= o correspond with the vendor or author. This is something administrators = generally know how to do, however, so it should not be a blocking issue. >=20 > My assessment: The document is clearly written and well argued, and the= issues are clearly laid out. It is therefore good to go. >=20 >=20 >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 --DIsibiwWufo32VcwfHxMm931Ts0soeBkf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUOtewACgkQ8AA1q7Z/VrLy/ACeNOH0pbKzVeItpG9KIAe59lOP yNUAnA3RB2SauivMdBVEclu/zwO9Sc30 =saaG -----END PGP SIGNATURE----- --DIsibiwWufo32VcwfHxMm931Ts0soeBkf-- From nobody Sun Mar 22 05:43: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 C0B611A9098; Sun, 22 Mar 2015 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMc3CWvpXn87; Sun, 22 Mar 2015 05:43:45 -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 4891B1A9096; Sun, 22 Mar 2015 05:43:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19E4EBECC; Sun, 22 Mar 2015 12:43:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFZje8fMINNq; Sun, 22 Mar 2015 12:43:43 +0000 (GMT) Received: from [31.133.142.144] (dhcp-8e90.meeting.ietf.org [31.133.142.144]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38C38BEC0; Sun, 22 Mar 2015 12:43:42 +0000 (GMT) Message-ID: <550EB8F2.10203@cs.tcd.ie> Date: Sun, 22 Mar 2015 12:43:30 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , "ops-dir@ietf.org" References: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> In-Reply-To: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OQCFxgrnN3HpwJBLXuqxQiMhtKDsEMnaI" Archived-At: Cc: "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" , "tls@ietf.org" Subject: Re: [TLS] ops review of draft-ietf-tls-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 12:43:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OQCFxgrnN3HpwJBLXuqxQiMhtKDsEMnaI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Fred for the thoughtful review. I think one thing is worth double-checking. You said: On 22/03/15 06:29, Fred Baker (fred) wrote: > One implication that the document doesn=E2=80=99t bring out directly, b= ut > which follows from the discussion of the attacks, is that any key or > certificate that has been exchanged using SSL may have been > compromised via a man-in-the-middle attack, and is therefore suspect. > Such certificates and keys should be replaced I don't think that is the case, as SSL's imperfections bad as they are, don't expose long-term (private) keying material. But it is worth checking. Short-term keys will naturally be replaced without any operator action in any SSL->TLS transition I think. And any trust anchors that were accepted via self-signed certificates will be as good or bad as ever and are probably best left alone if one isn't changing s/w but just a config. So I don't see an operator action here that we ought document in this draft. But if there were things operators ought do, that are not purely implementation specific issues, then I think those'd be worth noting in the document, so this is just to check that. If someone knows of such, please send text and the WG can process that. As the relevant AD, I'll interpret silence here as "no change needed." Cheers, S. --OQCFxgrnN3HpwJBLXuqxQiMhtKDsEMnaI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVDrj8AAoJEC88hzaAX42inMcH/26ILD8GiXZAfmO5elu1zg9j wn4qor+FHkscRTPT9MlzGnk+QbyLJhScREsA4K5FD6EyDh6xzqHgvPy346wYW/KK 0B07IOg7YTAz+IpHyJvz9ha0MyLAC8VbAKipo2Cxj79lhWulj9KFGYHtPgmRT13x srM3kjeYRsRn3i5ARUKXJeI79r8xGPwL4++GwTND3O1fXx8UY2l5VDSjY6qWKx30 JarRsL9fYEqZO4CqEvzlOirkosl6ow7ulRtKJ20AXCAmEbt35tcqq80lAcJS+Un5 OYO6V8aqK7damKtc42Z47QsoV+9ZI6F6SnlYVNJYHKiaRtIcLkSrOiVghilvHaw= =eiX3 -----END PGP SIGNATURE----- --OQCFxgrnN3HpwJBLXuqxQiMhtKDsEMnaI-- From nobody Sun Mar 22 06:57: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 F041D1A90DD; Sun, 22 Mar 2015 06:57: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 4hVpYUe_xRfl; Sun, 22 Mar 2015 06:57:08 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 F29CF1A90E0; Sun, 22 Mar 2015 06:57:07 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so106823953obd.3; Sun, 22 Mar 2015 06:57: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:content-transfer-encoding; bh=4nwqvHn2UNKBReEqaXDmqaLwyrPLzCz5OIAOYJtDEAo=; b=0xudl2oDJqdMrV+DcK7L6LCIjqUsUPucEklCrrgMC3UYc9hElKZNOlvlgF7m3mOFTD YjmCdaKkjLMtlOlsKdEjNsFyHsznSdVuOD/8gBxCmzEu2nQAGabo1gNDCPjhOsJeRtXs Hbv9U02GC7VNi8jHmVQ68u4i8cPmPQLFDXpjnYkwAB2+3ouys6aGfM2PKyIYAAxfzmJu eBrj2WhZRmeFqA8Ylj9+SUvET9H6SmjAY7IWlKh+fni6nuZ4zKYXGCzkIBeA4JL9VUd6 XvqFSYF3DJffu4bNTmc3/cn4xH9SGVSH/h0cMdMpFGSq2Th8dA+6GCS4g82YJVNA087u Qqlw== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr31145530obk.44.1427032627272; Sun, 22 Mar 2015 06:57:07 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 06:57:07 -0700 (PDT) In-Reply-To: References: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> <550EB8F2.10203@cs.tcd.ie> Date: Sun, 22 Mar 2015 06:57:07 -0700 Message-ID: From: Martin Thomson To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ops-dir@ietf.org" , "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" , "tls@ietf.org" Subject: Re: [TLS] ops review of draft-ietf-tls-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 13:57:10 -0000 On 22 March 2015 at 06:01, Fred Baker (fred) wrote: >> On Mar 22, 2015, at 7:43 AM, Stephen Farrell = wrote: >> On 22/03/15 06:29, Fred Baker (fred) wrote: >>> One implication that the document doesn=E2=80=99t bring out directly, b= ut >>> which follows from the discussion of the attacks, is that any key or >>> certificate that has been exchanged using SSL may have been >>> compromised via a man-in-the-middle attack, and is therefore suspect. >>> Such certificates and keys should be replaced >> >> I don't think that is the case, as SSL's imperfections bad as they >> are, don't expose long-term (private) keying material. But it is >> worth checking. Short-term keys will naturally be replaced without >> any operator action in any SSL->TLS transition I think. And any >> trust anchors that were accepted via self-signed certificates will >> be as good or bad as ever and are probably best left alone if one >> isn't changing s/w but just a config. > > You may ell be correct. I also noted, after having sent the email, that i= t is fairly probable that a different crypto algorithm might be selected as= a result of the transition, which would entail obtaining relevant keys and= certificates anyway. Hi Fred, Thanks for the writeup. With respect to this issue, I just did some double-checking and the treatment of certificates and the associated long-term keying material is identical between SSL3 and TLS 1.1. Some changes were made with respect to signatures in TLS 1.2, but those probably won't materially affect the analysis. So, absent new attacks being found, my analysis is that we're OK with respect to long-term keying material. If someone does find an attack, then we'll be retiring TLS 1.0 and 1.1 in a panic. --Martin From nobody Sun Mar 22 10:25: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 2B96F1A90B5; Sun, 22 Mar 2015 06:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, 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 O6bi-FWZshQU; Sun, 22 Mar 2015 06:01:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778BE1A9098; Sun, 22 Mar 2015 06:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2783; q=dns/txt; s=iport; t=1427029314; x=1428238914; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4ybdSs1D5JXE3kTxRz2YqsGxG9IADLG4u5xC+/xa6G8=; b=P14BVmYoaytSIqFFXjI30iIxB5YM+vc6YREYW3JR0DEFleFB0r+iGMuZ TdLkQ/RjHc8GCQAHdCdorM0xn5Wn68T8rxjzTOQLzm7q9XpA6YrKbsqSO CDjiYdo7UJm1hO5ZOKVzjyHQlawLc+s+4KYWYqlNoQR5m6EQCvqJn+Fev s=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ALBQA1vA5V/4oNJK1cgwaBLASDDMlRAoEbTAEBAQEBAX2EFAEBAQMBIwRSBQsCAQgYKgICMiUCBA4FDogZCK9XmTQBAQEBAQEBAQEBAQEBAQEBAQEBGYshhBMRAVAHgmgvgRYFkE+BaYEyhlMBgRqDMI9fIoICHIFQb4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,446,1422921600"; d="asc'?scan'208";a="134328410" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP; 22 Mar 2015 13:01:53 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2MD1rWm000678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Mar 2015 13:01:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 08:01:53 -0500 From: "Fred Baker (fred)" To: Stephen Farrell Thread-Topic: ops review of draft-ietf-tls-sslv3-diediedie Thread-Index: AQHQZGmWpARkpZLGW0mpB3eKsQYLp50oxpcAgAAFIYA= Date: Sun, 22 Mar 2015 13:01:53 +0000 Message-ID: References: <5287A99D-C512-498A-9F8C-3B7E38D7844B@cisco.com> <550EB8F2.10203@cs.tcd.ie> In-Reply-To: <550EB8F2.10203@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.89.4.20] Content-Type: multipart/signed; boundary="Apple-Mail=_67D2459B-3EE0-4C3B-B66C-477A4754EA52"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 10:25:29 -0700 Cc: "ops-dir@ietf.org" , "draft-ietf-tls-sslv3-diediedie.all@tools.ietf.org" , "tls@ietf.org" Subject: Re: [TLS] ops review of draft-ietf-tls-sslv3-diediedie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 13:01:56 -0000 --Apple-Mail=_67D2459B-3EE0-4C3B-B66C-477A4754EA52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 22, 2015, at 7:43 AM, Stephen Farrell = wrote: >=20 >=20 > Thanks Fred for the thoughtful review. >=20 > I think one thing is worth double-checking. You said: >=20 > On 22/03/15 06:29, Fred Baker (fred) wrote: >> One implication that the document doesn=E2=80=99t bring out directly, = but >> which follows from the discussion of the attacks, is that any key or >> certificate that has been exchanged using SSL may have been >> compromised via a man-in-the-middle attack, and is therefore suspect. >> Such certificates and keys should be replaced >=20 > I don't think that is the case, as SSL's imperfections bad as they > are, don't expose long-term (private) keying material. But it is > worth checking. Short-term keys will naturally be replaced without > any operator action in any SSL->TLS transition I think. And any > trust anchors that were accepted via self-signed certificates will > be as good or bad as ever and are probably best left alone if one > isn't changing s/w but just a config. >=20 > So I don't see an operator action here that we ought document in > this draft. But if there were things operators ought do, that are > not purely implementation specific issues, then I think those'd be > worth noting in the document, so this is just to check that. If > someone knows of such, please send text and the WG can process > that. >=20 > As the relevant AD, I'll interpret silence here as "no change > needed." >=20 > Cheers, > S. You may ell be correct. I also noted, after having sent the email, that = it is fairly probable that a different crypto algorithm might be = selected as a result of the transition, which would entail obtaining = relevant keys and certificates anyway. As you say, food for thought. --Apple-Mail=_67D2459B-3EE0-4C3B-B66C-477A4754EA52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEVAwUBVQ69QJ9ieig10VPpAQJhXwf/S6VtRXn6NuZPRh33M2YqyrNgvzW9dzKZ nB7QaLd6KqKvR1vQl5gO6urzzXH47QaFKKzR2sBnAAPfqNl4aq2LfBuhY3bmualG GNNbbwtCxcqbMe0M3De+/pkzj6tKqCjxaVomiUtnMy0VWPeSWBnDXb3L9/w9u0JL ZRdE8dsSj6bf3OXa1y/hcYE+lzT6UtfxgjZveH3X1oA2VKz1GXp6ZiMZeyUEKvoG 9Z9OV5ItY7cc8ar4zLfeqRgZl3HCrX8tySjKqlDMsjhiNliPc0RiZ4rWt+Ao+/u0 lRQ4vFHjeqK1Fb9Tmc05xKo93ACeRZb/2a/RA5hx9jVlgVPJerl4Ow== =KyVw -----END PGP SIGNATURE----- --Apple-Mail=_67D2459B-3EE0-4C3B-B66C-477A4754EA52-- From nobody Sun Mar 22 10:30: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 E4D011A011D for ; Sun, 22 Mar 2015 10:30:01 -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 YT8apYqLeoGI for ; Sun, 22 Mar 2015 10:30:00 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (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 1AAD51A00E7 for ; Sun, 22 Mar 2015 10:30:00 -0700 (PDT) Received: by qcbjx9 with SMTP id jx9so90629911qcb.0 for ; Sun, 22 Mar 2015 10:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SMXUSQ/vTL2sxskTtVIhEJzWqgYlq7hZNXWLkAc4MIY=; b=mHBlEoJRzTH6hNFGORvpJbYWtph6RNqb/E5P0OYmoQJf3Itt3HwN3d+O9J0lJXOzHv iwtvCJ/Sj+PmI/LsGHc9AyDdv1h+D3lu4ntwDGd8pFFunrwt2edlHdUMg6w/2LrnWGai bvSusEpS3sf5kcNvyXN4nXzjuRbnKa9Oosk5OGSJD+mFcQfpeTxFonoEAWyxPGoYKHzW Y+FQSeoZCJWsb31Hnaimo2hZ/GlzK7Ks10hIGqSEmNa/UhwvRLDAG0+ujmQcQFOjGweW nt7OzDPJeGX5g3MfxOi3G7OzNwnmWXbenVnSWadMoAdpgPSdC+gafZLOB3c+6wDaWuV+ xbMg== X-Gm-Message-State: ALoCoQlrHExQLIpayy5vu0OPh6uiC4dqJY5NAU3G68GoM/KnA2lPEAphym9ZeGVuECwp95DDpmEd MIME-Version: 1.0 X-Received: by 10.55.31.71 with SMTP id f68mr177782225qkf.7.1427045399351; Sun, 22 Mar 2015 10:29:59 -0700 (PDT) Received: by 10.96.121.104 with HTTP; Sun, 22 Mar 2015 10:29:59 -0700 (PDT) X-Originating-IP: [2601:8:b300:a5:808c:14e6:faee:9fc9] Date: Sun, 22 Mar 2015 10:29:59 -0700 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114782dc1b686e0511e3e614 Archived-At: Subject: [TLS] Result of Working Group Last Call for draft-ietf-tls-padding-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 17:30:02 -0000 --001a114782dc1b686e0511e3e614 Content-Type: text/plain; charset=UTF-8 Below is my proto writeup for the draft-ietf-tls-padding-01. Since there were no comments on the draft during the last call I am going to request the intended status as informational as the draft is documenting specific practice that was used to work around a few specific implementations problems that are being phased out. If you would rather see the draft as historic or standards track please respond to this message by March 27, 2015. Thanks, Joe 1. Summary Joseph Salowey is the document shepherd and Stephen Farrell is the responsible area director. This document describes a TLS extension that can be used to pad ClientHello messages to a desired size. This was done to work around implementation problems from several TLS server implementations. The requested status is informational since this is documenting a work around to a particular implementation problem. 2. Review and Consensus During the development and deployment of ALPN it was found that some TLS server implementations had a problem with TLS ClientHellos of certain sizes. This extension allowed client implementations to work around this problem until the server implementations are upgraded. There was a lot of review of this mechanism at that time and it was deployed to work around the problem. A temporary extension number was assigned so implementations could interoperate. At this time there is less interest in the document because the problem is solved by the extension and the reduction of faulty implementations, however it is still useful to document this extension to preserve the registration and in the case it ever becomes useful again. 3. Intellectual Property No IPR declarations have been made on this document. 4. Other Points There already is a temporary reservation in the IANA registry and this document makes it permanent. --001a114782dc1b686e0511e3e614 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below is my proto writeup for the draft-ietf-tls-padding-0= 1.=C2=A0 Since there were no comments on the draft during the last call I a= m going to request the intended status as informational as the draft is doc= umenting specific practice that was used to work around a few specific impl= ementations problems that are being phased out. =C2=A0 If you would rather = see the draft as historic or standards track please respond to this message= by March 27, 2015. =C2=A0

Thanks,

Joe

1. Summary
<= br>Joseph Salowey is the document shepherd and Stephen Farrell is the respo= nsible area director. =C2=A0

This document describes a TLS extension= that can be used to pad ClientHello messages to a desired size. This was d= one to work around implementation problems from several TLS server implemen= tations.

The requested status is informational since this is documen= ting a work around to a particular implementation problem.

2. Review= and Consensus

During the development and deployment of ALPN it was = found that some TLS server implementations had a problem with TLS ClientHel= los of certain sizes.=C2=A0 This extension allowed client implementations t= o work around this problem until the server implementations are upgraded. = =C2=A0 There was a lot of review of this mechanism at that time and it was = deployed to work around the problem. A temporary extension number was assig= ned so implementations could interoperate. =C2=A0

At this time there= is less interest in the document because the problem is solved by the exte= nsion and the reduction of faulty implementations, however it is still usef= ul to document this extension to preserve the registration and in the case = it ever becomes useful again. =C2=A0

3. Intellectual Property
No IPR declarations have been made on this document. =C2=A0

4. Othe= r Points

There already is a temporary reservation in the IANA regist= ry and this document makes it permanent. =C2=A0
--001a114782dc1b686e0511e3e614-- From nobody Sun Mar 22 10:54: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 410481A023E for ; Sun, 22 Mar 2015 10:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLOAC3-nW8Nt for ; Sun, 22 Mar 2015 10:54:27 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 D8BED1A020A for ; Sun, 22 Mar 2015 10:54:26 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so108786298obb.1 for ; Sun, 22 Mar 2015 10:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6dmnNfJ24wIRrjePDUKb2+PHSEts1nPksmmmFZNH9YE=; b=tdx+OW1vVlK18+Hp5CbHe5GR3GwjscT/8p6R3Oi6ZenZFTBJOpzcINN4Vm68zUawDj d7aDPVJKv27jRyDjYjOQm+X3X1Pu/UXgdvR+DjM+6vM/q8FycBjvzGqLM6iGHBWSl1qj fLSsdLnguLdoLjwhFxRedjU5xEjuzwgit134YGy+tNvGVhxdTWzI06Hpb+BaYdJPoDUD qarw1wegt24fS68u4g5cNQAvOOUFbZ46geaU4OGrxqbkqgKMJbk/PufjWJe3xVmGdjk2 D2HSMUrOES5RNGri6l486PIuzF7AZfJ+0QZUCT40qaBxYqHQzn1dqFZZUsG3MXgZAVes IA/Q== MIME-Version: 1.0 X-Received: by 10.182.20.237 with SMTP id q13mr52239570obe.82.1427046866434; Sun, 22 Mar 2015 10:54:26 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 10:54:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 10:54:26 -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] Result of Working Group Last Call for draft-ietf-tls-padding-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 17:54:28 -0000 On 22 March 2015 at 10:29, Joseph Salowey wrote: > Below is my proto writeup for the draft-ietf-tls-padding-01. Since there > were no comments on the draft during the last call I am going to request the > intended status as informational as the draft is documenting specific > practice that was used to work around a few specific implementations > problems that are being phased out. If you would rather see the draft as > historic or standards track please respond to this message by March 27, > 2015. I see no reason not to move for PS, but could live with Info. From nobody Sun Mar 22 11:19: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 DE52C1A0022; Sun, 22 Mar 2015 11:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RREPA37HQq_l; Sun, 22 Mar 2015 11:19:16 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 938D91A001A; Sun, 22 Mar 2015 11:19:16 -0700 (PDT) Received: from [IPv6:2001:67c:370:136:c617:feff:feb6:86ed] (unknown [IPv6:2001:67c:370:136:c617:feff:feb6:86ed]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4D2D8200C1; Sun, 22 Mar 2015 19:19:15 +0100 (CET) Message-ID: <550F07A1.7020403@acm.org> Date: Sun, 22 Mar 2015 12:19:13 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: "tram@ietf.org" , tls@ietf.org, AVT WG References: <550AB788.2040701@acm.org> In-Reply-To: <550AB788.2040701@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] rfc5764 design meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:19:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We will meet tonight at 8:30pm in the bar located on the lobby level of the Fairmont Hotel. On 03/19/2015 05:48 AM, Marc Petit-Huguenin wrote: > FYI, we will have a design meeting on Sunday around 9pm in Dallas to put together a proposal about the 5764 multiplexing scheme. The plan is to present this proposal in the avtcore WG session on Tuesday. Anybody with opinions on how to solve this problem should join us. > > I'll send another email when I know the place and exact time. > > Thanks. > > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVDwehAAoJECnERZXWan7EN8sP/iyslm73K21+e/joKaskQhII qMPCnPlmufLVGQ/6aEFGuRmdysnb60PKNHkaWfF1XRAiKbgnsn1Su7W63jyJzjJ3 S7RcMg1CiGqJ9S9yif6IfH7oTPZYqrydPKqjWCtUy2c/ZCcyiL7nxpA2JT1Snf9H W3oZqSD4RaGyN0nT5sYxQmdoI+RN9SmM0ts0vmPodNlAIK2bxAjKQPGVEodMkGEi we8idoICBlP6gkUqNpA57BHxS+xse0co1BRhAoTjtVqVWuMK/POWDhzVI4SC0cw0 miRmg+L4cwExqpapsdeZ3DTX1fw9fb0JJBf6mBUKDyK2R8LNGw5B/SC7UfDrvSED DjcNo/KS67ljHXTxrmVi1v6trZS6q75zZstE1wlNEDHiv54Dz2ZT/kKHT56LZ8Ot 79SJve8xMdY/CySvOwYxA5yVxU212VPy5tOLpgqEzk13Qz9OvXlRiZcFfRc2h5BW 4kkj24LCxnIWC62lo8hEaeNpv1/WR4MiAxvYIq7B9ZfcxfOcxqJ28E47ggqR+3Y/ DrEJNU0ePntUlBSgXJLsgsgjS2rVt93NeNaHq4o0jgu5jYJIvjNOR0Qc/UPosqDT NzOuvUgis6cGjUKTH+XH9/WdAeKvmDd+jfZzcFxkoQwOPXNglqaesWhnF7miWtqx PLFKqdUpwWtNrszOlH6Z =KHNB -----END PGP SIGNATURE----- From nobody Sun Mar 22 11:21: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 E509A1A0022 for ; Sun, 22 Mar 2015 11:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDEeuK6Ol2tr for ; Sun, 22 Mar 2015 11:21:26 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::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 333C21A0030 for ; Sun, 22 Mar 2015 11:21:26 -0700 (PDT) Received: by wgs2 with SMTP id 2so22422425wgs.1 for ; Sun, 22 Mar 2015 11:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=crRDJlCg6Ha8G01QRSn/lCu9JHHA9NcaU1v34XPlxU4=; b=FYzt/15GdH7SnvWH7m/k3S26HMJjYohsICweo8Gzg8xR3FvzoRtRJ6EiEO7w9PUt80 KsuHEKruABbBu+et67/KVnFmCmJ/qT2dia63rCIyRtiehvxM3rcLHjlVqggM9GYgvx1f ++LSg3JqxQ5Xc3814EuL6fK8LnO2zwVkkO4XcZz9yVOYB0Qj4/0THV0H3MJmc0dYuq4E tnG+zho1KN3Ydp8VXu1XjUmPz0scmd/tSkh/wTiGF2U3VSuuLVQPvgAzWdl2b796yaaW y7NgYZzymoQQ7DhHNDGzUA4DduCPlcBJMmuhOOvWAiKnUsAdUDeaO+mELVADgnV0ysQo il6w== X-Received: by 10.194.200.8 with SMTP id jo8mr146709208wjc.64.1427048483956; Sun, 22 Mar 2015 11:21:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:688d:9ee:8096:9d38? ([2001:67c:370:176:688d:9ee:8096:9d38]) by mx.google.com with ESMTPSA id ha10sm15850801wjc.37.2015.03.22.11.21.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 11:21:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 22 Mar 2015 13:21:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0E4D835E-0FCB-48C3-8F25-E93967957A75@gmail.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Result of Working Group Last Call for draft-ietf-tls-padding-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:21:28 -0000 > On Mar 22, 2015, at 12:54 PM, Martin Thomson = wrote: >=20 > On 22 March 2015 at 10:29, Joseph Salowey wrote: >> Below is my proto writeup for the draft-ietf-tls-padding-01. Since = there >> were no comments on the draft during the last call I am going to = request the >> intended status as informational as the draft is documenting specific >> practice that was used to work around a few specific implementations >> problems that are being phased out. If you would rather see the = draft as >> historic or standards track please respond to this message by March = 27, >> 2015. >=20 > I see no reason not to move for PS, but could live with Info. The question is whether this is behavior that we want to standardize or = a workaround that we want to document.=20 Five years from now, and giving you the power to force everyone to = upgrade their software, do you want this being used? Yoav From nobody Sun Mar 22 12:34: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 3CCB11A0A85 for ; Sun, 22 Mar 2015 12:34: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 VO8yID5A_6Iw for ; Sun, 22 Mar 2015 12:34:43 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 28F5B1A0A6A for ; Sun, 22 Mar 2015 12:34:43 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so109787741obd.3 for ; Sun, 22 Mar 2015 12:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JxEWuLOPnhGUgD/pnznqrvupomdninkU2+9qBEyBKMs=; b=gMKc3bFlWrR/SzV5ODZNJ82Hm8vWp6jfElcMV7fmeuMYrzwC6Ct1oP58WC97Ux+L86 KkWczKtm4SOHJnDixMjAkRzwb2H56QtkNIFl20q7Bs/7hhYyDdwQRDYmhcrpVJFSEBl1 3OkyAuL1DSMjZv1scw3vBZ6v9h9t4m1TL5/vIXtmIPsFsGPDwL3aeR9xVL63O03lQ8Se Q4OiahKV+WbdZMpy18rNxYm+maMDGEWlkWghoQ99anJ5SJ4fQAGQV+uQlbt3xb2DTYwc yNbTid4WoGMe2mNog8N63ygKUfDIJpU0sqOwZCpwtgoFsHcZBW+tnpqD8V4cXbKI0vpd 65fw== MIME-Version: 1.0 X-Received: by 10.182.34.131 with SMTP id z3mr3540379obi.4.1427052882699; Sun, 22 Mar 2015 12:34:42 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 12:34:42 -0700 (PDT) In-Reply-To: <0E4D835E-0FCB-48C3-8F25-E93967957A75@gmail.com> References: <0E4D835E-0FCB-48C3-8F25-E93967957A75@gmail.com> Date: Sun, 22 Mar 2015 12:34:42 -0700 Message-ID: From: Martin Thomson To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Result of Working Group Last Call for draft-ietf-tls-padding-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 19:34:44 -0000 On 22 March 2015 at 11:21, Yoav Nir wrote: > Five years from now, and giving you the power to force everyone to upgrade their software, do you want this being used? There is this feature in QUIC where their equivalent of the ClientHello is padded to a certain significant size. The theory there is that you don't want your server to be used in a packet amplification attack (ClientHello being generally smaller than the ensuing flight from the server). I think that perhaps there might be a standards-based use for a feature that at least made the size of the flights commensurate in size. From nobody Sun Mar 22 14:50: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 416381A1BD7 for ; Sun, 22 Mar 2015 14:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 BvYM-Y_0ji8D for ; Sun, 22 Mar 2015 14:50:10 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (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 100E41A1EE8 for ; Sun, 22 Mar 2015 14:50:10 -0700 (PDT) Received: by wgra20 with SMTP id a20so131743097wgr.3 for ; Sun, 22 Mar 2015 14:50: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:from:date:message-id:subject:to :content-type; bh=y7QCcyIG4BZMdSusMfzvy82jHFq2zfDNQ6ECPSMqoPc=; b=mDsxtDesoS1nQUe8vBFRZc5eOeRQ8FYW/qwZj4AzziYnSl3/Fd3F3fpqmiUKHqus/x nY+5xYvOKPJqVmke5NpE2mK+meikF3X3kbp4ag3C8g7fDUQYPJ8zByQ7I94NN0mK56C2 zDCN07CT8iIwCDoNRQxrXkX48m8b4YmskTAT6bgorWcPriO3pRrnaH3vH6ZVJsH6U1ig MFcqZnFocr3+9SIARoPTD7Z90GlYBi7OfQCOA5JtRjGVMminMLiY+sUphJQKwz2vO6yK RnxzVBsSfDbeExy/iXhhfsbppyL7Bs1/Ada4M/yS3u0uIpqkhCZUYvzwk9/m6lYp+ppk o/hQ== X-Gm-Message-State: ALoCoQlxnIATOjgQSpb5/+RxxGc4d4SFjFf7mfuAl3PVKdRYpfm+ewIHwf4nuPMmolvcxys6E4X4 X-Received: by 10.180.20.144 with SMTP id n16mr13897264wie.44.1427061008832; Sun, 22 Mar 2015 14:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 14:49:28 -0700 (PDT) From: Eric Rescorla Date: Sun, 22 Mar 2015 14:49:28 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53f2e2f812ea20511e788f2 Archived-At: Subject: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 21:50:14 -0000 --bcaec53f2e2f812ea20511e788f2 Content-Type: text/plain; charset=UTF-8 In the interim in Seattle, we had an extensive discussion of 0-RTT anti-replay in which DKG observed that all the proposed anti-replay mechanisms provide limited protection. The underlying problem is the desire to present a uniform interface in which the calling application can count on reliable delivery of the data it provides in the first flight, thus requiring the TLS stack to retransmit it automatically. This message describes the problem and should set us up for a discussion about the topic in Dallas. Apologies in advance for the length of this, but I'd like to be clear. BACKGROUND: ANTI-REPLAY As you'll recall, TLS ordinarily uses a server-provided random value mixed into the keys for anti-replay. This obviously doesn't work for 0-RTT. For reference, here's a simplified description of the way that (and the way that both QUIC and snap-start do it). - The server keeps a list of every ClientRandom it has received within a given time window keyed by a server context ("orbit") value that loosely can be thought of as indicating the data center. - When the server receives a new ClientHello, it checks to see if it has seen it before and then rejects the connection. Now consider what happens when the server reboots and loses its state. You don't want to reject every client 0-RTT connection so instead what you do is you ignore the client's initial data sent in the first flight. Since the ServerHello provides a new Random value, any data the client sends in subsequent flights has the usual anti-replay protection. A SOMEWHAT CONTRIVED ATTACK This is all fine so far, but the abstraction you probably want TLS to supply to the application is that the data it sends in the first flight isn't lost even in this case. In order to accomodate this, the natural design is for the TLS stack to retransmit the plaintext in the client's first flight as the first data it sends under the new keys. An attacker can make use of this as follows. When the client sends the initial first flight he captures the TCP connection and makes his own TCP connection to the server, forwarding the first flight. Client Attacker Server ClientHello [+0-RTT] ------------> "POST /buy-something" -----------> ClientHello [+0-RTT] ---------------> "POST /buy-something" --------------> [Processes purchase] <---------- ServerHello [accept 0-RTT] (+ rest of handshake) The attacker just discards the server's response and then the server somehow forces the server to reboot (this is the hard part). Once the server has rebooted, the attacker re-sends the client's initial flight then just forwards data back and forth to the client. Client Attacker Server ClientHello [+0-RTT] ---------------> "POST /buy-something" --------------> <-------------------------------------- ServerHello [reject 0-RTT] (+ rest of handshake) Finished ---------------------------------------------------------> "Post /buy-something" --------------------------------------------> [Processes purchase] At this point, you've mounted a successful replay attack. Obviously this is not that great an attack because it requires you to be able to force a reboot and also get in under the client's timeout window. A MORE REALISTIC ATTACK During the interim meeting, DKG observed that you could produce the same "I've forgotten my state" situation if you have a distributed server. Say that the server operates in two loosely-synchronized data centers. In that case, you can get the following situation (shown without the attacker's intervention because of ASCII art limitation Client Attacker Server1 Server 2 ClientHello [+0-RTT] --> "POST /buy-something" -> ClientHello [+0-RTT] --> "POST /buy-something" -> [Processes purchase] ClientHello [+0-RTT] -----------------------> "POST /buy-something" ----------------------> <-------------------------------------- ServerHello [reject 0-RTT] (+ rest of handshake) Finished ---------------------------------------------------------> "Post /buy-something" --------------------------------------------> [Processes purchase] Again, the attacker will need to mess with the TCP channel, but their ability to do so is part of our basic threat model [RFC 3552]. It's important to understand that this is a generic issue, not an issue with TLS in particular, so it's not like there's some other 0-RTT model we can lift and put into TLS that would solve the problem. APPROACHES One way to address this would be to simply not provide a 0-RTT mode. This is a charter item, so that would be sad, but obviously that's not out of the question if we really think this is bad. The more serious question is that there's an enormous demand for this feature (see, for instance, the discussion at the SEMI workshop), and so if we refuse to do a 0-RTT mode, we're giving applications the annoying choice of accepting a RTT or inventing their own 0-RTT method. There are a number of basic ways to address this issue, but I think the main plausible[0] ones are: 1. Keep the server state globally consistent and also temporally consistent so that replays can always be detected. 2. Remove the TLS anti-replay guarantee for the data sent in the first flight and tell applications to only send data there that can tolerate being replayed. 3. Remove the TLS reliable delivery guarantee for the data sent in the first flight, so that the stack doesn't automatically replay it. The first of these options (global state) is possible, but only in some limited circumstances, namely very sophisticated operators and/or situations where there's really only one server which has good state management. An example of the latter is WebRTC, where the server can have a different anti-replay context for each connection. The other two options clearly require a separate API to handle this special first-flight data and would require applications to handle it separately. So, for instance, in option 2, you would have something like: c = new TLSConnection(...) c.setReplayable0RTTData("GET /....") c.connect(); And in the case of option 3 you would have something like: c = new TLSConnection(...) c.setUnreliable0RTTData("GET /....") c.connect() if (c.delivered0RTTData()) { // Things are cool } else { // Try to figure out whether to replay or not } So in the former case, the choice of replay is in the TLS stack's hands but in the latter in the application's hands. I would expect them to have relatively similar impacts on the wire, namely applications would self-designate certain data as replay-safe (e.g., HTTP GETs) and would send it in the first flight and then either let the stack retransmit (option 2) or retransmit themselves (option 3). This isn't that odd, since, as AGL observes, browsers already routinely retry some HTTP requests that appear to fail even for ordinary TLS (i.e., no HTTP response was received) so in those cases they have already circumvented the anti-replay guarantees supplied by TLS, but of course that's different from having TLS give up those guarantees. RECOMMENDATION As I said, I think we do need to supply some sort of limited 0-RTT functionality. Given the practical difficulty of making global state work, I think it's a mistake to build a system which relies on this. The remaining two options require that we relax one of TLS's guarantees and of these, relaxing reliable delivery seems safer, and it also makes the implementation rather easier. Accordingly, I propose that we continue to develop 0-RTT but with the server just dropping 0-RTT first-flight data when 0-RTT is not possible (and of course telling the client it is doing so). The client application can then retransmit if it believes it is safe. In the very limited cases where application domains can in fact safely keep state, they can profile the use of TLS to that end and require the endpoints to behave appropriately. Thanks, -Ekr [0] One implausible approach is to treat any attempt to 0-RTT when you have lost state as a hard-fail, but this will create a lot of random failures, so it's not really practical. --bcaec53f2e2f812ea20511e788f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the interim in Seattle, we had an extensive discus= sion of 0-RTT
anti-replay in which DKG observed that all the prop= osed anti-replay
mechanisms provide limited protection. The under= lying problem is the
desire to present a uniform interface in whi= ch the calling application
can count on reliable delivery of the = data it provides in the first
flight, thus requiring the TLS stac= k to retransmit it automatically.

This message des= cribes the problem and should set us up for a
discussion about th= e topic in Dallas. Apologies in advance for
the length of this, b= ut I'd like to be clear.


BACKGR= OUND: ANTI-REPLAY
As you'll recall, TLS ordinarily uses a ser= ver-provided random value
mixed into the keys for anti-replay. Th= is obviously doesn't work for
0-RTT. For reference, here'= s a simplified description of the way that
(and the way that both= QUIC and snap-start do it).

- The server keeps a = list of every ClientRandom it has received
=C2=A0 within a given = time window keyed by a server context ("orbit")
=C2=A0 = value that loosely can be thought of as indicating the data center.

- When the server receives a new ClientHello, it checks t= o
=C2=A0 see if it has seen it before and then rejects the connec= tion.

Now consider what happens when the server re= boots and loses its
state. You don't want to reject every cli= ent 0-RTT connection so
instead what you do is you ignore the cli= ent's initial data sent in
the first flight. Since the Server= Hello provides a new Random value,
any data the client sends in s= ubsequent flights has the usual
anti-replay protection.


A SOMEWHAT CONTRIVED ATTACK
This i= s all fine so far, but the abstraction you probably want TLS to
s= upply to the application is that the data it sends in the first
f= light isn't lost even in this case. In order to accomodate this, the
natural design is for the TLS stack to retransmit the plaintext in = the
client's first flight as the first data it sends under th= e new keys.

An attacker can make use of this as fo= llows. When the client sends
the initial first flight he captures= the TCP connection and makes his
own TCP connection to the serve= r, forwarding the first flight.

Client =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At= tacker =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Server

ClientHello [+0-RTT= ] ------------>
"POST /buy-something" ----------->= ; =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ClientHello [+0-RTT] --------------->
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "POST /buy-something" --------------> =C2=A0 =C2=A0= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Processes purchase]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<---------- ServerHello [accept 0-RTT]
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (+ rest of handshake)


=
The attacker just discards the server's response and then the serv= er
somehow forces the server to reboot (this is the hard part).

Once the server has rebooted, the attacker re-sends= the client's
initial flight then just forwards data back and= forth to the client.

Client =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Attacker =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello [+0= -RTT] --------------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PO= ST /buy-something" --------------> =C2=A0 =C2=A0 =C2=A0
<= br>
=C2=A0 =C2=A0<-------------------------------------- =C2= =A0ServerHello [reject 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(+ rest o= f handshake)

Finished ----------------------------= ----------------------------->
"Post /buy-something"= -------------------------------------------->
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [Processes purchase]

At this point, = you've mounted a successful replay attack. Obviously
this is = not that great an attack because it requires you to be able to
fo= rce a reboot and also get in under the client's timeout window.


A MORE REALISTIC ATTACK
During t= he interim meeting, DKG observed that you could produce the
same = "I've forgotten my state" situation if you have a distributed=
server. Say that the server operates in two loosely-synchronized=
data centers. In that case, you can get the following situation<= /div>
(shown without the attacker's intervention because of ASCII a= rt
limitation

=C2=A0Client =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Attacker =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Server1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server 2

ClientHello [+0-RTT] -->
"POST /buy-= something" -> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ClientHello [+0-RTT] -->
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "POST /buy= -something" ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Processes
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purchase] =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ClientHello [+0-RTT] ----------------------->
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;POST /buy-something" ---------------------->

<= div>
=C2=A0 =C2=A0<-------------------------------------- = =C2=A0ServerHello [reject 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(+ res= t of handshake)

Finished -------------------------= -------------------------------->
"Post /buy-something&qu= ot; -------------------------------------------->
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Processes purchase]

Again, the = attacker will need to mess with the TCP channel, but their
abilit= y to do so is part of our basic threat model [RFC 3552].

It's important to understand that this is a generic issue, not a= n
issue with TLS in particular, so it's not like there's = some other
0-RTT model we can lift and put into TLS that would so= lve the problem.


APPROACHES
One way to address this would be to simply not provide a 0-RTT mode.
This is a charter item, so that would be sad, but obviously that'= ;s not
out of the question if we really think this is bad. The mo= re serious
question is that there's an enormous demand for th= is feature (see, for
instance, the discussion at the SEMI worksho= p), and so if we refuse to
do a 0-RTT mode, we're giving appl= ications the annoying choice of
accepting a RTT or inventing thei= r own 0-RTT method.


There are a num= ber of basic ways to address this issue, but I think
the main pla= usible[0] ones are:

1. Keep the server state globa= lly consistent and also temporally
=C2=A0 =C2=A0consistent so tha= t replays can always be detected.

2. Remove the TL= S anti-replay guarantee for the data sent in the first
=C2=A0 =C2= =A0flight and tell applications to only send data there that can
= =C2=A0 =C2=A0tolerate being replayed.

3. Remove th= e TLS reliable delivery guarantee for the data sent in
=C2=A0 =C2= =A0the first flight, so that the stack doesn't automatically replay it.=

The first of these options (global state) is poss= ible, but only in
some limited circumstances, namely very sophist= icated operators and/or
situations where there's really only = one server which has good state
management. An example of the lat= ter is WebRTC, where the server can
have a different anti-replay = context for each connection.

The other two options= clearly require a separate API to handle this
special first-flig= ht data and would require applications to handle it
separately. S= o, for instance, in option 2, you would have something
like:

=C2=A0 =C2=A0 c =3D new TLSConnection(...)
= =C2=A0 =C2=A0 c.setReplayable0RTTData("GET /....")
=C2= =A0 =C2=A0 c.connect();

And in the case of option = 3 you would have something like:

=C2=A0 =C2=A0 c = =3D new TLSConnection(...)
=C2=A0 =C2=A0 c.setUnreliable0RTTData(= "GET /....")
=C2=A0 =C2=A0 c.connect()
=C2=A0= =C2=A0 if (c.delivered0RTTData()) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0/= / Things are cool
=C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0// Try to figure out whether to replay or not
=C2=A0= =C2=A0 }
=C2=A0 =C2=A0=C2=A0
So in the former case, th= e choice of replay is in the TLS
stack's hands but in the lat= ter in the application's hands.

I would expect= them to have relatively similar impacts on the wire,
namely appl= ications would self-designate certain data as replay-safe
(e.g., = HTTP GETs) and would send it in the first flight and then
either = let the stack retransmit (option 2) or retransmit themselves
(opt= ion 3). This isn't that odd, since, as AGL observes, browsers
already routinely retry some HTTP requests that appear to fail even for
ordinary TLS (i.e., no HTTP response was received) so in those case= s
they have already circumvented the anti-replay guarantees suppl= ied by
TLS, but of course that's different from having TLS gi= ve up those
guarantees.


R= ECOMMENDATION
As I said, I think we do need to supply some sort o= f limited 0-RTT
functionality. Given the practical difficulty of = making global state
work, I think it's a mistake to build a s= ystem which relies on
this. The remaining two options require tha= t we relax one of TLS's
guarantees and of these, relaxing rel= iable delivery seems safer,
and it also makes the implementation = rather easier.

Accordingly, I propose that we cont= inue to develop 0-RTT but with the
server just dropping 0-RTT fir= st-flight data when 0-RTT is not
possible (and of course telling = the client it is doing so).=C2=A0 The
client application can then= retransmit if it believes it is safe.
In the very limited cases = where application domains can in fact
safely keep state, they can= profile the use of TLS to that end
and require the endpoints to = behave appropriately.

Thanks,
-Ekr
=


[0] One implausible approach is to treat= any attempt to 0-RTT when
you have lost state as a hard-fail, bu= t this will create a lot of
random failures, so it's not real= ly practical.



=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0















--bcaec53f2e2f812ea20511e788f2-- From nobody Sun Mar 22 15:10: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 035A31A3B9C for ; Sun, 22 Mar 2015 15:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wTMZGTVsPHj for ; Sun, 22 Mar 2015 15:10:13 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.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 E406A1A1BCD for ; Sun, 22 Mar 2015 15:10:12 -0700 (PDT) Received: by wegp1 with SMTP id p1so123667313weg.1 for ; Sun, 22 Mar 2015 15:10: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=URGedTMZrLyjqYBoNrehviqj1ZXRXH9R98AWAS9OTuk=; b=S0kZmRRq+2PULqXbukugOOrWPk02rP5741wZuVJSF6PsUrMlI62xAptIh3gi55KRtC ZrQ1mXUfDHNnUYR1pPt6IcO+0QdaOsvK78iH+HsetIkaVHcGvHi7UGb7wrMPnn24sEkl xl4IAXGZ1wpmYNK2KXI28ysDzbzNpS8U0pPYxKSQztzjjAJTTtljoT64WHZtOiPElpg3 WySW1sG9kI80o2iwg+1oVYNUgM8UPzcNoJgxjybDTtpf2e5ouRPW+2LT9gaatkS9rtQG jRidj6tRRsc7S83cnQmPzMkzAetrK3UMKvSn5xnNnj4/LPTsZw+G3XAB+fIKzACHUVqG 6cbw== X-Gm-Message-State: ALoCoQmy2abXyWLAzeH6FdSesM4CfFyeviN1bWdrliY/7KeuVrA4ug+3vpFBDrk6kh6qnyIrEYhp X-Received: by 10.194.108.9 with SMTP id hg9mr183045760wjb.68.1427062211727; Sun, 22 Mar 2015 15:10:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 15:09:31 -0700 (PDT) From: Eric Rescorla Date: Sun, 22 Mar 2015 15:09:31 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf10b1c33eefd0511e7d075 Archived-At: Subject: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:10:15 -0000 --047d7bf10b1c33eefd0511e7d075 Content-Type: text/plain; charset=UTF-8 During the interim we discussed discussion about adopting PSS for RSA signatures in TLS 1.3. Clearly, we will not be able to just adopt PSS because certificates will continue to be signed with PKCS#1 1.5. However, we could adopt PSS for signatures outside of the certificate context. Roughly speaking, we have three options: 1. Do not adopt PSS. 2. Adopt PSS as the only signature format for non-certificate signatures (but require acceptance of PKCS#1 1.5 for certificates) 3. Negotiate the use of PSS versus PKCS#1 1.5 Obviously, if we want to move to PSS, option #2 is simplest, but the sentiment at the interim was to survey the WG to see whether there was widespread enough support for generating and verifying PSS to make this feasible [0]. Please use this thread to discuss. -Ekr [0] FWIW, this doesn't appear to be a problem for NSS. --047d7bf10b1c33eefd0511e7d075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
During the interim we discussed discussion about adop= ting PSS for
RSA signatures in TLS 1.3.

= Clearly, we will not be able to just adopt PSS because certificates
will continue to be signed with PKCS#1 1.5. However, we could adopt
PSS for signatures outside of the certificate context. Roughly
<= div>speaking, we have three options:

1. Do not ado= pt PSS.
2. Adopt PSS as the only signature format for non-certifi= cate
=C2=A0 =C2=A0signatures (but require acceptance of PKCS#1 1.= 5 for
=C2=A0 =C2=A0certificates)
3. Negotiate the use o= f PSS versus PKCS#1 1.5

Obviously, if we want to m= ove to PSS, option #2 is simplest, but
the sentiment at the inter= im was to survey the WG to see whether
there was widespread enoug= h support for generating and verifying
PSS to make this feasible = [0].

Please use this thread to discuss.
=
-Ekr

[0] FWIW, this doesn't app= ear to be a problem for NSS.

--047d7bf10b1c33eefd0511e7d075-- From nobody Sun Mar 22 15:27: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 DAF821A6F2A for ; Sun, 22 Mar 2015 15:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNbzOxxzHEx7 for ; Sun, 22 Mar 2015 15:27:00 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::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 097141A6F12 for ; Sun, 22 Mar 2015 15:27:00 -0700 (PDT) Received: by wetk59 with SMTP id k59so123912180wet.3 for ; Sun, 22 Mar 2015 15:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ip818tprUCGoxePeKC9bJmxqMIMScLSjY/MeBtAnSw=; b=UKxcWHOWNWxRSwQ3u6EYTm8olGcYVuKEo/QfLipy29BcghxW1GEMyAt6GNcrJkaf8u 7weuLoYL3q41SsmSm3fYXB01w5oKAA/GtxkSKoTDbHxEXtwD7PhB9wcS0/5yjUbZd1d0 9TSQTkoU0Wl7jua4tu1T6YQvuk1oX/r8PAIH7E/pHD9wC96m9rEC5tdIUar6Cg8oIVAd zAs0tYHCYC5QvhCBJeLQ7HkZPocyS+Bl9leB3LcBdgZ+G8PekHs1rGK+2f1G4ftRaSOI SFHuks5lCOTXDoJi/S+yS2VmLJB5rpd/Xr3ET2b8qRdZ2KMcJ7O1H4d9PvOnzQcq8yUB cJGg== MIME-Version: 1.0 X-Received: by 10.194.47.201 with SMTP id f9mr176306709wjn.17.1427063218821; Sun, 22 Mar 2015 15:26:58 -0700 (PDT) Received: by 10.27.87.145 with HTTP; Sun, 22 Mar 2015 15:26:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 02:26:58 +0400 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b66fa5b3ae1a40511e80c9a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 22:27:06 -0000 --047d7b66fa5b3ae1a40511e80c9a Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, > Client Attacker Server > > ClientHello [+0-RTT] ------------> > "POST /buy-something" -----------> > > ClientHello [+0-RTT] ---------------> > "POST /buy-something" --------------> > > [Processes purchase] > <---------- ServerHello [accept 0-RTT] > (+ rest of handshake) > > > The attacker just discards the server's response and then the server > somehow forces the server to reboot (this is the hard part). > > Once the server has rebooted, the attacker re-sends the client's > initial flight then just forwards data back and forth to the client. > > Client Attacker Server > ClientHello [+0-RTT] ---------------> > "POST /buy-something" --------------> > > <-------------------------------------- ServerHello [reject 0-RTT] > (+ rest of handshake) > > Finished ---------------------------------------------------------> > "Post /buy-something" --------------------------------------------> > [Processes purchase] > > At this point, you've mounted a successful replay attack. Obviously > this is not that great an attack because it requires you to be able to > force a reboot and also get in under the client's timeout window. > According to draft-rescorla-tls13-new-flows-01: The EncryptedExtensions MUST include an ART indicator that matches the client's ART so that the client knows that the 0-RTT handshake was successful and that the client's application_data was accepted. I wonder why the Server doesn't include an indicator in his reject (encrypted indicator) so the client will avoid sending its request again. (BTW, based on what a server can reject after a reboot) Best regards Mohamad --047d7b66fa5b3ae1a40511e80c9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,


Client = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Attacker =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Server

ClientHello= [+0-RTT] ------------>
"POST /buy-something" ------= -----> =A0 =A0 =A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ClientHello [+0-RTT] --------------->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "P= OST /buy-something" --------------> =A0 =A0 =A0
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0[Processes purchase]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<---------- ServerHello [accept 0-RTT= ]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (+ rest of handshake)


The attacker just discards the server's respons= e and then the server
somehow forces the server to reboot (this i= s the hard part).

=
Once the server has rebooted, the attacker= re-sends the client's
initial flight then just forwards data= back and forth to the client.

Client =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Attacker =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0Server
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 ClientHello [+0-RTT] --------------->
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "POST /buy= -something" --------------> =A0 =A0 =A0

= =A0 =A0<-------------------------------------- =A0ServerHello [reject 0-= RTT]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(+ rest of handshake)

=
Finished -------------------------------------------------------= -->
"Post /buy-something" --------------------------= ------------------>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Processes purc= hase]

At this point, you've mounted a successf= ul replay attack. Obviously
this is not that great an attack beca= use it requires you to be able to
force a reboot and also get in = under the client's timeout window.


According to draft-rescorla-tls13-new-flows-01:

   The EncryptedExtensions MUST include an A=
RT indicator that matches
   the client's ART so that the client knows that the 0-RTT handshake
   was successful and that the client's application_data was accepted.=
=A0
=A0 =A0=

I wonder why the Server doesn't include an in= dicator in his reject (encrypted indicator) so the client will avoid sendin= g its request again.

(BTW, based on what a server = can reject after a reboot)
=A0
Best regards
Mohamad
--047d7b66fa5b3ae1a40511e80c9a-- From nobody Sun Mar 22 15:30: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 ED3D91A6F11 for ; Sun, 22 Mar 2015 15:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvuuEp0AToo9 for ; Sun, 22 Mar 2015 15:30:52 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 EB4B71A6F20 for ; Sun, 22 Mar 2015 15:30:51 -0700 (PDT) Received: by wixw10 with SMTP id w10so44419384wix.0 for ; Sun, 22 Mar 2015 15:30:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OhnNBejeScAHN+hvpbWO6E623o2ghYAXhZ/N+0umXxs=; b=LHxbeEI0iQmGOENEBtcBO0go/U0/ofdhHFL+1xQMlCHdmt3Og33xA2RW46PITX0xUr CaMRMNKJmR31GBzXfRuYpvxs/vdtkRZ9sBQ3tKuLZa9ZV7cAc/4U5LCYq1tI6ZGmagC2 CN6SON3iq0kZmIaro0pHdkEe7xyVUouc2HrcLTF4x1iPM/LMqXqGKmtXgIN2UwQyiHvh RnN+4KmWtfXkYmeXSv2jCNgmjD0pQrC373QMkYdjZLRwhU6a2WXCO5A3IwjGsc/vE2Py FHG/Kax8CwxAdpoR4pple9guFDtnqx+3Yz+RpxTkn/FayoOdufhbq4mD5llU/wLxFU2Q SdkA== X-Gm-Message-State: ALoCoQnC9uneJyIahvdZDYegvOX1fGw2F2YQDYj+Anl1w1zJ2f4LkbugfYaaRYwoivgp9zM8rupD X-Received: by 10.194.108.9 with SMTP id hg9mr183148072wjb.68.1427063450775; Sun, 22 Mar 2015 15:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 15:30:10 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 22 Mar 2015 15:30:10 -0700 Message-ID: To: Mohamad Badra Content-Type: multipart/alternative; boundary=047d7bf10b1c0e361b0511e81ad5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 22:30:54 -0000 --047d7bf10b1c0e361b0511e81ad5 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 3:26 PM, Mohamad Badra wrote: > Hi Eric, > > >> Client Attacker Server >> >> ClientHello [+0-RTT] ------------> >> "POST /buy-something" -----------> >> >> ClientHello [+0-RTT] ---------------> >> "POST /buy-something" --------------> >> >> [Processes purchase] >> <---------- ServerHello [accept 0-RTT] >> (+ rest of handshake) >> >> >> The attacker just discards the server's response and then the server >> somehow forces the server to reboot (this is the hard part). >> >> Once the server has rebooted, the attacker re-sends the client's >> initial flight then just forwards data back and forth to the client. >> >> Client Attacker Server >> ClientHello [+0-RTT] ---------------> >> "POST /buy-something" --------------> >> >> <-------------------------------------- ServerHello [reject 0-RTT] >> (+ rest of handshake) >> >> Finished ---------------------------------------------------------> >> "Post /buy-something" --------------------------------------------> >> [Processes purchase] >> >> At this point, you've mounted a successful replay attack. Obviously >> this is not that great an attack because it requires you to be able to >> force a reboot and also get in under the client's timeout window. >> > > > According to draft-rescorla-tls13-new-flows-01: > > The EncryptedExtensions MUST include an ART indicator that matches > the client's ART so that the client knows that the 0-RTT handshake > was successful and that the client's application_data was accepted. > > > > I wonder why the Server doesn't include an indicator in his reject > (encrypted indicator) so the client will avoid sending its request again. > This would basically be option #3, namely that this data is unreliable. Best, -Ekr (BTW, based on what a server can reject after a reboot) > > Best regards > Mohamad > --047d7bf10b1c0e361b0511e81ad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 3:26 PM, Mohamad Badra <mbadra@gmail.com>= ; wrote:
Hi Eric,=
=

Client =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At= tacker =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Server

ClientHello [+0-RTT= ] ------------>
"POST /buy-something" ----------->= ; =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ClientHello [+0-RTT] --------------->
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "POST /buy-something" --------------> =C2=A0 =C2=A0= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0[Processes purchase]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<---------- ServerHello [accept 0-RTT]
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (+ rest of handshake)


=
The attacker just discards the server's response and then the serv= er
somehow forces the server to reboot (this is the hard part).

Once the server has rebooted, the attacker re-sends the client= 's
initial flight then just forwards data back and forth to t= he client.

Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Attacker =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello [+0-RTT] ----= ----------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "POST /buy-som= ething" --------------> =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0<-------------------------------------- =C2=A0ServerHell= o [reject 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(+ rest of handshake)

Finished ------------------------------------------= --------------->
"Post /buy-something" -------------= ------------------------------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [= Processes purchase]

At this point, you've moun= ted a successful replay attack. Obviously
this is not that great = an attack because it requires you to be able to
force a reboot an= d also get in under the client's timeout window.


According to draft-rescorla-tls= 13-new-flows-01:

   The EncryptedExtensions MUST in=
clude an ART indicator that matches
   the client's ART so that the client knows that the 0-RTT handshake
   was successful and that the client's application_data was accepted.=
=C2=A0
=C2=A0 =C2= =A0

I wonder why the Server doesn't inc= lude an indicator in his reject (encrypted indicator) so the client will av= oid sending its request again.
This would basically be option #3, namely that this data is unr= eliable.

Best,
-Ekr

(BTW, based on what a server can reject= after a reboot)
=C2=A0
Best regards
Mohamad

--047d7bf10b1c0e361b0511e81ad5-- From nobody Sun Mar 22 16:02: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 CA4361A70E1 for ; Sun, 22 Mar 2015 16:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFBLrYq3KvIa for ; Sun, 22 Mar 2015 16:02:10 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.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 545DA1A7008 for ; Sun, 22 Mar 2015 16:02:10 -0700 (PDT) Received: by qcay5 with SMTP id y5so42384979qca.1 for ; Sun, 22 Mar 2015 16:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6pZ54j1K/bcPyHRRGeB6OTt7FiHJ2R8bQywoXmyWwo0=; b=K/4EFCfQYVwB27FgifjZenfOQxLTqM+034covHPZEySAztk9OPyNetKUmgwkFtVae9 I75BLvvy7069YImc4PUSsxTnmpfVYOLy+opR/AiGpYviApH/IGxSor85Y1ExkQyMy9sh EeU3xv5f7wQ3sRBa00pNpYsbJPIZbj2SXNF0PZPoLMknJS6wA3RxeJsLUvBVNTDvmxOO IodcyQQuk12zDv+Z8y43/dY9WU0P5bWnqpklQgGEBXsqv6NcX8WRP9CEspHZSx8AXhlK 9A46o8q5kURsKJQnz2CRJLORB4Jgftt+KHQJJqQN3UjdAP+recPCSGheSsqMzualBelK U8YQ== X-Gm-Message-State: ALoCoQka9nUIwObZ0qtxH0T5eYCS2B4FQqpZKdU7pt3d+k+z/g7+FwXQvm27RnyfySZb4k8GFt2j X-Received: by 10.55.51.77 with SMTP id z74mr113855654qkz.84.1427065329422; Sun, 22 Mar 2015 16:02:09 -0700 (PDT) Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id j66sm8006327qgf.25.2015.03.22.16.02.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2015 16:02:08 -0700 (PDT) Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id BD133AC282F; Sun, 22 Mar 2015 19:02:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Stephen Checkoway In-Reply-To: Date: Sun, 22 Mar 2015 19:02:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1872FE63-1C6C-4D6C-AA8E-A4F768674444@pahtak.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 23:02:11 -0000 On Mar 22, 2015, at 5:49 PM, Eric Rescorla wrote: > RECOMMENDATION > As I said, I think we do need to supply some sort of limited 0-RTT > functionality. Given the practical difficulty of making global state > work, I think it's a mistake to build a system which relies on > this. The remaining two options require that we relax one of TLS's > guarantees and of these, relaxing reliable delivery seems safer, > and it also makes the implementation rather easier. >=20 > Accordingly, I propose that we continue to develop 0-RTT but with the > server just dropping 0-RTT first-flight data when 0-RTT is not > possible (and of course telling the client it is doing so). The > client application can then retransmit if it believes it is safe. > In the very limited cases where application domains can in fact > safely keep state, they can profile the use of TLS to that end > and require the endpoints to behave appropriately. None of the options makes me very happy and I'm really concerned that = applications and/or implementations will mess this up and it'll lead to = a vulnerability. If we absolutely must support 0-RTT (and I believe that we do), then I = agree with ekr that relaxing reliable delivery of the first-flight data = is the least bad choice. I'm not sure how in-scope API recommendations are, but I think that = first flight data absolutely needs to be an explicit API call. That is, = something like c =3D new TLSConnection(...) c.write(data) SHOULD NOT send data along with the handshake. Ekr's = setUnreliable0RTTData really seems like the way to go. --=20 Stephen Checkoway From nobody Sun Mar 22 16:24: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 CC92A1A802D for ; Sun, 22 Mar 2015 16:24:05 -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 raFpGZcEh1S3 for ; Sun, 22 Mar 2015 16:24:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AA4A71A802A for ; Sun, 22 Mar 2015 16:24:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [199.227.110.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 0826DF984; Sun, 22 Mar 2015 19:24:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BEE8120092; Sun, 22 Mar 2015 18:23:57 -0500 (CDT) From: Daniel Kahn Gillmor To: Stephen Checkoway , Eric Rescorla In-Reply-To: <1872FE63-1C6C-4D6C-AA8E-A4F768674444@pahtak.org> References: <1872FE63-1C6C-4D6C-AA8E-A4F768674444@pahtak.org> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 22 Mar 2015 18:23:57 -0500 Message-ID: <87sicwboqa.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Mar 2015 23:24:06 -0000 On Sun 2015-03-22 18:02:05 -0500, Stephen Checkoway wrote: > None of the options makes me very happy and I'm really concerned that applications and/or implementations will mess this up and it'll lead to a vulnerability. i share this sentiment. > If we absolutely must support 0-RTT (and I believe that we do), then I agree with ekr that relaxing reliable delivery of the first-flight data is the least bad choice. Calling it "unreliable" in the sense that we can't guarantee that it will get through sounds likely to mislead users. In fact, the "unreliability" is that we don't know whether the data was accepted and processed by the remote server or not (particularly, in the case of a distributed service, which the client probably can't distinguish). So in practice, the data sent in the first flight needs to be seen as "replayable" in some sense. If it is rejected by the server but the handshake continues, then the client has three options as it crafts its 1-rtt reply: 0) send the same payload again 1) send some different payload (with the same semantics) 2) send some different payload with different semantics 3) abort the connection and surface the error to the user in cases 0 and 1, the first 0rtt payload could actually still be processed by some other server, and the client would never know about it. So case 0 is strictly "replayable" (as in, the attacker can cause the same payload to take effect twice) and case 1 is "semantically replayable". I'm having trouble getting my head around any cases that fall into case 2, and case 3 is what ekr called "implausible". so "replayable" still seems like the right way to declare this flight to users, even though it sounds worse than "unreliable". > I'm not sure how in-scope API recommendations are, but I think that first flight data absolutely needs to be an explicit API call. That is, something like > > c = new TLSConnection(...) > c.write(data) > > SHOULD NOT send data along with the handshake. Ekr's setUnreliable0RTTData really seems like the way to go. c = new TLSConnection(replayableData,...) if c.replayableDataSucceeded : c.write(nextFlight) else: .... I think there are lots of ways that developers can get burned here. Even testing these codepaths is tricky. --dkg From nobody Sun Mar 22 17:59: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 77A5C1A872A for ; Sun, 22 Mar 2015 17:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voDRdMl9Myq1 for ; Sun, 22 Mar 2015 17:59:48 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EE91A8726 for ; Sun, 22 Mar 2015 17:59:48 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-06v.sys.comcast.net with comcast id 6ozM1q00153iAfU01oznC3; Mon, 23 Mar 2015 00:59:47 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-10v.sys.comcast.net with comcast id 6ozm1q00B4uhcbK01ozmTU; Mon, 23 Mar 2015 00:59:47 +0000 Message-ID: <550F6582.9040602@brainhub.org> Date: Sun, 22 Mar 2015 17:59:46 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1427072387; bh=T7gMwz8obiOTuI3j8sP0GLny6o/i8xhG1fQ5gllBzgs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MzrmdfG0EPZnWi7t78cohdNVncEr0V2rpgTT0hbtxyHJU3ZCYLnUBlfrVuA4+NhvG 7JRbbXIZ6xJzOIt86dv8ghKMdGGezeSwRinPCuG4u/X/Hhx8w/oOV7xEkGFytQMohJ n+KfnfAVCIg/EVVtpi5a4n7UiS9+eRKZFaOcQNN2EsXAzI0XGXzrOOytAdIk6zVuiN cw289FUmXF36aDNRWgg4gS+mIRK0ragwXinkd3TmQplX3ByVllh+55AAkx/+n41dZd dppcrNxaAvZekOUj9nfGf/dgE4aOoQ24BgumkXpQt1igOImVrMwQpaZ9V6BOXHfcEr SMtQnMbgde6Aw== Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 00:59:51 -0000 On 03/22/2015 02:49 PM, Eric Rescorla wrote: > In the interim in Seattle, we had an extensive discussion of 0-RTT > anti-replay in which DKG observed that all the proposed anti-replay > mechanisms provide limited protection. The underlying problem is the > desire to present a uniform interface in which the calling application > can count on reliable delivery of the data it provides in the first > flight, thus requiring the TLS stack to retransmit it automatically. > > This message describes the problem and should set us up for a > discussion about the topic in Dallas. Apologies in advance for > the length of this, but I'd like to be clear. > > > BACKGROUND: ANTI-REPLAY > As you'll recall, TLS ordinarily uses a server-provided random value > mixed into the keys for anti-replay. This obviously doesn't work for > 0-RTT. For reference, here's a simplified description of the way that > (and the way that both QUIC and snap-start do it). > > - The server keeps a list of every ClientRandom it has received > within a given time window keyed by a server context ("orbit") > value that loosely can be thought of as indicating the data center. > > - When the server receives a new ClientHello, it checks to > see if it has seen it before and then rejects the connection. > > Now consider what happens when the server reboots and loses its > state. You don't want to reject every client 0-RTT connection so I think what you are proposing here is to treat a mismatch in 0-RTT parameters as "re-negotiate", similar to the SessionID-based reuse logic. See more below. > instead what you do is you ignore the client's initial data sent in > the first flight. Since the ServerHello provides a new Random value, > any data the client sends in subsequent flights has the usual > anti-replay protection. > > > A SOMEWHAT CONTRIVED ATTACK > This is all fine so far, but the abstraction you probably want TLS to > supply to the application is that the data it sends in the first > flight isn't lost even in this case. In order to accomodate this, the > natural design is for the TLS stack to retransmit the plaintext in the > client's first flight as the first data it sends under the new keys. > > An attacker can make use of this as follows. When the client sends > the initial first flight he captures the TCP connection and makes his > own TCP connection to the server, forwarding the first flight. > > Client Attacker Server > > ClientHello [+0-RTT] ------------> > "POST /buy-something" -----------> > > ClientHello [+0-RTT] ---------------> > "POST /buy-something" --------------> > [Processes purchase] > <---------- ServerHello [accept 0-RTT] > (+ rest of handshake) > > > The attacker just discards the server's response and then the server > somehow forces the server to reboot (this is the hard part). > > Once the server has rebooted, the attacker re-sends the client's > initial flight then just forwards data back and forth to the client. > > Client Attacker Server > ClientHello [+0-RTT] ---------------> > "POST /buy-something" --------------> > > <-------------------------------------- ServerHello [reject 0-RTT] > (+ rest of handshake) > > Finished ---------------------------------------------------------> > "Post /buy-something" --------------------------------------------> > [Processes purchase] > > At this point, you've mounted a successful replay attack. Obviously > this is not that great an attack because it requires you to be able to > force a reboot and also get in under the client's timeout window. > > > A MORE REALISTIC ATTACK > During the interim meeting, DKG observed that you could produce the > same "I've forgotten my state" situation if you have a distributed > server. Say that the server operates in two loosely-synchronized > data centers. In that case, you can get the following situation > (shown without the attacker's intervention because of ASCII art > limitation > > Client Attacker Server1 Server 2 > > ClientHello [+0-RTT] --> > "POST /buy-something" -> > > ClientHello [+0-RTT] --> > "POST /buy-something" -> > [Processes > purchase] > > > > ClientHello [+0-RTT] -----------------------> > "POST /buy-something" ----------------------> > > > <-------------------------------------- ServerHello [reject 0-RTT] > (+ rest of handshake) > > Finished ---------------------------------------------------------> > "Post /buy-something" --------------------------------------------> > [Processes purchase] > > Again, the attacker will need to mess with the TCP channel, but their > ability to do so is part of our basic threat model [RFC 3552]. > > It's important to understand that this is a generic issue, not an > issue with TLS in particular, so it's not like there's some other > 0-RTT model we can lift and put into TLS that would solve the problem. The SessionID-like fallback is a problem for a "broadcast" of the single "POST /buy-something" (via a replay of a captured message). Had the Server 2 above rejected the ClientHello [+0-RTT] which was intended for Server 1 (orbit1), there would be no problem. One way to solve this is to say that the server must *fail* 0-RTT, as opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is not that of this server. The only requirement here is that the server always knows its orbit. Servers must have different orbit IDs if they cannot handle simultaneous receipt of identical "POST /buy-something". Regarding the forced server reboot. The practical issue here, it seems, is that it's difficult to keep the state of the global purchasing DB updated, so that the HTTP requests issued (replayed) simultaneously to servers across the globe are verified. This is less of a problem when TLS pins the request to the same copy of the local DB, identified by orbit ID. > > > APPROACHES > One way to address this would be to simply not provide a 0-RTT mode. > This is a charter item, so that would be sad, but obviously that's not > out of the question if we really think this is bad. The more serious > question is that there's an enormous demand for this feature (see, for > instance, the discussion at the SEMI workshop), and so if we refuse to > do a 0-RTT mode, we're giving applications the annoying choice of > accepting a RTT or inventing their own 0-RTT method. > > > There are a number of basic ways to address this issue, but I think > the main plausible[0] ones are: > > 1. Keep the server state globally consistent and also temporally > consistent so that replays can always be detected. > > 2. Remove the TLS anti-replay guarantee for the data sent in the first > flight and tell applications to only send data there that can > tolerate being replayed. > > 3. Remove the TLS reliable delivery guarantee for the data sent in > the first flight, so that the stack doesn't automatically replay it. > > The first of these options (global state) is possible, but only in > some limited circumstances, namely very sophisticated operators and/or > situations where there's really only one server which has good state > management. An example of the latter is WebRTC, where the server can > have a different anti-replay context for each connection. > > The other two options clearly require a separate API to handle this > special first-flight data and would require applications to handle it > separately. So, for instance, in option 2, you would have something > like: > > c = new TLSConnection(...) > c.setReplayable0RTTData("GET /....") > c.connect(); > > And in the case of option 3 you would have something like: > > c = new TLSConnection(...) > c.setUnreliable0RTTData("GET /....") > c.connect() > if (c.delivered0RTTData()) { > // Things are cool > } else { > // Try to figure out whether to replay or not > } > So in the former case, the choice of replay is in the TLS > stack's hands but in the latter in the application's hands. > > I would expect them to have relatively similar impacts on the wire, > namely applications would self-designate certain data as replay-safe > (e.g., HTTP GETs) and would send it in the first flight and then > either let the stack retransmit (option 2) or retransmit themselves > (option 3). This isn't that odd, since, as AGL observes, browsers > already routinely retry some HTTP requests that appear to fail even for > ordinary TLS (i.e., no HTTP response was received) so in those cases > they have already circumvented the anti-replay guarantees supplied by > TLS, but of course that's different from having TLS give up those > guarantees. > > > RECOMMENDATION > As I said, I think we do need to supply some sort of limited 0-RTT > functionality. Given the practical difficulty of making global state > work, I think it's a mistake to build a system which relies on > this. The remaining two options require that we relax one of TLS's > guarantees and of these, relaxing reliable delivery seems safer, > and it also makes the implementation rather easier. > > Accordingly, I propose that we continue to develop 0-RTT but with the > server just dropping 0-RTT first-flight data when 0-RTT is not > possible (and of course telling the client it is doing so). The > client application can then retransmit if it believes it is safe. > In the very limited cases where application domains can in fact > safely keep state, they can profile the use of TLS to that end > and require the endpoints to behave appropriately. > > Thanks, > -Ekr > > > [0] One implausible approach is to treat any attempt to 0-RTT when > you have lost state as a hard-fail, but this will create a lot of > random failures, so it's not really practical. ... From nobody Sun Mar 22 18:53: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 8339F1A8761 for ; Sun, 22 Mar 2015 18:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbnJbOXo1Z17 for ; Sun, 22 Mar 2015 18:53:40 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (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 C86F31A875E for ; Sun, 22 Mar 2015 18:53:40 -0700 (PDT) Received: by oiag65 with SMTP id g65so129735689oia.2 for ; Sun, 22 Mar 2015 18:53:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CVdfVslWNQRrCxHl7YP5KHP1nnkRxT6Az/ION12ABxw=; b=gLgHCM20xB+Hkc+FsxyPeZ1G7FD1HiZauaLrgUWWB1tLSdUMXCXgO1uhOxeO+DN3Qk SPvrWxGh72f7btJQJCwMzweVv++bNkUId0w+9xSV+nY02rCmlF6fqJHxsoe1QuiOIRbR 29kP39RvqRARjuapnKcKx+cR6v/4tQ7/YGLvWv58VlL8uDJo1dVLBqlvSDDOXkWGFptX ORyAE7D6gNA3Z7oW6zFwZwNGj9yhc5WsyS6TolHE06fTfZIxQG38wq2FDdExk6uS2zje uUF2Q4cl1cKi2fIMMXQ7PzoW7aZD4tB2+bKNMpi6MMKMAyMn0OrCSse8GHtq97BP3fh+ l1sg== X-Gm-Message-State: ALoCoQlMYPF7trtyB2DiiLNRhaoBJYlQRNrR2cAjY74/kaan6MGFQrgp5xEswGwTPQi5b8tcd69E MIME-Version: 1.0 X-Received: by 10.60.82.10 with SMTP id e10mr15381045oey.85.1427075620216; Sun, 22 Mar 2015 18:53:40 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Sun, 22 Mar 2015 18:53:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 15:53:40 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:53:42 -0000 Eric Rescorla wrote: > Obviously, if we want to move to PSS, option #2 is simplest, but > the sentiment at the interim was to survey the WG to see whether > there was widespread enough support for generating and verifying > PSS to make this feasible [0]. PSS with which parameters? My suggestion is that, if PSS is used, (SHA-256, MGF-SHA-256, 32-byte salt) should be used with the SHA-256-based PRF and that (SHA-384, MGF-SHA-384, 48-byte salt) should be used with the SHA-384-based PRFs. [1] notes that there is a security advantage to using the same digest function for the MGF as was used for digesting the signed data. It would be a mistake to mandate support for MGF-SHA-1 in PSS signatures in TLS 1.3, because a TLS 1.3 implementation shouldn't be need to implement SHA-1 at all. Some implementations are hard-coded to support only MGF-SHA-1 and 20 byte salts. It is better to require those implementations to be updated than to require all implementations to implement SHA-1 just for the MGF. Cheers, Brian [1] https://tools.ietf.org/html/rfc3447#section-8.1 From nobody Sun Mar 22 19:11: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 7544E1A8773 for ; Sun, 22 Mar 2015 19:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBI91zuwe6IR for ; Sun, 22 Mar 2015 19:10:57 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 35C6B1A8772 for ; Sun, 22 Mar 2015 19:10:57 -0700 (PDT) Received: by oier21 with SMTP id r21so130029759oie.1 for ; Sun, 22 Mar 2015 19:10:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Om4xy2KOTMHiekQxx1sA4PNaiZ1n9B88PNtNpL4vrYM=; b=BaSJMzz80zN9K5aIP7lTNshoVfxUbeqv4f1Dib+XW260HRt0HXYM/lZaRHXaZInWDb RR9QYtH2Qgvk6SVohs44HQK42QXZ/9erw3hBDRMM8u6WkLvpfXixYF4ZYZu+/cNGyYrL zzEp1sbRt79rPRcYZcGVMT+hCsxnWenbF1KkfZrNEuYgL2e2PJrM1HS9y5xLAuKKW8M2 QHL5v+07PFNw0UJsCj+9JtBVHZl7PUMo53/DoS9KKBVK3viQUPOnwZcUqsN6uxHScbRr +6LyZZlBmAGo+5xmKyZhjsnPl4O40xczWMBQA+2j6w1CxWy+P2O1EjHf8nVLdoomQwEB fxAA== X-Gm-Message-State: ALoCoQneBxw62P3/G4YN/fZptnPyQSGBqgM3LEgkb5/vkL+NifsBXh7RsReGIANFsDgH7oG1atoa MIME-Version: 1.0 X-Received: by 10.60.35.102 with SMTP id g6mr30261698oej.7.1427076656675; Sun, 22 Mar 2015 19:10:56 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Sun, 22 Mar 2015 19:10:56 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 16:10:56 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 02:10:58 -0000 Eric Rescorla wrote: > Adam, Brian, what would you think of XOR rather than addition? > > E.g., generate a per-connection value V and then do: > > Nonce = Seq XOR V? Would the sequence number be logically the same size as the nonce (128 bits or 256 bits), or would the spec will forbid sending 2^64 or more records under the same key? Either solution prevents the need to worry about the record number overflowing, but my answer depends on which approach is chosen. The advantage of XOR is that it is easy to implement correctly, because mutli-machine-word XOR is easier to implement than multi-machine-word unsigned integer addition with wraparound during overflow. However, XOR is also easier to implement *wrongly* without anybody noticing, by only doing the XOR for a single machine word (e.g. only the lower 32 bits on a 32-bit machine). It's not so practical to do a conformance test that sends/receives 2^32+1 or 2^64+1 records.. It seems harder to implement addition wrongly without anybody noticing because all of the overflow cases should be triggered during interop testing and thus any bugs found and corrected. So, without knowing the answer to my question above, I prefer addition. Cheers, Brian From nobody Sun Mar 22 20:20: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 BB6721A87A2 for ; Sun, 22 Mar 2015 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o3W03yk0Uwz for ; Sun, 22 Mar 2015 20:19:56 -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 235851A87A1 for ; Sun, 22 Mar 2015 20:19:56 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so48865308wib.1 for ; Sun, 22 Mar 2015 20:19: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=RCzw5knlgA/x2NzQDPfm6LzxI7O7mdWbzqZJQMRP7sk=; b=CbvAZkBZhjFviwHJH8ylQSX1fs5/saKuyEXy4WMKZ9NOSVx1ERkAAZMCtN0eZEz2nv ibkqcB5/OuaiBW5fbxxSXPNmBjH4rfuRH0luylDOvkbLuiqV+p3EGf8Dn8PWq6syiWqQ OW664yehZjlCJB4Zs9jo69Ga3BxoiafWWHjCdQUs81lKelzIXQel1CfdqEiDJgLGRMdS 9LSJY+mvmMePo931lgz6cZm/1ZHfFpv5lSUg8gwycVYTjKNHldQ3AKoGocnJDrveHRe2 8jBI1cTD7qZEUoDFYFnneYbVpMGy2XWZM45wUX6kBdxs3VGU2pPjAyZQwo5H3pyP/XjK FlYA== X-Gm-Message-State: ALoCoQnVGM+p40KLZNiBzB13KAhpjs1QN580Hz06DJo6Hi74KV/RAHhFgfzdcLqKXw9/5PquBaTa X-Received: by 10.194.178.164 with SMTP id cz4mr13060048wjc.140.1427080794810; Sun, 22 Mar 2015 20:19:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 20:19:14 -0700 (PDT) In-Reply-To: <550F6582.9040602@brainhub.org> References: <550F6582.9040602@brainhub.org> From: Eric Rescorla Date: Sun, 22 Mar 2015 20:19:14 -0700 Message-ID: To: Andrey Jivsov Content-Type: multipart/alternative; boundary=089e013d1672d744270511ec2335 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:20:00 -0000 --089e013d1672d744270511ec2335 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 5:59 PM, Andrey Jivsov wrote: > On 03/22/2015 02:49 PM, Eric Rescorla wrote: > >> In the interim in Seattle, we had an extensive discussion of 0-RTT >> anti-replay in which DKG observed that all the proposed anti-replay >> mechanisms provide limited protection. The underlying problem is the >> desire to present a uniform interface in which the calling application >> can count on reliable delivery of the data it provides in the first >> flight, thus requiring the TLS stack to retransmit it automatically. >> >> This message describes the problem and should set us up for a >> discussion about the topic in Dallas. Apologies in advance for >> the length of this, but I'd like to be clear. >> >> >> BACKGROUND: ANTI-REPLAY >> As you'll recall, TLS ordinarily uses a server-provided random value >> mixed into the keys for anti-replay. This obviously doesn't work for >> 0-RTT. For reference, here's a simplified description of the way that >> (and the way that both QUIC and snap-start do it). >> >> - The server keeps a list of every ClientRandom it has received >> within a given time window keyed by a server context ("orbit") >> value that loosely can be thought of as indicating the data center. >> >> - When the server receives a new ClientHello, it checks to >> see if it has seen it before and then rejects the connection. >> >> Now consider what happens when the server reboots and loses its >> state. You don't want to reject every client 0-RTT connection so >> > > I think what you are proposing here is to treat a mismatch in 0-RTT > parameters as "re-negotiate", similar to the SessionID-based reuse logic. > > See more below. > > > instead what you do is you ignore the client's initial data sent in >> the first flight. Since the ServerHello provides a new Random value, >> any data the client sends in subsequent flights has the usual >> anti-replay protection. >> >> >> A SOMEWHAT CONTRIVED ATTACK >> This is all fine so far, but the abstraction you probably want TLS to >> supply to the application is that the data it sends in the first >> flight isn't lost even in this case. In order to accomodate this, the >> natural design is for the TLS stack to retransmit the plaintext in the >> client's first flight as the first data it sends under the new keys. >> >> An attacker can make use of this as follows. When the client sends >> the initial first flight he captures the TCP connection and makes his >> own TCP connection to the server, forwarding the first flight. >> >> Client Attacker Server >> >> ClientHello [+0-RTT] ------------> >> "POST /buy-something" -----------> >> >> ClientHello [+0-RTT] ---------------> >> "POST /buy-something" --------------> >> [Processes purchase] >> <---------- ServerHello [accept 0-RTT] >> (+ rest of handshake) >> >> >> The attacker just discards the server's response and then the server >> somehow forces the server to reboot (this is the hard part). >> >> Once the server has rebooted, the attacker re-sends the client's >> initial flight then just forwards data back and forth to the client. >> >> Client Attacker Server >> ClientHello [+0-RTT] ---------------> >> "POST /buy-something" --------------> >> >> <-------------------------------------- ServerHello [reject 0-RTT] >> (+ rest of handshake) >> >> Finished ---------------------------------------------------------> >> "Post /buy-something" --------------------------------------------> >> [Processes purchase] >> >> At this point, you've mounted a successful replay attack. Obviously >> this is not that great an attack because it requires you to be able to >> force a reboot and also get in under the client's timeout window. >> >> >> A MORE REALISTIC ATTACK >> During the interim meeting, DKG observed that you could produce the >> same "I've forgotten my state" situation if you have a distributed >> server. Say that the server operates in two loosely-synchronized >> data centers. In that case, you can get the following situation >> (shown without the attacker's intervention because of ASCII art >> limitation >> >> Client Attacker Server1 Server 2 >> >> ClientHello [+0-RTT] --> >> "POST /buy-something" -> >> >> ClientHello [+0-RTT] --> >> "POST /buy-something" -> >> [Processes >> purchase] >> >> >> >> ClientHello [+0-RTT] -----------------------> >> "POST /buy-something" ----------------------> >> >> >> <-------------------------------------- ServerHello [reject 0-RTT] >> (+ rest of handshake) >> >> Finished ---------------------------------------------------------> >> "Post /buy-something" --------------------------------------------> >> [Processes purchase] >> >> Again, the attacker will need to mess with the TCP channel, but their >> ability to do so is part of our basic threat model [RFC 3552]. >> >> It's important to understand that this is a generic issue, not an >> issue with TLS in particular, so it's not like there's some other >> 0-RTT model we can lift and put into TLS that would solve the problem. >> > > The SessionID-like fallback is a problem for a "broadcast" of the single > "POST /buy-something" (via a replay of a captured message). Had the Server > 2 above rejected the ClientHello [+0-RTT] which was intended for Server 1 > (orbit1), there would be no problem. > > One way to solve this is to say that the server must *fail* 0-RTT, as > opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello > is not that of this server. > Yeah, this is what I claimed is "implausible" in my original message. My concern here is that this basically means that implementations get punished with random failures for any data center/routing instabilities... -Ekr > The only requirement here is that the server always knows its orbit. > Servers must have different orbit IDs if they cannot handle simultaneous > receipt of identical "POST /buy-something". > > Regarding the forced server reboot. The practical issue here, it seems, is > that it's difficult to keep the state of the global purchasing DB updated, > so that the HTTP requests issued (replayed) simultaneously to servers > across the globe are verified. This is less of a problem when TLS pins the > request to the same copy of the local DB, identified by orbit ID. > > > > >> >> APPROACHES >> One way to address this would be to simply not provide a 0-RTT mode. >> This is a charter item, so that would be sad, but obviously that's not >> out of the question if we really think this is bad. The more serious >> question is that there's an enormous demand for this feature (see, for >> instance, the discussion at the SEMI workshop), and so if we refuse to >> do a 0-RTT mode, we're giving applications the annoying choice of >> accepting a RTT or inventing their own 0-RTT method. >> >> >> There are a number of basic ways to address this issue, but I think >> the main plausible[0] ones are: >> >> 1. Keep the server state globally consistent and also temporally >> consistent so that replays can always be detected. >> >> 2. Remove the TLS anti-replay guarantee for the data sent in the first >> flight and tell applications to only send data there that can >> tolerate being replayed. >> >> 3. Remove the TLS reliable delivery guarantee for the data sent in >> the first flight, so that the stack doesn't automatically replay it. >> >> The first of these options (global state) is possible, but only in >> some limited circumstances, namely very sophisticated operators and/or >> situations where there's really only one server which has good state >> management. An example of the latter is WebRTC, where the server can >> have a different anti-replay context for each connection. >> >> The other two options clearly require a separate API to handle this >> special first-flight data and would require applications to handle it >> separately. So, for instance, in option 2, you would have something >> like: >> >> c = new TLSConnection(...) >> c.setReplayable0RTTData("GET /....") >> c.connect(); >> >> And in the case of option 3 you would have something like: >> >> c = new TLSConnection(...) >> c.setUnreliable0RTTData("GET /....") >> c.connect() >> if (c.delivered0RTTData()) { >> // Things are cool >> } else { >> // Try to figure out whether to replay or not >> } >> So in the former case, the choice of replay is in the TLS >> stack's hands but in the latter in the application's hands. >> >> I would expect them to have relatively similar impacts on the wire, >> namely applications would self-designate certain data as replay-safe >> (e.g., HTTP GETs) and would send it in the first flight and then >> either let the stack retransmit (option 2) or retransmit themselves >> (option 3). This isn't that odd, since, as AGL observes, browsers >> already routinely retry some HTTP requests that appear to fail even for >> ordinary TLS (i.e., no HTTP response was received) so in those cases >> they have already circumvented the anti-replay guarantees supplied by >> TLS, but of course that's different from having TLS give up those >> guarantees. >> >> >> RECOMMENDATION >> As I said, I think we do need to supply some sort of limited 0-RTT >> functionality. Given the practical difficulty of making global state >> work, I think it's a mistake to build a system which relies on >> this. The remaining two options require that we relax one of TLS's >> guarantees and of these, relaxing reliable delivery seems safer, >> and it also makes the implementation rather easier. >> >> Accordingly, I propose that we continue to develop 0-RTT but with the >> server just dropping 0-RTT first-flight data when 0-RTT is not >> possible (and of course telling the client it is doing so). The >> client application can then retransmit if it believes it is safe. >> In the very limited cases where application domains can in fact >> safely keep state, they can profile the use of TLS to that end >> and require the endpoints to behave appropriately. >> >> Thanks, >> -Ekr >> >> >> [0] One implausible approach is to treat any attempt to 0-RTT when >> you have lost state as a hard-fail, but this will create a lot of >> random failures, so it's not really practical. >> > ... > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e013d1672d744270511ec2335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 5:59 PM, Andrey Jivsov <crypto@brainhub.org<= /a>> wrote:
On= 03/22/2015 02:49 PM, Eric Rescorla wrote:
In the interim in Seattle, we had an extensive discussion of 0-RTT
anti-replay in which DKG observed that all the proposed anti-replay
mechanisms provide limited protection. The underlying problem is the
desire to present a uniform interface in which the calling application
can count on reliable delivery of the data it provides in the first
flight, thus requiring the TLS stack to retransmit it automatically.

This message describes the problem and should set us up for a
discussion about the topic in Dallas. Apologies in advance for
the length of this, but I'd like to be clear.


BACKGROUND: ANTI-REPLAY
As you'll recall, TLS ordinarily uses a server-provided random value mixed into the keys for anti-replay. This obviously doesn't work for 0-RTT. For reference, here's a simplified description of the way that (and the way that both QUIC and snap-start do it).

- The server keeps a list of every ClientRandom it has received
=C2=A0 =C2=A0within a given time window keyed by a server context ("or= bit")
=C2=A0 =C2=A0value that loosely can be thought of as indicating the data ce= nter.

- When the server receives a new ClientHello, it checks to
=C2=A0 =C2=A0see if it has seen it before and then rejects the connection.<= br>
Now consider what happens when the server reboots and loses its
state. You don't want to reject every client 0-RTT connection so

 I think what you are proposing here is to treat a mismatch in 0-RTT paramet= ers as "re-negotiate", similar to the SessionID-based reuse logic= .

See more below.


instead what you do is you ignore the client's initial data sent in
the first flight. Since the ServerHello provides a new Random value,
any data the client sends in subsequent flights has the usual
anti-replay protection.


A SOMEWHAT CONTRIVED ATTACK
This is all fine so far, but the abstraction you probably want TLS to
supply to the application is that the data it sends in the first
flight isn't lost even in this case. In order to accomodate this, the natural design is for the TLS stack to retransmit the plaintext in the
client's first flight as the first data it sends under the new keys.
An attacker can make use of this as follows. When the client sends
the initial first flight he captures the TCP connection and makes his
own TCP connection to the server, forwarding the first flight.

Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Attacker=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server

ClientHello [+0-RTT] ------------>
"POST /buy-something" ----------->

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello [+0-RTT] ---------------&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"POST /buy-something" -----= --------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Processes purchase]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <---------- ServerHello [a= ccept 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(+ rest of handshake)


The attacker just discards the server's response and then the server somehow forces the server to reboot (this is the hard part).

Once the server has rebooted, the attacker re-sends the client's
initial flight then just forwards data back and forth to the client.

Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Attacker=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello [+0-RTT] ---------------&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"POST /buy-something" -----= --------->

=C2=A0 =C2=A0 <--------------------------------------=C2=A0 Serve= rHello [reject 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (+ rest of handshake)

Finished ---------------------------------------------------------&g= t;
"Post /buy-something" ------------------------------------= -------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Processes purchase]

At this point, you've mounted a successful replay attack. Obviously
this is not that great an attack because it requires you to be able to
force a reboot and also get in under the client's timeout window.


A MORE REALISTIC ATTACK
During the interim meeting, DKG observed that you could produce the
same "I've forgotten my state" situation if you have a distri= buted
server. Say that the server operates in two loosely-synchronized
data centers. In that case, you can get the following situation
(shown without the attacker's intervention because of ASCII art
limitation

=C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Attacker=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Server 2

ClientHello [+0-RTT] -->
"POST /buy-something" ->

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0ClientHello [+0-RTT] -->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"POST /buy-something" ->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[P= rocesses
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p= urchase]



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0ClientHello [+0-RTT] ----------------------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"POST /buy-something" ---------------------->


=C2=A0 =C2=A0 <--------------------------------------=C2=A0 Serve= rHello [reject 0-RTT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (+ rest of handshake)

Finished ---------------------------------------------------------&g= t;
"Post /buy-something" ------------------------------------= -------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Processes purchase]

Again, the attacker will need to mess with the TCP channel, but their
ability to do so is part of our basic threat model [RFC 3552].

It's important to understand that this is a generic issue, not an
issue with TLS in particular, so it's not like there's some other 0-RTT model we can lift and put into TLS that would solve the problem.

The SessionID-like fallback is a problem for a "broadcast" of the= single "POST /buy-something" (via a replay of a captured message= ). Had the Server 2 above rejected the ClientHello [+0-RTT] which was inten= ded for Server 1 (orbit1), there would be no problem.

One way to solve this is to say that the server must *fail* 0-RTT, as oppos= ed to fallback to 1-RTT, if the "orbit" indicated in the ClientHe= llo is not that of this server.

Yeah, t= his is what I claimed is "implausible" in my original message.

My concern here is that this basically means that im= plementations get
punished with random failures for any data cent= er/routing instabilities...

-Ekr
=C2=A0<= /div>
The only requirement here is that the server always knows its orbit. Server= s must have different orbit IDs if they cannot handle simultaneous receipt = of identical "POST /buy-something".

Regarding the forced server reboot. The practical issue here, it seems, is = that it's difficult to keep the state of the global purchasing DB updat= ed, so that the HTTP requests issued (replayed) simultaneously to servers a= cross the globe are verified. This is less of a problem when TLS pins the r= equest to the same copy of the local DB, identified by orbit ID.





APPROACHES
One way to address this would be to simply not provide a 0-RTT mode.
This is a charter item, so that would be sad, but obviously that's not<= br> out of the question if we really think this is bad. The more serious
question is that there's an enormous demand for this feature (see, for<= br> instance, the discussion at the SEMI workshop), and so if we refuse to
do a 0-RTT mode, we're giving applications the annoying choice of
accepting a RTT or inventing their own 0-RTT method.


There are a number of basic ways to address this issue, but I think
the main plausible[0] ones are:

1. Keep the server state globally consistent and also temporally
=C2=A0 =C2=A0 consistent so that replays can always be detected.

2. Remove the TLS anti-replay guarantee for the data sent in the first
=C2=A0 =C2=A0 flight and tell applications to only send data there that can=
=C2=A0 =C2=A0 tolerate being replayed.

3. Remove the TLS reliable delivery guarantee for the data sent in
=C2=A0 =C2=A0 the first flight, so that the stack doesn't automatically= replay it.

The first of these options (global state) is possible, but only in
some limited circumstances, namely very sophisticated operators and/or
situations where there's really only one server which has good state management. An example of the latter is WebRTC, where the server can
have a different anti-replay context for each connection.

The other two options clearly require a separate API to handle this
special first-flight data and would require applications to handle it
separately. So, for instance, in option 2, you would have something
like:

=C2=A0 =C2=A0 =C2=A0c =3D new TLSConnection(...)
=C2=A0 =C2=A0 =C2=A0c.setReplayable0RTTData("GET /....")
=C2=A0 =C2=A0 =C2=A0c.connect();

And in the case of option 3 you would have something like:

=C2=A0 =C2=A0 =C2=A0c =3D new TLSConnection(...)
=C2=A0 =C2=A0 =C2=A0c.setUnreliable0RTTData("GET /....")
=C2=A0 =C2=A0 =C2=A0c.connect()
=C2=A0 =C2=A0 =C2=A0if (c.delivered0RTTData()) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Things are cool
=C2=A0 =C2=A0 =C2=A0} else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // Try to figure out whether to replay or not =C2=A0 =C2=A0 =C2=A0}
So in the former case, the choice of replay is in the TLS
stack's hands but in the latter in the application's hands.

I would expect them to have relatively similar impacts on the wire,
namely applications would self-designate certain data as replay-safe
(e.g., HTTP GETs) and would send it in the first flight and then
either let the stack retransmit (option 2) or retransmit themselves
(option 3). This isn't that odd, since, as AGL observes, browsers
already routinely retry some HTTP requests that appear to fail even for
ordinary TLS (i.e., no HTTP response was received) so in those cases
they have already circumvented the anti-replay guarantees supplied by
TLS, but of course that's different from having TLS give up those
guarantees.


RECOMMENDATION
As I said, I think we do need to supply some sort of limited 0-RTT
functionality. Given the practical difficulty of making global state
work, I think it's a mistake to build a system which relies on
this. The remaining two options require that we relax one of TLS's
guarantees and of these, relaxing reliable delivery seems safer,
and it also makes the implementation rather easier.

Accordingly, I propose that we continue to develop 0-RTT but with the
server just dropping 0-RTT first-flight data when 0-RTT is not
possible (and of course telling the client it is doing so).=C2=A0 The
client application can then retransmit if it believes it is safe.
In the very limited cases where application domains can in fact
safely keep state, they can profile the use of TLS to that end
and require the endpoints to behave appropriately.

Thanks,
-Ekr


[0] One implausible approach is to treat any attempt to 0-RTT when
you have lost state as a hard-fail, but this will create a lot of
random failures, so it's not really practical.
...

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

--089e013d1672d744270511ec2335-- From nobody Sun Mar 22 20:21: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 B729D1A87A4 for ; Sun, 22 Mar 2015 20:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1XB5RHP7WWc for ; Sun, 22 Mar 2015 20:21:10 -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 23CA51A87A6 for ; Sun, 22 Mar 2015 20:21:10 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so48884452wib.1 for ; Sun, 22 Mar 2015 20:21: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=f8RusdPan0N58VahWdJCKnzVo3aCgcUAraRFXTsYIjw=; b=M7iVYZ3MauaQVu1PSx1B2P4zP2ZB/jsfbtVAMc08VPpUPZyEX7HOA3hqmaYjp/wDzM WqLwOgp3jfyo5f9/Zz7mx5XmaLtD5ukiPUeynPMwcX19J7XoN3UTWU57Eh7x7SgLxX4R Zj5PP27St4A7tj0aMAg509nijy1NwGTFpOjujXW8plEzJjbAjbKIjMlko7SeMerPL0Dl jo1sZz6ogYPSdiZrgHGEAvlkLGUdurlsRTy7ayBoH+CZWBtFFxjskJ+YHkEp1MnlOUrr sj3ziJpQTYm7//H0GGXZcW5SEyEal0YprC3PxFmXBhc+Xk3/Hufgf1O+OqWoAN842JmC 6Siw== X-Gm-Message-State: ALoCoQmyl+VgbYRoKHa9SUocQSeMTCGpeuEbY8mfWFTMNJtxh65nie53JvgP5SDRzg96ZBOi1PEk X-Received: by 10.180.80.164 with SMTP id s4mr7963868wix.78.1427080868911; Sun, 22 Mar 2015 20:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 20:20:27 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 22 Mar 2015 20:20:27 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=14dae9cc9f9e41f07f0511ec2820 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:21:11 -0000 --14dae9cc9f9e41f07f0511ec2820 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 7:10 PM, Brian Smith wrote: > Eric Rescorla wrote: > > Adam, Brian, what would you think of XOR rather than addition? > > > > E.g., generate a per-connection value V and then do: > > > > Nonce = Seq XOR V? > > Would the sequence number be logically the same size as the nonce (128 > bits or 256 bits), or would the spec will forbid sending 2^64 or more > records under the same key? What I had in mind was the latter. -Ekr > Either solution prevents the need to worry > about the record number overflowing, but my answer depends on which > approach is chosen. > > The advantage of XOR is that it is easy to implement correctly, > because mutli-machine-word XOR is easier to implement than > multi-machine-word unsigned integer addition with wraparound during > overflow. However, XOR is also easier to implement *wrongly* without > anybody noticing, by only doing the XOR for a single machine word > (e.g. only the lower 32 bits on a 32-bit machine). It's not so > practical to do a conformance test that sends/receives 2^32+1 or > 2^64+1 records.. > > It seems harder to implement addition wrongly without anybody noticing > because all of the overflow cases should be triggered during interop > testing and thus any bugs found and corrected. So, without knowing the > answer to my question above, I prefer addition. > > Cheers, > Brian > --14dae9cc9f9e41f07f0511ec2820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 7:10 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> Adam, Brian, what would you think of XOR rather than addition?
>
> E.g., generate a per-connection value V and then do:
>
> Nonce =3D Seq XOR V?

Would the sequence number be logically the same size as the nonce (1= 28
bits or 256 bits), or would the spec will forbid sending 2^64 or more
records under the same key?

What I had in = mind was the latter.

-Ekr
=C2=A0
Either solution prevents the need to worry
about the record number overflowing, but my answer depends on which
approach is chosen.

The advantage of XOR is that it is easy to implement correctly,
because mutli-machine-word XOR is easier to implement than
multi-machine-word unsigned integer addition with wraparound during
overflow. However, XOR is also easier to implement *wrongly* without
anybody noticing, by only doing the XOR for a single machine word
(e.g. only the lower 32 bits on a 32-bit machine). It's not so
practical to do a conformance test that sends/receives 2^32+1 or
2^64+1 records..

It seems harder to implement addition wrongly without anybody noticing
because all of the overflow cases should be triggered during interop
testing and thus any bugs found and corrected. So, without knowing the
answer to my question above, I prefer addition.

Cheers,
Brian

--14dae9cc9f9e41f07f0511ec2820-- From nobody Sun Mar 22 20:21:45 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 C0A201A879A for ; Sun, 22 Mar 2015 20:21:44 -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 lujZFVM9ZOqV for ; Sun, 22 Mar 2015 20:21:43 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 D2DCE1A87A3 for ; Sun, 22 Mar 2015 20:21:42 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so48892685wib.1 for ; Sun, 22 Mar 2015 20:21:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=s02ZEjAvKCMv2f8Gqn22VHYbv6CsCHjgccNOIjbhZKc=; b=eLZj9OC9uotz3Ht3reY0vATKKj50n4Z62Hu7ubvqs6ULZJDRkK/FwiGc3ya8N8OOIY 8R+Ed8Mk9U9vz/l++r1hjHOuZugOM0iadvbSWeSy0SGZsJYLdufgKt3eeBq8/p5ZB6tS qk6KGfUuP7OzNin1DNOGBsRSxlwGYBHCrXArxg7lakL2pp90Kz/m1b2EzKsmzJKPc/2e VfdNtfN4rynhX0YwhvYbpA5zyBF8c2TAZClO9Px0+jOLAOP0P5UBh7mdsOEO300wILsV 2amoljZnX/nHR74iLthkfFa2mgaK52K+IGQVkBzctegEpu0I1vwUbOQCAE1jBVFkPdGO uBtQ== X-Gm-Message-State: ALoCoQnbEhTjsX6+AX2rjshGTq5gdRgNstTUc6yVB+xhwFBFNkx7ZFF/yv30xrlGkXSndkvaX+ce X-Received: by 10.194.121.10 with SMTP id lg10mr185123259wjb.71.1427080901668; Sun, 22 Mar 2015 20:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Sun, 22 Mar 2015 20:21:01 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 22 Mar 2015 20:21:01 -0700 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=089e0117715535c6b90511ec2ad1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:21:45 -0000 --089e0117715535c6b90511ec2ad1 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 6:53 PM, Brian Smith wrote: > Eric Rescorla wrote: > > Obviously, if we want to move to PSS, option #2 is simplest, but > > the sentiment at the interim was to survey the WG to see whether > > there was widespread enough support for generating and verifying > > PSS to make this feasible [0]. > > PSS with which parameters? > I would be fine with mandating a minimum of SHA-256. -Ekr > My suggestion is that, if PSS is used, (SHA-256, MGF-SHA-256, 32-byte > salt) should be used with the SHA-256-based PRF and that (SHA-384, > MGF-SHA-384, 48-byte salt) should be used with the SHA-384-based PRFs. > > [1] notes that there is a security advantage to using the same digest > function for the MGF as was used for digesting the signed data. It > would be a mistake to mandate support for MGF-SHA-1 in PSS signatures > in TLS 1.3, because a TLS 1.3 implementation shouldn't be need to > implement SHA-1 at all. > > Some implementations are hard-coded to support only MGF-SHA-1 and 20 > byte salts. It is better to require those implementations to be > updated than to require all implementations to implement SHA-1 just > for the MGF. > > Cheers, > Brian > > [1] https://tools.ietf.org/html/rfc3447#section-8.1 > --089e0117715535c6b90511ec2ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 6:53 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> Obviously, if we want to move to PSS, option #2 is simplest, but
> the sentiment at the interim was to survey the WG to see whether
> there was widespread enough support for generating and verifying
> PSS to make this feasible [0].

PSS with which parameters?

I wou= ld be fine with mandating a minimum of SHA-256.

-E= kr
=C2=A0
My suggestion is that, if PSS is used, (SHA-256, MGF-SHA-256, 32-byte
salt) should be used with the SHA-256-based PRF and that (SHA-384,
MGF-SHA-384, 48-byte salt) should be used with the SHA-384-based PRFs.

[1] notes that there is a security advantage to using the same digest
function for the MGF as was used for digesting the signed data. It
would be a mistake to mandate support for MGF-SHA-1 in PSS signatures
in TLS 1.3, because a TLS 1.3 implementation shouldn't be need to
implement SHA-1 at all.

Some implementations are hard-coded to support only MGF-SHA-1 and 20
byte salts. It is better to require those implementations to be
updated than to require all implementations to implement SHA-1 just
for the MGF.

Cheers,
Brian

[1] https://tools.ietf.org/html/rfc3447#section-8.1

--089e0117715535c6b90511ec2ad1-- From nobody Sun Mar 22 20:35: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 6E0371A87AD for ; Sun, 22 Mar 2015 20:35: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 EUYCyVIv8bYr for ; Sun, 22 Mar 2015 20:35:35 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 09C7D1A87AB for ; Sun, 22 Mar 2015 20:35:35 -0700 (PDT) Received: by oigv203 with SMTP id v203so130938530oig.3 for ; Sun, 22 Mar 2015 20:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5r8uB77hTxC83tXQ+9xbI0kdkhtp+KIKr97xqHdUX78=; b=NLgZr5f/VnHwglTMxNVmYKGqhjgZlbGF2VGj1nPh5fHcdEJ5+CJxxPYxpvAjOvNvau YZxhFoA4w39ba0q19wS4M6GahjtH4ZcrzuXz/As4Jod4x4r9DL8M3LIZ7GlHjIHubOf3 M4+qq3fRR2x0OxkfiBy8i2lwMWRmxudKZlt9Wz4sFe/rxMVm6NkWxaECeZLExcAtzuAy URZ6ptwg8tApPKJoRHP/PxNCREY43+jIFVwNvGvUbWgIZR4dJK9DAmHpc9om4FQ3Y1qZ FOMECYivM5R/Y37140YmpilhJhh8ThJMyxeT+l5akSE0NpC4ZHHE3K9xmqA3x95wJQAO T29A== MIME-Version: 1.0 X-Received: by 10.182.128.199 with SMTP id nq7mr51202530obb.47.1427081734483; Sun, 22 Mar 2015 20:35:34 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 20:35:34 -0700 (PDT) In-Reply-To: References: <550F6582.9040602@brainhub.org> Date: Sun, 22 Mar 2015 20:35:34 -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] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:35:36 -0000 On 22 March 2015 at 20:19, Eric Rescorla wrote: >> One way to solve this is to say that the server must *fail* 0-RTT, as >> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is >> not that of this server. > > > Yeah, this is what I claimed is "implausible" in my original message. > > My concern here is that this basically means that implementations get > punished with random failures for any data center/routing instabilities... I don't see any way that we can support a mode that fails with increased probability like this. I think that the only real options here are #2 and #3. I'm tending toward a requirement for marking the data as being explicitly replayable, simply because I don't think we should leave applications with the awkward choice of deciding between resend and something else. Mainly because I don't know what that something else looks like. For HTTP, I think we can use that first flight for idempotent queries quite easily and (at worst) the HTTP/2 connection preface. From nobody Sun Mar 22 20: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 057001A87AB for ; Sun, 22 Mar 2015 20:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo_Y3aXp_24T for ; Sun, 22 Mar 2015 20:37:19 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 D303F1A87A5 for ; Sun, 22 Mar 2015 20:37:18 -0700 (PDT) Received: by oigv203 with SMTP id v203so130958177oig.3 for ; Sun, 22 Mar 2015 20:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FsRHiXSbivEKJAKhK/k1p1kn6HsAbi3BL4NkUAw+ceI=; b=aYXE8iyIyE7loWWosAPM6KHsCHJbv1HbKd4kbVUKm3jYDz5px3dgcz361N7kTmGIdT H3ITU4jiyH4as1rUHJApbymGGayJJN3VQfHCG5YSUtZ2DRSBTEpL1l2Uuf011YJNPfeS Rt8IJcsNRxndAPls2JuZAECqsAbvMAC3o3s0GLmx0qlnzKfHktoXtiabCTUp8M2w3yXR zMIpcDAO3IEn4bhLcXrEJYYxfgkPymgAC0xJInWVN6BvVElb3MH30YOjme0ylFFIs1PC IvycmHYR/4N8JMja6xlyhQ0WqcJsj73DSE2s4eDYNwQW9Eb41uonKJoJYWOFUE0GsTks 7qlQ== MIME-Version: 1.0 X-Received: by 10.202.106.12 with SMTP id f12mr15125112oic.39.1427081838370; Sun, 22 Mar 2015 20:37:18 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sun, 22 Mar 2015 20:37:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 20:37:18 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:37:20 -0000 On 22 March 2015 at 20:20, Eric Rescorla wrote: >> Would the sequence number be logically the same size as the nonce (128 >> bits or 256 bits), or would the spec will forbid sending 2^64 or more >> records under the same key? > > > What I had in mind was the latter. I don't think that we are in a position to have more than 2^64 records sent. Not that I expect anyone will need that. (in the spirit of the 640K limit :) From nobody Sun Mar 22 20:38: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 3B5451A87AF for ; Sun, 22 Mar 2015 20:38: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 DFF99ou8c14U for ; Sun, 22 Mar 2015 20:38:30 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e: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 1A56B1A87AD for ; Sun, 22 Mar 2015 20:38:30 -0700 (PDT) Received: by pagv19 with SMTP id v19so2549657pag.2 for ; Sun, 22 Mar 2015 20:38: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=5bLjyuh77lMDLMwTmjiq07KT71P9uAUMdNw+1jZ60Eg=; b=LciU/ILP3Nte1fLpSfFCHwDiw4yy2d7ZEPN3/7zM1lIzaIB3ymiaWP9Gzu1W+tKtrO F9LVGi0hrorAPLfQlzzJcmV80Pwdb2FdiDPTx4RFJalzqDFljdfap9cZd+wMWRw04OId 82dlKDwox2PhqUHWP3aNu1OIsFvzCAbFBSbh9qBn8BUvIpiSYwbFjIsDgyh5zYlCPhFy WfSyU+NCRUBRg88PtgYn6d46+pOD24Dj3HX34sd4qf7yrzxveWlMx1bPKb3O44wLSWi2 G2GTS4Uzc3DQCcdC/sVi3hpaS0oBsIPZBPwxktLPjhNqUrPj5vQFE+qLJKawUPG873C3 QQiQ== MIME-Version: 1.0 X-Received: by 10.70.54.169 with SMTP id k9mr54496353pdp.135.1427081909795; Sun, 22 Mar 2015 20:38:29 -0700 (PDT) Received: by 10.70.104.4 with HTTP; Sun, 22 Mar 2015 20:38:29 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 20:38:29 -0700 Message-ID: From: Peter Bowen To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:38:31 -0000 On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla wrote: > During the interim we discussed discussion about adopting PSS for > RSA signatures in TLS 1.3. > > Clearly, we will not be able to just adopt PSS because certificates > will continue to be signed with PKCS#1 1.5. I would like to see TLS 1.3 allow certificates signed using PSS (RFC 4055 and 3447) and provide a way to signal the server that such certificates are supported. Currently there is no way to use PSS signed certificates with TLS at all, which is a problem. I agree with the move to EC* as the preferred algorithm, but it seems like enhancing non-EC signatures makes sense for the same reason as fixing FFDHE. Possibly the SignatureAlgorithm extension could carry both (1) rsa and (tbd) rsa-pss? Thanks, Peter From nobody Sun Mar 22 20:48: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 914471A87AF for ; Sun, 22 Mar 2015 20:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC5ucGWEt_M9 for ; Sun, 22 Mar 2015 20:48:15 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D1F1A87BB for ; Sun, 22 Mar 2015 20:48:15 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with comcast id 6roF1q0025AAYLo01roFHZ; Mon, 23 Mar 2015 03:48:15 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-15v.sys.comcast.net with comcast id 6roE1q00F4uhcbK01roE63; Mon, 23 Mar 2015 03:48:15 +0000 Message-ID: <550F8CFE.60201@brainhub.org> Date: Sun, 22 Mar 2015 20:48:14 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson , Eric Rescorla References: <550F6582.9040602@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1427082495; bh=DWxQMOEvI5papH6QYTjtDF87vqLOwjzJIrt7T75Pl74=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DTpCPnsDKbi5Ic/p/i0MD+By1OE3F0W4QokaB2w1vI78CO+gQ8ZTsMVtXffiha8W9 WXxubxJIB65gRC/bRB7ix8+QKAhCu2VCj9XEsS9jQtqaCzgAT1aL7/VKq9+CSkNgCO J6xjMiGCKgvWo/pxUDHo9tcMlzQEE9G2FXxgMW+d1ZVC4cj7s3V/i2HUiQ+Mtr4Nbg EEzknRM7eXzONrOWum59jE+C1c4QoZ/34Ady/40EFe7IuvOTEXbl5MNH37u5YwNiaj hfAsEPZu4Hxbp4c+I8Qkm1vx6+KFyHx0CT7FhEuIeO/XuVnCS5j/YJRpRvd/8MMSCM P2hnYGRhbsZaQ== Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:48:17 -0000 On 03/22/2015 08:35 PM, Martin Thomson wrote: > On 22 March 2015 at 20:19, Eric Rescorla wrote: >>> One way to solve this is to say that the server must *fail* 0-RTT, as >>> opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is >>> not that of this server. >> >> Yeah, this is what I claimed is "implausible" in my original message. >> >> My concern here is that this basically means that implementations get >> punished with random failures for any data center/routing instabilities... > I don't see any way that we can support a mode that fails with > increased probability like this. I think that the only real options > here are #2 and #3. I'm tending toward a requirement for marking the > data as being explicitly replayable, simply because I don't think we > should leave applications with the awkward choice of deciding between > resend and something else. Mainly because I don't know what that > something else looks like. > > For HTTP, I think we can use that first flight for idempotent queries > quite easily and (at worst) the HTTP/2 connection preface. I was thinking about in terms of two websites from different companies A and B. They are independent and they get different orbit IDs. If A sees an orbit ID of B that A would never have sent, this is a replay. An error is appropriate on such mismatch. Likewise, A, B can be divisions in the same company, in which case, again, there are different Orbit IDs and an error on mismatch. When A and B are load-balanced, e.g. by DNS entries, then A, B are in the same orbit. In this case they should use the same DB. (I probably re-defined the "orbit". In my proposal it's a persistent ID that survives the reboot ). If the data center is misconfigured or a client confused the origin of the 0-RTT state, isn't an error appropriate? Otherwise, yes, there would need to be restrictions on data sent in 0-RTT. From nobody Sun Mar 22 21:32: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 CA3AD1A0194 for ; Sun, 22 Mar 2015 21:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTcKKsJxKXzV for ; Sun, 22 Mar 2015 21:32:15 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) (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 1EFB91A0191 for ; Sun, 22 Mar 2015 21:32:15 -0700 (PDT) Received: by oiag65 with SMTP id g65so131590473oia.2 for ; Sun, 22 Mar 2015 21:32: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:date :message-id:subject:from:to:cc:content-type; bh=N+E05uW0wwZa1ZE+v71ooqNMsll/IlJ+faeip/UPta8=; b=Ie/tvx4cgEPAyGWzQlXfFJ44bQ1PP2BnStrWVzdIJAEN8h5kTuaWV9xp4zTV/fyp/t difbBIKXwxbDDxkTdydLeuNATy6PcXgzbrDLdincqqpaWon1ZoD70b29VrcEdT1na318 bff3ZwJsCDij5QW72QEgdG5XS6ZhVlQcw3My4QHsSSGEUFg80TWljhq2g7Kw2XtEAQ5n cJRZZbO2DjLzbOJjvsbyaYUHruRpCCFp7BsqjDSTkYpIW52jcBJSC4Ri6+Cbk//MehJk 7RLIobZPUH2cAFnYO/3TsG28TyfwfqtQNPO5nFK+nw4Rbs/+5iR5ECr3U6QWggc2csRm 3Kgg== X-Gm-Message-State: ALoCoQkiwFmJEPjmaPoqcpOVjpd1t3kPWsC91hymV91nLaLo8OtKfOKlcWTe2SI/xoa4ClkPSDOG MIME-Version: 1.0 X-Received: by 10.202.228.201 with SMTP id b192mr26756040oih.40.1427085134581; Sun, 22 Mar 2015 21:32:14 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Sun, 22 Mar 2015 21:32:14 -0700 (PDT) In-Reply-To: References: <550F6582.9040602@brainhub.org> Date: Sun, 22 Mar 2015 21:32:14 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 04:32:15 -0000 On Sun, Mar 22, 2015 at 8:35 PM, Martin Thomson wrote: > For HTTP, I think we can use that first flight for idempotent queries > quite easily and (at worst) the HTTP/2 connection preface. This seems so open to error as to be untenable. Quite a lot of HTTP based APIs are not idempotent, probably even the majority. Even where API calls can be made idempotent in the theoretical sense, in the real world there is often throttling and billing/metering state associated even just with the raw number of calls made. So they are non-idempotent by side-effect. -- Colm From nobody Sun Mar 22 22:21: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 D6D9F1A8830 for ; Sun, 22 Mar 2015 22:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-lJnRk8tDu9 for ; Sun, 22 Mar 2015 22:21:03 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.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 573311A883E for ; Sun, 22 Mar 2015 22:21:03 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so115388645obb.1 for ; Sun, 22 Mar 2015 22:21:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5uYeR6B7U2ufvvU0JqXIV9RLdO2+Sohs6HtN6TcU5Zg=; b=HtS9tdSVecVrKtw3ahFewoP8ohVH99GlGGg9LEK+k2TEnTsIw9gMZBKMFquPLSQtpJ VdaAt5Vtqx54+w9ZXjfL/UAmHszpN2rzU4n+nzUJWwDetKeHGYIowLB2v2uDJLcZmrZ3 zmPEx231CwcIFycCLLFFMYzLKRCEOVInsYKEI/rCxt+afLut+9k4cEXlJQo2qq4lEme2 oEctch+N+4SD4A5YMq5aMxiXTIXcaU1afH+NsPdlzq1Gi2dVJ4vqxMBl0oLB1uca/Jxf 9Z56HCcco7Yl7Ewzaul/hmUmCP0+/xg8qt14ekQBflW44tkfQwOLVOYTyzomtjlo/Ytf DpfA== X-Gm-Message-State: ALoCoQm0loAbTn2lB1MDJQqOAAYQzy5ULoMRVE+ntDKggl+MSsr4tJpl/wPLnEonTvwp6BDz0pvw MIME-Version: 1.0 X-Received: by 10.182.133.68 with SMTP id pa4mr74095934obb.87.1427088062789; Sun, 22 Mar 2015 22:21:02 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Sun, 22 Mar 2015 22:21:02 -0700 (PDT) In-Reply-To: References: Date: Sun, 22 Mar 2015 22:21:02 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:21:05 -0000 On Sun, Mar 22, 2015 at 2:49 PM, Eric Rescorla wrote: > > > A SOMEWHAT CONTRIVED ATTACK > This is all fine so far, but the abstraction you probably want TLS to > supply to the application is that the data it sends in the first > flight isn't lost even in this case. In order to accomodate this, the > natural design is for the TLS stack to retransmit the plaintext in the > client's first flight as the first data it sends under the new keys. > > An attacker can make use of this as follows. When the client sends > the initial first flight he captures the TCP connection and makes his > own TCP connection to the server, forwarding the first flight. > > Client Attacker Server > > ClientHello [+0-RTT] ------------> > "POST /buy-something" -----------> > > ClientHello [+0-RTT] ---------------> > "POST /buy-something" --------------> > > [Processes purchase] > <---------- ServerHello [accept 0-RTT] > (+ rest of handshake) > > > The attacker just discards the server's response and then the server > somehow forces the server to reboot (this is the hard part). It's probably easier than rebooting in a real-world attack: the server is vulnerable to state exhaustion attacks. For a primitive server, an attacker can generate enough client randoms to exhaust the state capabilities of the remote end. A more complicated server set-up might use a distributed store, sharded on the client random data; but even if they pay enough attention to use a salted hash of the client random data for the shard key, it only changes the attack effort by a linear factor. > It's important to understand that this is a generic issue, not an > issue with TLS in particular, so it's not like there's some other > 0-RTT model we can lift and put into TLS that would solve the problem. This probably opens a can of worms; but I think schemes that involve an assumption of roughly synchronized time between clients and servers can go quite a way to mitigating replay attacks too. Also, I know it's groan-worthy: but a safe variant of 0RTT is to first transit data opaquely, protected by a key that is only sent once the server is authenticated. This makes optimistic execution impossible on the server side, but it does preserve some of the benefits of network throughput and latency. > I would expect them to have relatively similar impacts on the wire, > namely applications would self-designate certain data as replay-safe > (e.g., HTTP GETs) and would send it in the first flight and then > either let the stack retransmit (option 2) or retransmit themselves > (option 3). This isn't that odd, since, as AGL observes, browsers > already routinely retry some HTTP requests that appear to fail even for > ordinary TLS (i.e., no HTTP response was received) so in those cases > they have already circumvented the anti-replay guarantees supplied by > TLS, but of course that's different from having TLS give up those > guarantees. I don't think it's a good idea to use browsers as the comparison here. TLS is used extensively outside of browsers and many of those applications do not retry like this, and rely on TLS as their anti-replay mechanism. -- Colm From nobody Sun Mar 22 22:39: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 208501A8850 for ; Sun, 22 Mar 2015 22:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r645qTnXimiH for ; Sun, 22 Mar 2015 22:39:48 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52CBF1A883E for ; Sun, 22 Mar 2015 22:39:48 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id E63FA2005D909; Sun, 22 Mar 2015 22:39:47 -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=FRZydb0nk+nKs2 vVzbnFJCRv4Bw=; b=PiMN8JC0CwbmmIUdRmsuAyIP2C5vMmtHU8GREPcPVmohHu YBrnpbCkr0plFqRJ8bsQ2HEI08+kxaHkbuxKAKV8SjH9jaWSj0vuBi6k9kxsEVTQ MkVsAVeDmZ8YhIlsZrd+frxJkn0efQgboID9+0R6XtlnYlqray54fQsHQszCA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id A601C2005D903; Sun, 22 Mar 2015 22:39:47 -0700 (PDT) Date: Mon, 23 Mar 2015 00:38:05 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150323053804.GK21267@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 05:39:49 -0000 On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: > A MORE REALISTIC ATTACK > During the interim meeting, DKG observed that you could produce the > same "I've forgotten my state" situation if you have a distributed > server. Say that the server operates in two loosely-synchronized > data centers. In that case, you can get the following situation > (shown without the attacker's intervention because of ASCII art > limitation > > Client Attacker Server1 Server 2 > > ClientHello [+0-RTT] --> > "POST /buy-something" -> > > ClientHello [+0-RTT] --> > "POST /buy-something" -> > > [Processes > purchase] > > > > ClientHello [+0-RTT] -----------------------> > "POST /buy-something" ----------------------> > > > <-------------------------------------- ServerHello [reject 0-RTT] > (+ rest of handshake) > > Finished ---------------------------------------------------------> > "Post /buy-something" --------------------------------------------> > [Processes purchase] If the client's first message had a nonce that the reject message (or subsequent handshake) could authenticate, then this attack goes away because the client will see that its message has been played, therefore the client should not play it again. Now the client application needs a way to recover other than repeating the request! It needs to go check the status of whatever it wanted done (a GET, here). Nico -- From nobody Mon Mar 23 01:00: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 8BC6C1A8967 for ; Mon, 23 Mar 2015 01:00:05 -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 E0EF9vjZD8P0 for ; Mon, 23 Mar 2015 01:00:02 -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 2E4C11A894C for ; Mon, 23 Mar 2015 01:00:02 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 61C0B9010C; Mon, 23 Mar 2015 09:59:59 +0200 (EET) Date: Mon, 23 Mar 2015 09:59:59 +0200 From: Ilari Liusvaara To: Andrey Jivsov Message-ID: <20150323075958.GA18876@LK-Perkele-VII> References: <550F6582.9040602@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <550F6582.9040602@brainhub.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:00:05 -0000 On Sun, Mar 22, 2015 at 05:59:46PM -0700, Andrey Jivsov wrote: > On 03/22/2015 02:49 PM, Eric Rescorla wrote: > > > >A MORE REALISTIC ATTACK > >During the interim meeting, DKG observed that you could produce the > >same "I've forgotten my state" situation if you have a distributed > >server. Say that the server operates in two loosely-synchronized > >data centers. In that case, you can get the following situation > >(shown without the attacker's intervention because of ASCII art > >limitation > > > > Client Attacker Server1 Server 2 > > > >ClientHello [+0-RTT] --> > >"POST /buy-something" -> > > > > ClientHello [+0-RTT] --> > > "POST /buy-something" -> > > [Processes > > purchase] > > > > > > > > ClientHello [+0-RTT] -----------------------> > > "POST /buy-something" ----------------------> > > > > > > <-------------------------------------- ServerHello [reject 0-RTT] > > (+ rest of handshake) > > > >Finished ---------------------------------------------------------> > >"Post /buy-something" --------------------------------------------> > > [Processes purchase] > > > >Again, the attacker will need to mess with the TCP channel, but their > >ability to do so is part of our basic threat model [RFC 3552]. > > > >It's important to understand that this is a generic issue, not an > >issue with TLS in particular, so it's not like there's some other > >0-RTT model we can lift and put into TLS that would solve the problem. > > The SessionID-like fallback is a problem for a "broadcast" of the single > "POST /buy-something" (via a replay of a captured message). Had the Server 2 > above rejected the ClientHello [+0-RTT] which was intended for Server 1 > (orbit1), there would be no problem. I think there would still be a problem: The transaction would get retried (there might be a dialog to shift the blame on user). I don't see a way of eliminating this "forking" attack without essentially eliminating 0-RTT (since client doesn't prove that its exchange key was correct until handshake is complete, and at that point you can start sending data anyway). > One way to solve this is to say that the server must *fail* 0-RTT, as > opposed to fallback to 1-RTT, if the "orbit" indicated in the ClientHello is > not that of this server. Won't help, and in general, you really don't want to fail TLS handshake unless you know the handshake with that client can never succeed (e.g. not supporting secure enough crypto). > The only requirement here is that the server always knows its orbit. Servers > must have different orbit IDs if they cannot handle simultaneous receipt of > identical "POST /buy-something". As noted above, you can use server that has different orbit as the second server in attack. Heck, in above diagram, the second server actually _rejects_ the 0RTT. You propose additionally rejecting the connection, which will get retried. Heck, I think the "forking" attack might actually work better in practice with servers with different orbit IDs than with the same orbit ID, since the latter could actually signal that replay is happening to the client. -Ilari From nobody Mon Mar 23 01:34: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 0AAC81A00BF for ; Mon, 23 Mar 2015 01:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk_rz3IPYx4P for ; Mon, 23 Mar 2015 01:34:41 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9B1A0084 for ; Mon, 23 Mar 2015 01:34:41 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 2C3D42005D005; Mon, 23 Mar 2015 01:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ADMiEs0JwCSni9 0bngz+fEt8Vuk=; b=Oy0nbUM4fxWQNmy6n8dqFocQUl0qnEte58+gMA9Yws7+8H 945xieiKnnCADOvRJaf2DV5rNGQajPpGvENfnZcJLFwapyWUFPEwbr2/3aPA85D7 aep/DfW4NMFzwYmWSInLpgwIbOFe/xZRZ30iDgbi92M6BY1idOpudsbw95ad4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id D09AB2005D004; Mon, 23 Mar 2015 01:34:40 -0700 (PDT) Date: Mon, 23 Mar 2015 03:33:09 -0500 From: Nico Williams To: Martin Thomson Message-ID: <20150323083308.GL21267@localhost> References: <550F6582.9040602@brainhub.org> 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] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:34:42 -0000 On Sun, Mar 22, 2015 at 08:35:34PM -0700, Martin Thomson wrote: > For HTTP, I think we can use that first flight for idempotent queries > quite easily and (at worst) the HTTP/2 connection preface. But TLS can't know what's happening at the application layer, so it had better be the case that the 0-RTT data is clearly denoted to the app as "had better be idempotent". I.e., this becomes an API issue. The name of the method would have to be indicative of danger. 0-RTT data is acted on at great risk. It's OK to use it for negotiation purposes where the integrity of the negotiation will eventually be confirmed (else the connection fails). For things like "launch missiles" it is a very bad idea to act on the command before authenticating it and determining that it's not a replay. When we don't know the nature of the data, we must assume it can't be sent without authentication and replay protection. Nico -- From nobody Mon Mar 23 01:48: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 3BAF61A0151 for ; Mon, 23 Mar 2015 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nANwMMXcT1l2 for ; Mon, 23 Mar 2015 01:48:47 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A1CAF1A0141 for ; Mon, 23 Mar 2015 01:48:47 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 69E7A1005D; Mon, 23 Mar 2015 01:48:47 -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=Xcfy5bRvXeuvo1 b00KPPWvNDl+Y=; b=C8q+RnYtBwkvQ6Z+12lKe9WXEVDVLIDBgUalEzzTwu5ru8 z8uCz5jeMzYYHUaFtbnsFIMWCHbEoh/2O629zEdOMzTNcX5m4FLL2NFut92/YJ5k 9ccO87DfFON5fYeVMUdpMqL88WKI6QSeB6a/+MTYGek/nHPrjpFHq+uXG28eM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 212BB10075; Mon, 23 Mar 2015 01:48:47 -0700 (PDT) Date: Mon, 23 Mar 2015 03:47:16 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150323084716.GM21267@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:48:48 -0000 On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: > Now consider what happens when the server reboots and loses its > state. You don't want to reject every client 0-RTT connection so > instead what you do is you ignore the client's initial data sent in > the first flight. Since the ServerHello provides a new Random value, > any data the client sends in subsequent flights has the usual > anti-replay protection. This is an optimization. If the server loses its replay state then it must cause every 0-RTT connection to become a 1-RTT connection. There's no question of "want". Nico -- From nobody Mon Mar 23 03:22:34 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 F2E121A702A for ; Mon, 23 Mar 2015 03:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_Z_Ipjq9d9j for ; Mon, 23 Mar 2015 03:22:29 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7EE1A7020 for ; Mon, 23 Mar 2015 03:22:29 -0700 (PDT) Received: from pc1.fritz.box (x4d0c2a73.dyn.telefonica.de [::ffff:77.12.42.115]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 23 Mar 2015 11:22:25 +0100 id 0000000000000061.00000000550FE961.00006789 Date: Mon, 23 Mar 2015 11:22:32 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20150323112232.5964828b@pc1.fritz.box> In-Reply-To: References: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26505-1427106145-0001-2" Archived-At: Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 10:22:32 -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-26505-1427106145-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm glad this comes up. I wanted to push for it again, but didn't find the time lately. On Sun, 22 Mar 2015 15:09:31 -0700 Eric Rescorla wrote: > 2. Adopt PSS as the only signature format for non-certificate > signatures (but require acceptance of PKCS#1 1.5 for > certificates) +1 I think this totally makes sense. I think we should see Signatures for PKI separately that for TLS (i.e. signing certificates versus signing handshakes). Pushing PKI to support PSS can be done separately, but it is probably much more difficult due to backwards compatibility issues. But it doesn't need to happen inside the TLS 1.3 specification. (and the tech / spec for doing so is already available) I have some ideas how this should be done though. The PSS spec currently allows a wide range of flexibility. It is for example in theory possible to use two different hash functions within the same signature (there's a hash and an mgf that's based on a hash). I think it would make implementations much easier if the spec defined a pre-defined set of sane parameters and doesn't allow the full flexibility of PSS. Also - which seems obvious - the use of insecure parameters (sha1, I'm looking at you) should be forbidden completely. (and if this helps: I wrote my diploma thesis on pss a few years ago and the nss implementation was originally written by me. I think I have a pretty good idea about the issues surrounding PSS, if anyone feels they have any questions I'm glad to try to answer them.) --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-26505-1427106145-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVD+loAAoJEKWIAHK7tR5CAhkP/3AcsMvAsOU/qYI368tXhxkX RQ4h3jQwM9Fa8703fHC7cgksPzYqGXUQaFINfVy4AepzSG28AZFzgAgTyuPgNdIe 6MvCKp+gHhJUELcl7r2bQ0BdpDK+PiIv3sxU5XwaBwM5ErgfvtgBsNkKkCMbfCGX YuXsCki4MrzNbdXnU4jPKGYAAMTk+EJ43cv+e6d/I5XX2LyQz4hf6PHA0rzGeaxI cMhf+u+7o5aPapgRpifTqm0XlY+5161NHZFAaH/ZHwDFsR5mz8Vdj53TAzegzaMK XtGH5ILjzk2zaqc4G/pDfpyf3ph7eyt0Q9mHKGjzPAoXj6eMNY6RRGDrKXxlp8kg J0hUlYQ7JHtMl0aFIMSYLRJoCyklQtuTr/jjl9HmcqYfsPov77X+BiAgZyHcyvz0 2c/iYsfA3ZEapPe9UWdjUddGj5vGzFMpGnjb7MDjHH9aS6EXKfycWGg5lol5rUCX qd19Cl40fD8/Ia+/pG5nT+yfqlgri3T2zKfFoQri5ZNQnOIr0Rnk59SEgIN2XgIU sQW65jAKuprYz6X35vnnJWKWNA8PYWQVM5g5YMKQNxZ6lctqlarpd4Ptj9apj3k3 P+t3cihRaufNeWs0n6+r9EwxcQQCBDkDEoQXXdNIloGh4o8waO/j3wJtwzqlWpeg 0m26W/XxuztK8hBNdNuo =oi4J -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-26505-1427106145-0001-2-- From nobody Mon Mar 23 03: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 363501A870B for ; Mon, 23 Mar 2015 03:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM6iWR0q61RY for ; Mon, 23 Mar 2015 03:47:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 E2CEC1A8737 for ; Mon, 23 Mar 2015 03:47:24 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2NAlOcQ013518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Mar 2015 06:47:24 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2NAlMh0028701 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 06:47:23 -0400 Message-ID: <1427107642.19595.19.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Mon, 23 Mar 2015 11:47:22 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 10:47:29 -0000 On Sun, 2015-03-22 at 15:09 -0700, Eric Rescorla wrote: > During the interim we discussed discussion about adopting PSS for > RSA signatures in TLS 1.3. > Clearly, we will not be able to just adopt PSS because certificates > will continue to be signed with PKCS#1 1.5. However, we could adopt > PSS for signatures outside of the certificate context. Roughly > speaking, we have three options: > 1. Do not adopt PSS. > 2. Adopt PSS as the only signature format for non-certificate > signatures (but require acceptance of PKCS#1 1.5 for > certificates) > 3. Negotiate the use of PSS versus PKCS#1 1.5 Does (3) imply the usage of signatureAlgorithms to negotiate? I guess that's the more natural approach, as a client could support both RSA and PSS_RSA at the same time. However, that is complicated by the fact that new ciphersuites are needed to use RSA_PSS on the end certificates. That's because the ciphersuite name contains the type of the certificate of the peer. I have argued about abolishing that [0]. Overall, I'm not sure how useful is a connection with PSS signature in the handshake, but with a PKCS #1 1.5 signature in the certificate. However, that looks like the only path to deprecate PKCS #1 1.5 and move to PSS (if the WG thinks it's worth it). regards, Nikos [0]. https://github.com/tlswg/tls13-spec/issues/98 From nobody Mon Mar 23 06:12: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 D33311A89FC for ; Mon, 23 Mar 2015 06:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Pt9MmewjHL5 for ; Mon, 23 Mar 2015 06:12:26 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 E55551A89C7 for ; Mon, 23 Mar 2015 06:12:25 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so122441853obc.0 for ; Mon, 23 Mar 2015 06:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jD9xdzfLq5lzZgjTVf6xL5sI1dSOObtaW0Ca7MKz75I=; b=CGVMqw10QvK51epIQRq/XW4+uhsNii7d5uTFaGUl77krNk29UiJTI3j6+V0j2Ib0Dy v2WS8UjpSUNmQYC3X5GQ8GZlbXZ3X2MbSUwcRpN7gGVP01jxOsqzMtyESUOwfCb/FEEq joGjFWrsa8pJSPZO+QY0tjjhhtgAv1XTVOicK80bofdqbZWjOl42Nqu10yhwKiMpiU8P i+z3nFFhntHgFSVklJjJd1HC8zBoIrn7/d3AOh+j+YujJjRL/VAJ8e/8E+XeXbIVwfGO o/cUr/0MyAXzkIDvqB6ZHpIIv/UmFt7diL926JgRsGj1cuq2WJfNMJBgh8U9h/ZcAaVM nRXQ== MIME-Version: 1.0 X-Received: by 10.202.64.9 with SMTP id n9mr70346552oia.20.1427116345507; Mon, 23 Mar 2015 06:12:25 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 06:12:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 06:12:25 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:12:27 -0000 On 22 March 2015 at 22:21, Colm MacC=C3=A1rthaigh wrote= : > It's probably easier than rebooting in a real-world attack: the server > is vulnerable to state exhaustion attacks. For a primitive server, an > attacker can generate enough client randoms to exhaust the state > capabilities of the remote end. A more complicated server set-up might > use a distributed store, sharded on the client random data; but even > if they pay enough attention to use a salted hash of the client random > data for the shard key, it only changes the attack effort by a linear > factor. Well, Adam described at the interim why this isn't a concern: as the "strike register" takes a higher density of entries, the window of time over which it applies can be narrowed to limit the potential for state exhaustion. That simply increases the likelihood of a rejection, not the attack. From nobody Mon Mar 23 06:12: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 0C0601A8A01 for ; Mon, 23 Mar 2015 06:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8csuqXoW_ngv for ; Mon, 23 Mar 2015 06:12:42 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.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 807AE1A89F6 for ; Mon, 23 Mar 2015 06:12:42 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so145498531wgb.0 for ; Mon, 23 Mar 2015 06:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1B+FPY5EJFhG5KBo2FVQOAZQJp6LjPoJkcD1g3ndDZo=; b=hdBzu0CPKZaSgD5FcDbFEJfBpH3gfK1R45j+whBg7M7vJ+2w0LI1zZlVz5I2nm8nCE WjbwhTVDxP7e5rHG6R/PYPxTltMrqJV5Oez+1NY2XUZvqAOFIq9houkb/ZAaKIvaMBRI AjYL/rEe1YOv09z/zOYpU0OUDoo0vF49MKmKFa0QV1PmE3VRGDNlnYJPoM9d3GI7PKNK 5ZD1FocsRovbyeeeaoZqgMNxnYHioJ3khbffihlRgG1KCukjWBdujsftVs5tqHxgAlje PRDMPoX46kBPqPjApRThKitlGSWprFkNmUQY8HS2uDEnty1OGzO/RHIWalDjhRR9YYQ/ LW3w== X-Gm-Message-State: ALoCoQl3LGDRpn54lRMGZormlgPZdwQL549umraez6tSVvBDqtjhiyBHmzYmAyd+U5so5OiWVz+w X-Received: by 10.180.91.70 with SMTP id cc6mr18844018wib.78.1427116361133; Mon, 23 Mar 2015 06:12:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 06:11:59 -0700 (PDT) In-Reply-To: <20150323084716.GM21267@localhost> References: <20150323084716.GM21267@localhost> From: Eric Rescorla Date: Mon, 23 Mar 2015 08:11:59 -0500 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=f46d0438edd7c246f90511f46b6f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:12:45 -0000 --f46d0438edd7c246f90511f46b6f Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 3:47 AM, Nico Williams wrote: > On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote: > > Now consider what happens when the server reboots and loses its > > state. You don't want to reject every client 0-RTT connection so > > instead what you do is you ignore the client's initial data sent in > > the first flight. Since the ServerHello provides a new Random value, > > any data the client sends in subsequent flights has the usual > > anti-replay protection. > > This is an optimization. > > If the server loses its replay state then it must cause every 0-RTT > connection to become a 1-RTT connection. There's no question of "want". > Maybe I wasn't clear. When I said "reject" I meant "hard-fail" rather than make it 1-RTT. -Ekr Nico > -- > --f46d0438edd7c246f90511f46b6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 23, 2015 at 3:47 AM, Nico Williams <nico@cryptonector.= com> wrote:
On Sun, Mar 22, 2015 at 02:49:28PM -0700, Eric Rescorla wrote:
> Now consider what happens when the server rebo= ots and loses its
> state. You don't want to reject every client 0-RTT connection so > instead what you do is you ignore the client's initial data sent i= n
> the first flight. Since the ServerHello provides a new Random value, > any data the client sends in subsequent flights has the usual
> anti-replay protection.

This is an optimization.

If the server loses its replay state then it must cause every 0-RTT
connection to become a 1-RTT connection.=C2=A0 There's no question of &= quot;want".
<= /span>

Maybe I wasn't clear. When I sai= d "reject" I meant "hard-fail" rather than
ma= ke it 1-RTT.

-Ekr

Nico
--

--f46d0438edd7c246f90511f46b6f-- From nobody Mon Mar 23 06:14: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 A13721A8A01 for ; Mon, 23 Mar 2015 06:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JFHjInHquWh for ; Mon, 23 Mar 2015 06:13:58 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 C91A41A8A0F for ; Mon, 23 Mar 2015 06:13:57 -0700 (PDT) Received: by wixw10 with SMTP id w10so62184701wix.0 for ; Mon, 23 Mar 2015 06:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9UYXWP3qSz5zM6mNTF9JImALjbl+CasuAi/gmolreo4=; b=b74jRdirI5MVCybobKpP2k1eDgi7RIdet0SpAJnPdWn/As0Rhn9GLXQEqSXpK8i/4y SpPbwUl8+GO7Fpl17KaDUa6kClH0bjLr08mmPucAyWRXbhcVcUJxXeGlx6NjsaGBfai8 Yqb2x6+htv4TrZ/4NF3+MRx1+thquyrLf0R8Tet2G2Oat74yR66TaGGMF1cN+pdv179a 8dD5XFk+uLUMzhssNLKlU3kvef7A44BYHTkOrmitktqTzyHui2I4+iCLfu9kgNUQOfTB 8ynPi+rUwUAyYxcBKplhcyR0vDXR5af6LQdv3JQ5a67eC6K2wG3Y464TDeeihAeb+iP2 z82Q== X-Gm-Message-State: ALoCoQk+EUF7Y2n6zuO15OdCHhLGcGSrPLDU8YjZT4xV+eugAvyyFoBCSNpIYTqz6n3bSm6aPSs+ X-Received: by 10.180.84.99 with SMTP id x3mr938933wiy.35.1427116436554; Mon, 23 Mar 2015 06:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 06:13:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 23 Mar 2015 08:13:16 -0500 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=f46d044403a84117e30511f47024 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:13:59 -0000 --f46d044403a84117e30511f47024 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen wrote: > On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla wrote: > > During the interim we discussed discussion about adopting PSS for > > RSA signatures in TLS 1.3. > > > > Clearly, we will not be able to just adopt PSS because certificates > > will continue to be signed with PKCS#1 1.5. > > I would like to see TLS 1.3 allow certificates signed using PSS (RFC > 4055 and 3447) and provide a way to signal the server that such > certificates are supported. I would think that in option #2, we would also require support for this. > Currently there is no way to use PSS > signed certificates with TLS at all, which is a problem. I agree with > the move to EC* as the preferred algorithm, but it seems like > enhancing non-EC signatures makes sense for the same reason as fixing > FFDHE. > > Possibly the SignatureAlgorithm extension could carry both (1) rsa and > (tbd) rsa-pss? > This seems like the obvious design if we opt for the negotiation route. Best, -Ekr Thanks, > Peter > --f46d044403a84117e30511f47024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen <pzbowen@gmail.com&g= t; wrote:
On Sun,= Mar 22, 2015 at 3:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> During the interim we discussed discussion about adopting PSS for
> RSA signatures in TLS 1.3.
>
> Clearly, we will not be able to just adopt PSS because certificates > will continue to be signed with PKCS#1 1.5.

I would like to see TLS 1.3 allow certificates signed using PSS (RFC=
4055 and 3447) and provide a way to signal the server that such
certificates are supported.=C2=A0

I would t= hink that in option #2, we would also require support for this.
<= br>
=C2=A0
Currently there i= s no way to use PSS
signed certificates with TLS at all, which is a problem.=C2=A0 I agree with=
the move to EC* as the preferred algorithm, but it seems like
enhancing non-EC signatures makes sense for the same reason as fixing
FFDHE.

Possibly the SignatureAlgorithm extension could carry both (1) rsa and
(tbd) rsa-pss?

This seems like the obvi= ous design if we opt for the negotiation route.

Be= st,
-Ekr

Thanks,
Peter

--f46d044403a84117e30511f47024-- From nobody Mon Mar 23 06:37: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 24BC51A8A5E for ; Mon, 23 Mar 2015 06:37: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 Qyi-tIOY8cjJ for ; Mon, 23 Mar 2015 06:37:24 -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 C69E31A89ED for ; Mon, 23 Mar 2015 06:37:23 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so47680500wib.0 for ; Mon, 23 Mar 2015 06:37: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:from:date:message-id:subject:to :content-type; bh=MXI7QsM01YR6hRDsD5n2wFi8QkE9I8DxQXTmvEhZdQ4=; b=HPU4/mVXG8vDjnBMDW9fOlxfdUD/+EnL9JWuqAUzai20en579T+2ylIYUJXEsb5lBc sufupreBhmOO5tCzuBguCtXo79EFq98wjqii2CRlP6p0avuthflfq9TLJyLyX8CSzY2J 3d8PlzHbKoxdFs6DCZBUJPUzv0BI7SSRyteXSJrEvK2Bhfkvd0q6Eez6JO/zuYGregH4 02CyDWinANrF0K81GLJbtmW0oV8Qqn3XjmLbJdUoSnz9bl+gxtyteH4ViI1YMvByndVy CS+rUe/vCBUP4mP95+pg/RNwIU73a5pTh5X/1vjSu1eC3nxKYtgXx7EnNxUWgUFEKgH1 CLHA== X-Gm-Message-State: ALoCoQknH1VYeANMaCpbRgdMqo/RvODrQVEaSlCFQv0I61bep4oXFYnWP+AZ4fhmAQZG0SpBHAhC X-Received: by 10.180.218.200 with SMTP id pi8mr19628211wic.71.1427117842039; Mon, 23 Mar 2015 06:37:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 06:36:41 -0700 (PDT) From: Eric Rescorla Date: Mon, 23 Mar 2015 08:36:41 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1135e462071cf30511f4c471 Archived-At: Subject: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:37:26 -0000 --001a1135e462071cf30511f4c471 Content-Type: text/plain; charset=UTF-8 Folks, At the interim discussed transitioning to a DH-based handshake (rather than a signature-based one) like that proposed by Hugo Krawczyk and Hoeteck Wee. The major rationale for this change is that any 0-RTT mode is inherently DH-based and so if we make that our basic mode, then we can simplify the protocol logic and key derivation model. This model also allows us to pull in PSK modes under the same basic structure. However, in the near term it's clear that servers will continue to have RSA and ECDSA certificates rather than (EC)DH certificates, so we need some way to reuse those credentials. The two major options are: - An offline signature of the server's DH share. - An online signature of the server's DH share that's tied to the handshake in some way. The WG sentiment was generally favorable to exploring this avenue but there was also airly strong WG sentiment that we didn't presently want to do an offline signatures. This leaves with a model in which the client initially learns the server's semi-static DH share through an online-signed 1-RTT handshake but then can cache it for use with future connections. As an outcome of the interim, I was asked to write up an initial draft of what this would all look like and post it to the list. You can find such a draft at: Git branch: https://github.com/ekr/tls13-spec/tree/WIP_dh_based Text file: https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt HTML diff: https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.html Please note that this is a very rough draft and no doubt contains a number of major errors (and certainly has seen no security review). Please point these out to me if you find them, especially if they impede understanding. Assuming that people are happy with this general direction, I will clean it up and turn it into a PR. A number of other notes: - There is generally not support here for 0-RTT. I am developing that on a separate branch (based on that branch) and will be cleaning it up and posting it in the next few days. You will, however, probably notice some hooks for 0-RTT that don't do anything yet. - In Section 7.3.7 there is a discussion about using the same DH share for the semi-static and epehemeral server keys. This is an important part of getting performance comparable between the 1-RTT mode and the current 1-RTT mode. We discussed this extensively at the interim and I believe that Hugo and Hoeteck consider this safe, but any information to the contrary would be very useful at this point. - The key schedule in Section 8.1 is probably going to change, but that shouldn't impede understanding. - During the interim we also discussed moving to HKDF. This branch includes a draft version of that change as well as using separate HKDF invocations to generate each traffic key. As usual comments welcome; I look forward to discussing this in Dallas. -Ekr --001a1135e462071cf30511f4c471 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

At the interim discus= sed transitioning to a DH-based handshake (rather
than a signatur= e-based one) like that proposed by Hugo Krawczyk and
Hoeteck Wee.= The major rationale for this change is that any 0-RTT
mode is in= herently DH-based and so if we make that our basic mode,
then we = can simplify the protocol logic and key derivation model. This
mo= del also allows us to pull in PSK modes under the same basic
stru= cture.

However, in the near term it's clear th= at servers will continue to
have RSA and ECDSA certificates rathe= r than (EC)DH certificates, so
we need some way to reuse those cr= edentials. The two major options are:

- An offline= signature of the server's DH share.
- An online signature of= the server's DH share that's tied to the
=C2=A0 handshak= e in some way.

The WG sentiment was generally favo= rable to exploring this avenue but
there was also airly strong WG= sentiment that we didn't presently want
to do an offline sig= natures. This leaves with a model in which the
client initially l= earns the server's semi-static DH share through
an online-sig= ned 1-RTT handshake but then can cache it for use with
future con= nections.

As an outcome of the interim, I was aske= d to write up an initial draft
of what this would all look like a= nd post it to the list. You can find
such a draft at:
<= br>
Git branch:

Text file:

HTML diff:


Please note that this is a very rough draft and no doubt c= ontains
a number of major errors (and certainly has seen no secur= ity review).
Please point these out to me if you find them, espec= ially if they
impede understanding. Assuming that people are happ= y with this
general direction, I will clean it up and turn it int= o a PR.

A number of other notes:

- There is generally not support here for 0-RTT. I am developing th= at
=C2=A0 on a separate branch (based on that branch) and will be= cleaning it
=C2=A0 up and posting it in the next few days. You w= ill, however, probably
=C2=A0 notice some hooks for 0-RTT that do= n't do anything yet.

- In Section 7.3.7 there = is a discussion about using the same DH share
=C2=A0 for the semi= -static and epehemeral server keys. This is an important
=C2=A0 p= art of getting performance comparable between the 1-RTT mode and
= =C2=A0 the current 1-RTT mode. We discussed this extensively at the interim=
=C2=A0 and I believe that Hugo and Hoeteck consider this safe, b= ut any
=C2=A0 information to the contrary would be very useful at= this point.

- The key schedule in Section 8.1 is = probably going to change, but
=C2=A0 that shouldn't impede un= derstanding.

- During the interim we also discusse= d moving to HKDF. This branch
=C2=A0 includes a draft version of = that change as well as using separate
=C2=A0 HKDF invocations to = generate each traffic key.

As usual comments welco= me; I look forward to discussing this in Dallas.

-= Ekr



--001a1135e462071cf30511f4c471-- From nobody Mon Mar 23 07:05: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 B4E7F1A8ABF for ; Mon, 23 Mar 2015 07:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxBizhU85I_q for ; Mon, 23 Mar 2015 07:05:02 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 C2E281A8AB3 for ; Mon, 23 Mar 2015 07:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427119499; l=1909; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=gogSl4ADhreK6NIGxr+btJ4qwFMUObz36zYnY4eyqUA=; b=yH1R/DsYicFdE+rRF0eF4YmVq2F3exLAPBxrn7IXLn2dNSJq67TTm2yg5daQtNriI95 wouI5Fr6kLvgYoGiRQ/jLljZxJ3d9OjJApfYj5AEJ4y0jrgsEgHMRSdQi5Lsy3ait4p5I GK/w/K6tNt+HAP8JEaA9H8I9w3HXIbiodkg= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5UXpfUT3myN2hlbG+UDaVCoSA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id R00452r2NE4w5E1 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for ; Mon, 23 Mar 2015 15:04:58 +0100 (CET) Message-ID: <55101D8B.7050909@zinks.de> Date: Mon, 23 Mar 2015 15:04:59 +0100 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:05:03 -0000 On 22.03.2015 22:49, Eric Rescorla wrote: > > There are a number of basic ways to address this issue, but I think > the main plausible[0] ones are: > > 1. Keep the server state globally consistent and also temporally > consistent so that replays can always be detected. > > 2. Remove the TLS anti-replay guarantee for the data sent in the first > flight and tell applications to only send data there that can > tolerate being replayed. > The server probably can't trust the clients choice. An API on the server side is needed as well to check that data received on the first flight is acceptable. > 3. Remove the TLS reliable delivery guarantee for the data sent in > the first flight, so that the stack doesn't automatically replay it. > What does happen when the stack can't deliver it? Is the user asked to replay? Does the software hang? > The first of these options (global state) is possible, but only in > some limited circumstances, namely very sophisticated operators and/or > situations where there's really only one server which has good state > management. An example of the latter is WebRTC, where the server can > have a different anti-replay context for each connection. > > The other two options clearly require a separate API to handle this > special first-flight data and would require applications to handle it > separately. So, for instance, in option 2, you would have something > like: > Does this mean a standard API will be specified. A separate API would mean that 0RTT will not be available in many cases because the replay / delivery guarantee requirements are unknown in some layers. The solutions 2 and 3 seem to give the problem to the application, e.g. either the application doesn't (need to) care or need to implement it. So solution 1 seems the way to go although for non single server solutions this may be complicated. Roland From nobody Mon Mar 23 07:12: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 954AF1A8A8F for ; Mon, 23 Mar 2015 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 TEiCnSJVPBCu for ; Mon, 23 Mar 2015 07:12:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 778411A8AB2 for ; Mon, 23 Mar 2015 07:12:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 66264288E7; Mon, 23 Mar 2015 14:12:39 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4B66228918; Mon, 23 Mar 2015 14:12:39 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 448AE202F; Mon, 23 Mar 2015 14:12:39 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 23 Mar 2015 10:12:06 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 23 Mar 2015 10:12:06 -0400 From: "Salz, Rich" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] PSS for TLS 1.3 Thread-Index: AQHQZOz9T2F3OpDQXkC0e6kcgiq0Zp0qH78A///9BrA= Date: Mon, 23 Mar 2015 14:12:05 +0000 Message-ID: References: <20150323112232.5964828b@pc1.fritz.box> In-Reply-To: <20150323112232.5964828b@pc1.fritz.box> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.113.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:12:42 -0000 DQo+IEkgdGhpbmsgdGhpcyB0b3RhbGx5IG1ha2VzIHNlbnNlLiBJIHRoaW5rIHdlIHNob3VsZCBz ZWUgU2lnbmF0dXJlcyBmb3IgUEtJDQo+IHNlcGFyYXRlbHkgdGhhdCBmb3IgVExTIChpLmUuIHNp Z25pbmcgY2VydGlmaWNhdGVzIHZlcnN1cyBzaWduaW5nIGhhbmRzaGFrZXMpLg0KPiBQdXNoaW5n IFBLSSB0byBzdXBwb3J0IFBTUyBjYW4gYmUgZG9uZSBzZXBhcmF0ZWx5LCBidXQgaXQgaXMgcHJv YmFibHkgbXVjaA0KPiBtb3JlIGRpZmZpY3VsdCBkdWUgdG8gYmFja3dhcmRzIGNvbXBhdGliaWxp dHkgaXNzdWVzLg0KPiBCdXQgaXQgZG9lc24ndCBuZWVkIHRvIGhhcHBlbiBpbnNpZGUgdGhlIFRM UyAxLjMgc3BlY2lmaWNhdGlvbi4NCj4gKGFuZCB0aGUgdGVjaCAvIHNwZWMgZm9yIGRvaW5nIHNv IGlzIGFscmVhZHkgYXZhaWxhYmxlKQ0KDQorMQ0KDQo= From nobody Mon Mar 23 07:12: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 1B28E1A8AC3 for ; Mon, 23 Mar 2015 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnUpS5SWkuXM for ; Mon, 23 Mar 2015 07:12:50 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 D61C31A8ABC for ; Mon, 23 Mar 2015 07:12:49 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so103532297obc.2 for ; Mon, 23 Mar 2015 07:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HBrAdPfRSAlanQJvWFpTBDMI2CvkaCU+9FZKIfeptCU=; b=SolYa2j50+Muq91qM1O+Zg39/lYZUvvdBz5F+o8H0EXUi7tFpvmY8F7o1PxjrIqd0P i6c/2hKNwcmEBu8jJ7dXBWzvAFApqg0VJmELPZ+jvynBO/x8qCFZfs8tD3v2yqcjy7kJ v2VLOrA5ZRlpI+Zsmyz1bu/sHQgQcOaoJefO2Ia80F7QLRp9UbDpiVnFgzaESeaQRSTo IRQtNyZ66c60g3fHQfMju5VDgybau1SQrJbD3r3Uc2m9vXjx5aZCnLte7YJtjZM89iAQ 5k2zvsYLyBQChSKMECY530HTeKJysvtOKu0y7CBL8Va78hPkj6NBEkASAm4LFTLDK6Tt ZyZw== MIME-Version: 1.0 X-Received: by 10.202.106.12 with SMTP id f12mr16706365oic.39.1427119969446; Mon, 23 Mar 2015 07:12:49 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 07:12:49 -0700 (PDT) In-Reply-To: <55101D8B.7050909@zinks.de> References: <55101D8B.7050909@zinks.de> Date: Mon, 23 Mar 2015 07:12:49 -0700 Message-ID: From: Martin Thomson To: Roland Zink Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:12:51 -0000 On 23 March 2015 at 07:04, Roland Zink wrote: > Does this mean a standard API will be specified. Probably more in the form of a generic recommendation, or a requirement on what the API needs to achieve. From nobody Mon Mar 23 07:21: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 B35A61A8AB5 for ; Mon, 23 Mar 2015 07:20: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 BQS2PKJ8YXZz for ; Mon, 23 Mar 2015 07:20:53 -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 E0C251A8ADA for ; Mon, 23 Mar 2015 07:20:40 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so64198391wib.1 for ; Mon, 23 Mar 2015 07:20:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=BgHhLjPzc/tqNMVOOdZoHqrbR+mzcaeXFdHicNglHNY=; b=BGPIKYms4zit9lcuTMDdhk5Tivg02Yj1EG5Z+8vwIXEGHD+pLSpHapkxLL1d/uKF8f C/6JwR1Ath9Bk+BwQivdhMUWbmqiEU0Ag/yTc2FUKJXOEdozmzQZG4/xmClNbLUZe64V i44s5jYmbhmQFeV3U38cwUoJrkyI0X3FsLVASxUL6o/8Co8g8fJreEEme9Ch9XX3+uSc B/kh1d8RlYs/TVslVdA1Yj3hchHQoju2rv1IqpgkjO/WwwHU5rJtajaBXZUk6Wjo8npP 9PDUHp1yB6jfHx33xw4Ovu0kbY5YesJn6D+eaQOvr/J3sLlmiyK1LlYmQ0pHOLtswoGx yDGw== X-Gm-Message-State: ALoCoQkTElak8bwqZalP/1/FSkrj802vaF+QpQLoiqxKbhTvJDZWwF33/s9LHjqzawSLSW5iBKI9 X-Received: by 10.180.202.228 with SMTP id kl4mr19348972wic.66.1427120439593; Mon, 23 Mar 2015 07:20:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 07:19:59 -0700 (PDT) From: Eric Rescorla Date: Mon, 23 Mar 2015 09:19:59 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0102e128daa36f0511f55e87 Archived-At: Subject: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:20:54 -0000 --089e0102e128daa36f0511f55e87 Content-Type: text/plain; charset=UTF-8 As I mentioned in a previous message [0] during the interim we discussed moving from the TLS PRF to HKDF [RFC5869]. The general sentiment was: - Move to HKDF - Specify both SHA-256 and SHA-384 (the latter being required for Suite B) This is also the time when we would want to look at adjusting the key expansion to separate keys and IVs (assuming we still have IVs). Please use this thread to discuss this topic. -Ekr [0] https://www.ietf.org/mail-archive/web/tls/current/msg15621.html --089e0102e128daa36f0511f55e87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I mentioned in a previous message [0] during the i= nterim we discussed
moving from the TLS PRF to HKDF [RFC5869].

The general sentiment was:

= - Move to HKDF
- Specify both SHA-256 and SHA-384 (the latter bei= ng required for
=C2=A0 Suite B)

This is = also the time when we would want to look at adjusting
the key exp= ansion to separate keys and IVs (assuming we still
have IVs).

Please use this thread to discuss this topic.

-Ekr



=



--089e0102e128daa36f0511f55e87-- From nobody Mon Mar 23 07:26: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 74C6F1A8AD0 for ; Mon, 23 Mar 2015 07:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20atyr6QfgpX for ; Mon, 23 Mar 2015 07:26:20 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (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 477A61A8AC6 for ; Mon, 23 Mar 2015 07:26:20 -0700 (PDT) Received: by oifl3 with SMTP id l3so111723893oif.0 for ; Mon, 23 Mar 2015 07:26:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X+pHfGB+w6Bxxnnfkwsf1fHbCsP7xsA+4uyqIK82sT0=; b=EqD/sQqyl/m3CwOnQ+/VUMclsLsNVMD/HZrqp5ExEWziNk0x6LfXLuHUSZIzBZD/Cf uOEfCOkZ4s7YbJ2ZIWDOLpLlhmj71+v4GFkG2CHJjOxpCwp66F4dXKmMBEvyhFPSpGgj eAxh4o+OduzUHrgqLoDWPryB/gH2otIUCHxJ0AxhybwsqSw//z2TSrGZ9Fol1s8f75hG i0XkzcNzISgA4kQ+gA4QVEJ2cFVerkN7GRgayWFP+PxnCPT/Q7suvC7cW2jV0LqSOke1 7zqOHmVP12QgDt9Ir+vDWSWwwNHEW9fcSdYxfrdnn8ug9S3VV8rVWxeNiCiZCzj5dUgA 8bfw== X-Gm-Message-State: ALoCoQmidInFtsU6YHngAXKW/IfCFWiI9maiy8+n/rNUB3PR0ovjwnf2DupXWrGzrrHonyYG6t7L MIME-Version: 1.0 X-Received: by 10.60.112.65 with SMTP id io1mr17581970oeb.66.1427120779610; Mon, 23 Mar 2015 07:26:19 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Mon, 23 Mar 2015 07:26:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 07:26:19 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:26:21 -0000 On Mon, Mar 23, 2015 at 6:12 AM, Martin Thomson wrote: > Well, Adam described at the interim why this isn't a concern: as the > "strike register" takes a higher density of entries, the window of > time over which it applies can be narrowed to limit the potential for > state exhaustion. That simply increases the likelihood of a > rejection, not the attack. I haven't been able to get my head around this. Doesn't that mean that an attacker can disable 0RTT for third parties at will? it also means that the session itself must be invalidated on a shorter duration, or else we could just collect 0RTT data from before the time window and replay those. -- Colm From nobody Mon Mar 23 07:40: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 CFC561A8AFA for ; Mon, 23 Mar 2015 07:40:56 -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 63NYu-Djej5z for ; Mon, 23 Mar 2015 07:40:54 -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 2A1891A8AF8 for ; Mon, 23 Mar 2015 07:40:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 95324283011; Mon, 23 Mar 2015 14:40:52 +0000 (UTC) Date: Mon, 23 Mar 2015 14:40:52 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150323144052.GF9387@mournblade.imrryr.org> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150323083308.GL21267@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay 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, 23 Mar 2015 14:40:57 -0000 On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote: > On Sun, Mar 22, 2015 at 08:35:34PM -0700, Martin Thomson wrote: > > For HTTP, I think we can use that first flight for idempotent queries > > quite easily and (at worst) the HTTP/2 connection preface. > > But TLS can't know what's happening at the application layer, so it had > better be the case that the 0-RTT data is clearly denoted to the app as > "had better be idempotent". I.e., this becomes an API issue. The name > of the method would have to be indicative of danger. > > 0-RTT data is acted on at great risk. It's OK to use it for negotiation > purposes where the integrity of the negotiation will eventually be > confirmed (else the connection fails). For things like "launch > missiles" it is a very bad idea to act on the command before > authenticating it and determining that it's not a replay. When we don't > know the nature of the data, we must assume it can't be sent without > authentication and replay protection. Therefore, 0-RTT data must: * Require a non-default code path to send, (explicit request by the client to send a 0-RTT message). * Require a non-default code path to *receive*. That is, the server must be configured to allow receipt of such data, and must explicitly request to read it. If the server issues a read for protected data, while expedited 0-RTT data is pending, the connection should be aborted by the server's TLS stack. Once the server exhausts all the expedited data, it can switch to reading protected data. * The server's TLS stack must not coallesce 0-RTT expedited (idempotent) data with subsequent protected data. This allows servers that receive idempotent queries to avoid the 1-RTT latency. Something akin to DNS lookups over TLS, (I am not specifically advocating TLS as a transport for DNS in this message). Servers reading expedited 0-RTT data will be aware that they are doing that, and can/should reject operations that are unsafe in that context. This avoids all futile attempts to add stateful replay protection to a stateless phase protocol. I expect such attempts are doomed to failure. -- Viktor. From nobody Mon Mar 23 07: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 BBC801A8AE4 for ; Mon, 23 Mar 2015 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vXDJHeFkUKW for ; Mon, 23 Mar 2015 07:42:51 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 1E3AA1A8ADC for ; Mon, 23 Mar 2015 07:42:51 -0700 (PDT) Received: by oigv203 with SMTP id v203so142179047oig.3 for ; Mon, 23 Mar 2015 07:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5X9WDvLcszd6LQO27O916N2EyA54pI8rQrxrOJPiCUA=; b=MykUSKw1i2SJQFtO3q9QmZFNI42ynuXURxbnP9IqRc/0QhxUGcplJuMAd1a91BrBNB sEvT3dDHCj9J2txQYpr9HcBWhTxb1TO31TxuUiwKcAHGr5QZK0qMVD72otzOLZ5u+6Co IcFCG9RJwc3zNHGIM8lsyYOrEz8boL0+N/lrBpEA7sOA6uzmY94Vbq35vkP8ivRk0fxk K0TRLE7oZR56dz5bqmmzHoheykIolPuCtWfsX62SLclzdSgMLVtT7R0y9MUSTFXeph3s Wx8xNceuZJaZFuboZ2BAF7o/dv3/RMLBnUyOiaVCb5aDsRxu1XUAQuU+TH7k4duY2eoG LbOA== MIME-Version: 1.0 X-Received: by 10.182.39.195 with SMTP id r3mr34606862obk.44.1427121770639; Mon, 23 Mar 2015 07:42:50 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 07:42:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 07:42:50 -0700 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:42:52 -0000 On 23 March 2015 at 07:26, Colm MacC=C3=A1rthaigh wrote= : > I haven't been able to get my head around this. Doesn't that mean that > an attacker can disable 0RTT for third parties at will? To the extent that they can create connections that use 0RTT, yes. And yes, narrowing the window means that clients need clocks that are increasingly better synchronized to that of the server if they are to succeed under these sorts of conditions. From nobody Mon Mar 23 08:01: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 D8B8D1A8F46 for ; Mon, 23 Mar 2015 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UixmjVj9b44A for ; Mon, 23 Mar 2015 08:01:30 -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 74ECA1A8BAF for ; Mon, 23 Mar 2015 08:00:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CB570165D3C; Mon, 23 Mar 2015 15:00:54 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C0374165CC5; Mon, 23 Mar 2015 15:00:54 +0000 (GMT) Received: from Tereva.local (unknown [172.19.116.2]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 3745C9803E; Mon, 23 Mar 2015 15:00:54 +0000 (GMT) From: Brian Sniffen To: Martin Thomson , Roland Zink In-Reply-To: References: <55101D8B.7050909@zinks.de> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin14.0.0) Date: Mon, 23 Mar 2015 10:00:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:01:32 -0000 Martin Thomson writes: > On 23 March 2015 at 07:04, Roland Zink wrote: >> Does this mean a standard API will be specified. > > Probably more in the form of a generic recommendation, or a > requirement on what the API needs to achieve. APIs offering a socket model and attempting to provide a secure socket layer shouldn't use the 0RTT path at all, then? APIs exposing a record or message semantics (either TLS's, or their own) can use 0RTT iff they can guarantee idempotency of the messages in the 0RTT fragment? -Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somewhere along the spectrum from insufficiently nuanced through ill-informed to dead wrong." From nobody Mon Mar 23 08:06: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 8B93D1A901C for ; Mon, 23 Mar 2015 08:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg-zCbxXjnwb for ; Mon, 23 Mar 2015 08:06:26 -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 262A21A8FD6 for ; Mon, 23 Mar 2015 08:06:26 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6FE2528878 for ; Mon, 23 Mar 2015 15:06:25 +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 59B0228867 for ; Mon, 23 Mar 2015 15:06:25 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 55C538004A for ; Mon, 23 Mar 2015 15:06:25 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 23 Mar 2015 11:06:06 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 23 Mar 2015 11:06:06 -0400 From: "Salz, Rich" To: "Sniffen, Brian" Thread-Topic: [TLS] 0-RTT and Anti-Replay Thread-Index: AQHQZOoxUeEZJ8kfGkGiuqONqc5YFZ0qXeyAgAACMICAAA1ugP//vYog Date: Mon, 23 Mar 2015 15:06:06 +0000 Message-ID: References: <55101D8B.7050909@zinks.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.113.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:06:30 -0000 > APIs offering a socket model and attempting to provide a secure socket la= yer > shouldn't use the 0RTT path at all, then? TLS_SOCKOPT_STOP_ME_IF_YOUVE_HEARD_THIS_BEFORE ? Call me cynical, but search engines are going to force adoption of this. -- =20 Senior Architect, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Mon Mar 23 08:16: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 B82DB1A9024 for ; Mon, 23 Mar 2015 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvTFwYJDe_aB for ; Mon, 23 Mar 2015 08:16:15 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 927851A902E for ; Mon, 23 Mar 2015 08:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427123770; l=1251; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=NHfwACmfhUVn/5433pbgh5N8Gx1otlFKyPPyDs1LNlU=; b=nJt9TKMoiYd20Uwg2OV8V3q0DLRbxLFNT5efe/Lzh2WqtVVjevWlpTslg/OR24MPCGh QJZJBlo2n4d19JtcoEc4lMWhMkeiLp8sESsrNDhQlxD7kJJlKp+W6XUyZrGM+JKkZvfPH lkedpz4jOccgxxf/g3xKwwWG17S5dUHNFUc= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5UXpfUT3myN2hlbG+UDaVCoSA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id 505eb0r2NFG863B (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for ; Mon, 23 Mar 2015 16:16:08 +0100 (CET) Message-ID: <55102E3A.70300@zinks.de> Date: Mon, 23 Mar 2015 16:16:10 +0100 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> In-Reply-To: <20150323144052.GF9387@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:16:16 -0000 On 23.03.2015 15:40, Viktor Dukhovni wrote: > On Mon, Mar 23, 2015 at 03:33:09AM -0500, Nico Williams wrote: > >> Therefore, 0-RTT data must: >> >> * Require a non-default code path to send, (explicit request >> by the client to send a 0-RTT message). >> >> * Require a non-default code path to *receive*. That is, >> the server must be configured to allow receipt of such data, >> and must explicitly request to read it. If the server issues >> a read for protected data, while expedited 0-RTT data is >> pending, the connection should be aborted by the server's >> TLS stack. Once the server exhausts all the expedited >> data, it can switch to reading protected data. >> >> * The server's TLS stack must not coallesce 0-RTT expedited >> (idempotent) data with subsequent protected data. Often there is a whole software stack on top of TLS. You probably can't forward the requirements through the complete software stack. >> >> This allows servers that receive idempotent queries to avoid the >> 1-RTT latency. Something akin to DNS lookups over TLS, (I am not >> specifically advocating TLS as a transport for DNS in this message). Even DNS queries may have side effects, for example when it is used to do load balancing. From nobody Mon Mar 23 08:19: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 1DB371A9030 for ; Mon, 23 Mar 2015 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHRyEA9NZWrJ for ; Mon, 23 Mar 2015 08:18:57 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 CAC151A89FF for ; Mon, 23 Mar 2015 08:18:14 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so125432966obd.3 for ; Mon, 23 Mar 2015 08:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FiMswNW5ds79NiyEf4gyuGskkK8svF68G1vFOHKzrN8=; b=p2cCHXaDbovzf/bLPcbXQuFu4tZxEv3kDYK2Lf7/1d3VmF1n2qwDAT7a0lbpNbysCc XHtrEbKYBsMPFas2uTBzsrdZdxG9I/g+tmY/KzurSOw8NTjkJZg1isj8T7G3A8Iv6jnf xgWoplYfMeNPdpUaH/fdA9MXdSgcko3S775ZwBPr4EO+ThiPu216xzmjfYAUd9Roy+ml N19xWrU9CC7NPt20CSRHbnlUXFOJgFD2q6pNKqJJvvsiDlKnLJW8rgwUJnTkCkSc3HqM O6wC+ezIzPaetb+hjESyleiqST57PJsgIUMstVIvkWZ4s8+bnKOcctSF8tJ/l6mih19a LIIA== MIME-Version: 1.0 X-Received: by 10.182.34.131 with SMTP id z3mr6382302obi.4.1427123894327; Mon, 23 Mar 2015 08:18:14 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 08:18:14 -0700 (PDT) In-Reply-To: References: <55101D8B.7050909@zinks.de> Date: Mon, 23 Mar 2015 08:18:14 -0700 Message-ID: From: Martin Thomson To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:18:59 -0000 On 23 March 2015 at 08:00, Brian Sniffen wrote: > APIs offering a socket model and attempting to provide a secure socket > layer shouldn't use the 0RTT path at all, then? APIs exposing a record > or message semantics (either TLS's, or their own) can use 0RTT iff they > can guarantee idempotency of the messages in the 0RTT fragment That sounds like a reasonable first approximation. It might be that a streamed/socket protocol can intrinsically handle the replay problem because of the nature of the protocol, but in the generic sense, this would be correct. From nobody Mon Mar 23 08:20: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 62DA01A9026 for ; Mon, 23 Mar 2015 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqON3dpseSiH for ; Mon, 23 Mar 2015 08:20:45 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 4D7331A89FF for ; Mon, 23 Mar 2015 08:20:45 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so105195827obc.2 for ; Mon, 23 Mar 2015 08:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iRd74tGPftnoAxQjwv4sL8hCZiexE7tPaoFhxIYUrqc=; b=se3rp1YeJBTqaDBTPlwgMLYJRxa4DhIfWK3Dfs6sRnZPdTggM62kxRUrt0RTIzdt+E cohi8kP0vGRbdYI97veKnOhJ8rhohqVp9bqXD7PtLo/8k6AnA1jlZpJKeAVCtmFCnyca vFmqBYshZ3jph7XbF1EzR1oTUi5m2DIItRGMX87Zsz9B3g0AC2DCCgbOuix/FYQnf8oj T6UTWS5FbOnYZFq+5aeoIQf2fH5pLs5kzrV/9xqzcLbJdB9QplaKwuBqZB1WXWL/ukhm sW2PC5ZL+sY9Yft4riQc5GWLYJqt3n+O/eHqSPr/s4PQnpeDeCDvk793zNHGM+rt9jHJ Q/Ww== MIME-Version: 1.0 X-Received: by 10.60.56.39 with SMTP id x7mr4049436oep.65.1427124044712; Mon, 23 Mar 2015 08:20:44 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 08:20:44 -0700 (PDT) In-Reply-To: <55102E3A.70300@zinks.de> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> Date: Mon, 23 Mar 2015 08:20:44 -0700 Message-ID: From: Martin Thomson To: Roland Zink Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:20:47 -0000 On 23 March 2015 at 08:16, Roland Zink wrote: > Often there is a whole software stack on top of TLS. You probably can't > forward the requirements through the complete software stack. If you can't then don't. It is perhaps unfortunate, but this is going to have a very narrow applicability. From nobody Mon Mar 23 08: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 391071A9031; Mon, 23 Mar 2015 08:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpC9759g1AYZ; Mon, 23 Mar 2015 08:22:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F28861A89FF; Mon, 23 Mar 2015 08:22:05 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323152205.25971.50439.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:22:05 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-19.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, 23 Mar 2015 15:22:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-19.txt Pages : 11 Date : 2015-03-23 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 08:28: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 572FC1A907E for ; Mon, 23 Mar 2015 08:28: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdJDdNynAGKr for ; Mon, 23 Mar 2015 08:28:37 -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 E7C261A8FD6 for ; Mon, 23 Mar 2015 08:28:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D1214283011; Mon, 23 Mar 2015 15:28:31 +0000 (UTC) Date: Mon, 23 Mar 2015 15:28:31 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150323152831.GG9387@mournblade.imrryr.org> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55102E3A.70300@zinks.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay 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, 23 Mar 2015 15:28:38 -0000 On Mon, Mar 23, 2015 at 04:16:10PM +0100, Roland Zink wrote: > >> * The server's TLS stack must not coalesce 0-RTT expedited > >> (idempotent) data with subsequent protected data. > > Often there is a whole software stack on top of TLS. You probably can't > forward the requirements through the complete software stack. That's good. Such software stacks will not be 0-RTT aware, and must not see 0-RTT data. Only stacks explicitly designed for 0-RTT will get to play. > >>This allows servers that receive idempotent queries to avoid the > >>1-RTT latency. Something akin to DNS lookups over TLS, (I am not > >>specifically advocating TLS as a transport for DNS in this message). > > Even DNS queries may have side effects, for example when it is used to do > load balancing. DNS "load-balancers" are really latency optimizers, they don't actually know how much load they are directing at servers because there is a not a 1-to-1 mapping between DNS requests and service requests. There should be no state changes based on the observed DNS queries, and if even there are, nothing tragic happens. The intended application here would be confidentiality only. -- Viktor. From nobody Mon Mar 23 08:42: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 0CD011A8F4B for ; Mon, 23 Mar 2015 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxOdlPhNWFib for ; Mon, 23 Mar 2015 08:42:35 -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 CA9C11A89B8 for ; Mon, 23 Mar 2015 08:42:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id D8960BACA8; Mon, 23 Mar 2015 15:05:49 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2NF5lmD019607 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 11:05:49 -0400 Message-ID: <1427123147.19595.62.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Mon, 23 Mar 2015 16:05:47 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:42:38 -0000 On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote: > Folks, > At the interim discussed transitioning to a DH-based handshake (rather > than a signature-based one) like that proposed by Hugo Krawczyk and > Hoeteck Wee. The major rationale for this change is that any 0-RTT > mode is inherently DH-based and so if we make that our basic mode, > then we can simplify the protocol logic and key derivation model. This > model also allows us to pull in PSK modes under the same basic > structure. [...] > The WG sentiment was generally favorable to exploring this avenue but > there was also airly strong WG sentiment that we didn't presently want > to do an offline signatures. This leaves with a model in which the > client initially learns the server's semi-static DH share through > an online-signed 1-RTT handshake but then can cache it for use with > future connections. Wasn't that discussed in the list before? My impression was that the outcome of that discussion was not to add that. Anyway, a first question that comes to mind, is why this isn't defined as separate ciphersuites? Why does it even have to be TLS 1.3 related? Static DH parameters is an experiment that failed years ago. What has changed since then that we believe now it is going to work? You even dropped the static DH ciphersuites from TLS 1.3. Please make that part optional so you don't doom the whole TLS 1.3 protocol enhancements if no-one switches to static DH keys (in the document they are described as semi-static DH keys - but there is no definition of what that means). A second question is why HKDF? Why is it even there? Is there any issue with the current TLS PRF and we need another? Is there a valid reason to bloat implementations with shipping multiple KDFs? This kind of changes shouldn't be done without thought, as it is now there cannot be any code sharing between TLS 1.2 and 1.3 and we risk having implementers stay with TLS 1.2 for the next decade. regards, Nikos From nobody Mon Mar 23 09:08: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 251D01AC3DF for ; Mon, 23 Mar 2015 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ0VbO2j9iYR for ; Mon, 23 Mar 2015 09:08:18 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (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 D28151A92B6 for ; Mon, 23 Mar 2015 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427126895; l=1809; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=WohEgxlf2jQgeXI+jq3DiXY1aeskyVAGzA4VRzkoE0M=; b=qmOPMhXUUkt5txrGUzmHzuYYaTRh1E8OAxJv9HZ11FdUiOQp4UVMXdkdAiPV5NgGJ7T saEwQu53TorHuPKRT87hMZRpxC8QmosGGoh8D0VhNYxzDhwp0yfgfZz0Hx32akbrqaSru sCM1x1wVdIL+i/FzOrJOcu6wVppdbAac/K8= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5UXpfUT3myN2hlbG+UDaVCoSA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id 204104r2NG8C6SO (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for ; Mon, 23 Mar 2015 17:08:12 +0100 (CET) Message-ID: <55103A6E.4060409@zinks.de> Date: Mon, 23 Mar 2015 17:08:14 +0100 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> In-Reply-To: <20150323152831.GG9387@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:08:19 -0000 On 23.03.2015 16:28, Viktor Dukhovni wrote: > On Mon, Mar 23, 2015 at 04:16:10PM +0100, Roland Zink wrote: > >>>> * The server's TLS stack must not coalesce 0-RTT expedited >>>> (idempotent) data with subsequent protected data. >> Often there is a whole software stack on top of TLS. You probably can't >> forward the requirements through the complete software stack. > That's good. Such software stacks will not be 0-RTT aware, and > must not see 0-RTT data. Only stacks explicitly designed for 0-RTT > will get to play. Seem like very limited use, but still when somebody builds something on top of such a stack not knowing that something special needs to be done. Simplest may be a HTTP library thinking GET requests are idempotent, which they should, and is doing 0-RTT and the server does something on the GET request like fire some missiles. >>>> This allows servers that receive idempotent queries to avoid the >>>> 1-RTT latency. Something akin to DNS lookups over TLS, (I am not >>>> specifically advocating TLS as a transport for DNS in this message). >> Even DNS queries may have side effects, for example when it is used to do >> load balancing. > DNS "load-balancers" are really latency optimizers, they don't > actually know how much load they are directing at servers because > there is a not a 1-to-1 mapping between DNS requests and service > requests. There should be no state changes based on the observed > DNS queries, and if even there are, nothing tragic happens. The > intended application here would be confidentiality only. > Well DNS is only an example anyway. Assuming the server is returning A,B on even requests and B,A on odd requests and an attacker replays all requests then the server will always returning the same result to the real clients. From nobody Mon Mar 23 09:14:43 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 E6F731AC41C for ; Mon, 23 Mar 2015 09:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNseFttmGfQ9 for ; Mon, 23 Mar 2015 09:14:38 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.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 7B7561AC40D for ; Mon, 23 Mar 2015 09:14:37 -0700 (PDT) Received: by wegp1 with SMTP id p1so141912286weg.1 for ; Mon, 23 Mar 2015 09:14:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AFhw3XJLtoV7QDgek2xSqyQd8dFoopxwg9omjfMmnDU=; b=lSM0IMJvBIfis6vHvHXoU+X7pTKhG6gA5pZQPLgJ9RLtpWySlQc8paCnIz9nM1aXdR GLCWy4KO8tsReH9hFIxZ5FqAm1WdHTVuZ3v/rVEH+rzaaaroUlheyjv9MbdLkHTy0BOm JPF1UKYiinhSgRLnrTBv8XIvinEJMzhrs/Z7LRqv6ZvIQEsgauhw4j5BqRkJCZGbBMaV 33kaBMC/3ze4SprfbeaxOygpfaCB+j4vQ6/XgcTPyJYVFVnMiX3EqHnmy6SipI0dKoTd 51yos3+dypU+hSJbgutFP6N1F0rjWelGC6Gh0Qddp9uetNs6O86aoMav52HViRVz4IYm xB7A== X-Gm-Message-State: ALoCoQljDew6GCYQDszFbEZBXgl5q/vRH9sokInH25hrfPLP9qZgWmguL1nfv2WpyGuz23y56bRv X-Received: by 10.194.120.230 with SMTP id lf6mr183866380wjb.78.1427127276253; Mon, 23 Mar 2015 09:14:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 09:13:56 -0700 (PDT) In-Reply-To: <1427123147.19595.62.camel@redhat.com> References: <1427123147.19595.62.camel@redhat.com> From: Eric Rescorla Date: Mon, 23 Mar 2015 11:13:56 -0500 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=089e0115fe2459c8320511f6f6a2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:14:42 -0000 --089e0115fe2459c8320511f6f6a2 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 10:05 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote: > > Folks, > > At the interim discussed transitioning to a DH-based handshake (rather > > than a signature-based one) like that proposed by Hugo Krawczyk and > > Hoeteck Wee. The major rationale for this change is that any 0-RTT > > mode is inherently DH-based and so if we make that our basic mode, > > then we can simplify the protocol logic and key derivation model. This > > model also allows us to pull in PSK modes under the same basic > > structure. > [...] > > The WG sentiment was generally favorable to exploring this avenue but > > there was also airly strong WG sentiment that we didn't presently want > > to do an offline signatures. This leaves with a model in which the > > client initially learns the server's semi-static DH share through > > an online-signed 1-RTT handshake but then can cache it for use with > > future connections. > > Wasn't that discussed in the list before? My impression was that the > outcome of that discussion was not to add that. > There was enough interest that we decided to revisit it at the interim in view of the considerations I listed above, and the chairs asked me to draft it up so we could discuss here and in Dallas. As I said above, the WG can of course decide not to proceed in this direction which is why this is a separate branch rather than -06. > Anyway, a first question that comes to mind, is why this isn't defined > as separate ciphersuites? Why does it even have to be TLS 1.3 related? > Static DH parameters is an experiment that failed years ago. What has > changed since then that we believe now it is going to work? You even > dropped the static DH ciphersuites from TLS 1.3. Please make that part > optional so you don't doom the whole TLS 1.3 protocol enhancements if > no-one switches to static DH keys (in the document they are described as > semi-static DH keys - but there is no definition of what that means). > Well, what's being done here is qualitatively different in three ways: 1. The DH keys aren't in DH certificates (though one supposes they could be), rather they are attested to by the server signing key. 2. The semi-static DH keys are expected to be quite short-lived (possible because of point #1). Hence 'semi-static'. 3. We are doing a separate ephemeral-ephemeral DH exchange to provide PFS. The argument for not making it a cipher suite is that doing things this way allows us to have a unified protocol logic whereas that's not true if it's a separate option. A second question is why HKDF? Why is it even there? Is there any issue > with the current TLS PRF and we need another? Is there a valid reason to > bloat implementations with shipping multiple KDFs? As I said separately [0], there was some sentiment in the interim that HKDF was a more modern primitive. As above, I can easily back this out and use the existing PRF if that's what people prefer. -Ekr [0] https://www.ietf.org/mail-archive/web/tls/current/msg15625.html --089e0115fe2459c8320511f6f6a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 23, 2015 at 10:05 AM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
On Mon, 2015-= 03-23 at 08:36 -0500, Eric Rescorla wrote:
> Folks,
> At the interim discussed transitioning to a DH-based handshake (rather=
> than a signature-based one) like that proposed by Hugo Krawczyk and > Hoeteck Wee. The major rationale for this change is that any 0-RTT
> mode is inherently DH-based and so if we make that our basic mode,
> then we can simplify the protocol logic and key derivation model. This=
> model also allows us to pull in PSK modes under the same basic
> structure.
[...]
> The WG sentiment was generally favorable to exploring= this avenue but
> there was also airly strong WG sentiment that we didn't presently = want
> to do an offline signatures. This leaves with a model in which the
> client initially learns the server's semi-static DH share through<= br> > an online-signed 1-RTT handshake but then can cache it for use with > future connections.

Wasn't that discussed in the list before? My impression was that= the
outcome of that discussion was not to add that.

There was enough interest that we decided to revisit it at th= e interim
in view of the considerations I listed above, and the c= hairs asked
me to draft it up so we could discuss here and in Dal= las. As I said
above, the WG can of course decide not to pr= oceed in this direction
which is why this is a separate branch ra= ther than -06.

=C2=A0
Anyway, a first question that comes to mind, is why this isn't defined<= br> as separate ciphersuites? Why does it even have to be TLS 1.3 related?
Static DH parameters is an experiment that failed years ago. What has
changed since then that we believe now it is going to work? You even
dropped the static DH ciphersuites from TLS 1.3. Please make that part
optional so you don't doom the whole TLS 1.3 protocol enhancements if no-one switches to static DH keys (in the document they are described as semi-static DH keys - but there is no definition of what that means).

Well, what's being done here is qualitat= ively different in three ways:

1. The DH keys aren= 't in DH certificates (though one supposes they
=C2=A0 =C2=A0= could be), rather they are attested to by the server signing key.

2. The semi-static DH keys are expected to be quite short-= lived
=C2=A0 =C2=A0 (possible because of point #1). Hence 'se= mi-static'.

3. We are doing a separate ephemer= al-ephemeral DH exchange to
=C2=A0 =C2=A0 provide PFS.
=
The argument for not making it a cipher suite is that doing = things
this way allows us to have a unified protocol logic wherea= s that's
not true if it's a separate option.



A second question is why HKDF? Why is it even there? Is there any issue
with the current TLS PRF and we need another? Is there a valid reason to bloat implementations with shipping multiple KDFs?

As I said separately [0], there was some sentiment in the interim t= hat
HKDF was a more modern primitive. As above, I can easily back= this
out and use the existing PRF if that's what people pref= er.

-Ekr



--089e0115fe2459c8320511f6f6a2-- From nobody Mon Mar 23 09:22: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 D4C621AC418 for ; Mon, 23 Mar 2015 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0hrjE5yjwU8 for ; Mon, 23 Mar 2015 09:22:02 -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 6579D1A92B6 for ; Mon, 23 Mar 2015 09:22:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD049283011; Mon, 23 Mar 2015 16:22:00 +0000 (UTC) Date: Mon, 23 Mar 2015 16:22:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150323162200.GI9387@mournblade.imrryr.org> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55103A6E.4060409@zinks.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay 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, 23 Mar 2015 16:22:04 -0000 On Mon, Mar 23, 2015 at 05:08:14PM +0100, Roland Zink wrote: > > >Often there is a whole software stack on top of TLS. You probably can't > > >forward the requirements through the complete software stack. > > > >That's good. Such software stacks will not be 0-RTT aware, and > >must not see 0-RTT data. Only stacks explicitly designed for 0-RTT > >will get to play. > > Seems like very limited use, Deliberately so, for people who know what they are doing, to support latency sensitive idempotent requests that don't need request replay protection. > but still when somebody builds something on top of such a stack not knowing > that something special needs to be done. They lose. * If clients make 0-RTT requests to a stack that does not support these, all connection abort when the stack requests non-expedited data, while expedited data is pending. * If the stack requests expedited data without an explicit request from the server application to do that, it is broken. Vulnerability reports will be filed, everyone will run around patching, ... > Simplest may be a HTTP library thinking GET requests are idempotent, which > they should, and is doing 0-RTT and the server does something on the GET > request like fire some missiles. HTTP libraries have no business doing that (bring on the sky is falling vulnerability reports, emergency patch cycles, ...). The application would have to explicitly signal support for such requests, and when they arrive they'd have to be clearly tagged as such consistent with the API that enabled their delivery. -- Viktor. From nobody Mon Mar 23 09:36:45 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 BD68C1ACD33 for ; Mon, 23 Mar 2015 09:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TVteasbbuRm for ; Mon, 23 Mar 2015 09:36:42 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::8]) (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 7FEFB1ACC8C for ; Mon, 23 Mar 2015 09:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427128595; l=513; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date; bh=Vc3jIJStC9D8f6mzlqgUE1lWxhIvTiZKv5BYRwsO0Yk=; b=OjbvgctmuiKEjXqfNIav8ScQDP9lsmm+xUFRokqx/cARsyPkhhBowdLbYm/ihZkh7S1 sQ9iTLjt6CqsODXN6qBh702n6IYmdragZ0fPHOtrN9GTrvmUwUyUmi9Ye2D45vfI/ij3s I/HDQdgTY5RLTH2pbBTQMngLJPIrt7btDtI= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzTv5UXpfUT3myN2hlbG+UDaVCoSA== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:b430:a134:91bc:ebfa] ([2001:4dd0:ff67:0:b430:a134:91bc:ebfa]) by smtp.strato.de (RZmta 37.4 AUTH) with ESMTPSA id d07d4br2NGaZ85x (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256)) (Client did not present a certificate) for ; Mon, 23 Mar 2015 17:36:35 +0100 (CET) Message-ID: <55104114.5060903@zinks.de> Date: Mon, 23 Mar 2015 17:36:36 +0100 From: Roland Zink User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> In-Reply-To: <20150323162200.GI9387@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:36:43 -0000 On 23.03.2015 17:22, Viktor Dukhovni wrote: > They lose. > > * If clients make 0-RTT requests to a stack that does not > support these, all connection abort when the stack requests > non-expedited data, while expedited data is pending. > > * If the stack requests expedited data without an explicit > request from the server application to do that, it is broken. > Vulnerability reports will be filed, everyone will run around > patching, ... > Hope you will not get many such vulnerability reports. From nobody Mon Mar 23 09:44: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 3AE6C1ACD73 for ; Mon, 23 Mar 2015 09:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtZhpQWAopjT for ; Mon, 23 Mar 2015 09:44:21 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) (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 DD60D1ACD77 for ; Mon, 23 Mar 2015 09:44:16 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so127491127obc.0 for ; Mon, 23 Mar 2015 09:44:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yjlpzE1QtF2o29QvemvFg86a119reR8rIOHn2eqYVFU=; b=RiXqdBsf5vzE6UEGGI33hyotvbqmuihicxBin1edTAbHuaec8HC8x0mXQZXsdneUuJ HkFlNrCido1Fdqjwlvmz2jsi7dffpWu2yjcE6HA6cQK+wFaVOOC8VuJm+YzIow758yHE WyDvBhDSHTxp5ms7IFRToMMXfdPpWu3Cm65xgB7g5dQpVFUuxIhfuR8Okp3jk7rg+OVw sKr8HKPKIlMPbIfZ0peTfDQiE3tfZig5YDKH/pnSBdQadU93xI1p0gXhAShfKrEOROce QGq/CovGN3i+XIYCI8Uy+rOTmO9jcDFMj/WLnSrY0lBJ7mUv1CoVmg0T9R+V1QWkrWnE FqnA== X-Gm-Message-State: ALoCoQngpF5b6bYaCDEPV9rufo923JrYd1CK2akoo8HUeo4PNYM1jc25Q4r+S7An128cpma1l7J/ MIME-Version: 1.0 X-Received: by 10.202.210.215 with SMTP id j206mr43108367oig.131.1427129056364; Mon, 23 Mar 2015 09:44:16 -0700 (PDT) Received: by 10.76.129.235 with HTTP; Mon, 23 Mar 2015 09:44:16 -0700 (PDT) In-Reply-To: <20150323162200.GI9387@mournblade.imrryr.org> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> Date: Mon, 23 Mar 2015 09:44:16 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:44:28 -0000 On Mon, Mar 23, 2015 at 9:22 AM, Viktor Dukhovni wrote: > Deliberately so, for people who know what they are doing, to support > latency sensitive idempotent requests that don't need request replay > protection. Should using TLS securely rely on that level of expertise? it is also an incredible temptation to have the possibility of optimistic execution, and just not pay any attention to the idempotent (or reliability) issues. Are there that many applications that are this latency sensitive that can't use long-lived connections/sessions? -- Colm From nobody Mon Mar 23 09:52: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 DEA431ACD21 for ; Mon, 23 Mar 2015 09:52:06 -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 VGu3dK3M_9xn for ; Mon, 23 Mar 2015 09:52:04 -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 119701A8A17 for ; Mon, 23 Mar 2015 09:52:04 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id E8AFB699DA for ; Mon, 23 Mar 2015 18:52:01 +0200 (EET) Date: Mon, 23 Mar 2015 18:52:01 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20150323165201.GA15202@LK-Perkele-VII> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150323162200.GI9387@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:52:07 -0000 On Mon, Mar 23, 2015 at 04:22:00PM +0000, Viktor Dukhovni wrote: > > * If clients make 0-RTT requests to a stack that does not > support these, all connection abort when the stack requests > non-expedited data, while expedited data is pending. I regard that as very bad idea. The server should reject the 0-RTT data, not abort the connection, because the former can sanely be handled by the client, the latter can't. -Ilari From nobody Mon Mar 23 09:59:45 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 05FBB1ACDD5 for ; Mon, 23 Mar 2015 09:59: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 MV6XXjTlDePg for ; Mon, 23 Mar 2015 09:59:43 -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 EE9021ACD86 for ; Mon, 23 Mar 2015 09:59:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6262F283011; Mon, 23 Mar 2015 16:59:36 +0000 (UTC) Date: Mon, 23 Mar 2015 16:59:36 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150323165936.GK9387@mournblade.imrryr.org> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> <20150323165201.GA15202@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150323165201.GA15202@LK-Perkele-VII> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:59:44 -0000 On Mon, Mar 23, 2015 at 06:52:01PM +0200, Ilari Liusvaara wrote: > On Mon, Mar 23, 2015 at 04:22:00PM +0000, Viktor Dukhovni wrote: > > > > * If clients make 0-RTT requests to a stack that does not > > support these, all connection abort when the stack requests > > non-expedited data, while expedited data is pending. > > I regard that as very bad idea. The server should reject the > 0-RTT data, not abort the connection, because the former can > sanely be handled by the client, the latter can't. A connection on which the initial data was lost is broken. Signalling such loss is simplest by dropping the connection. In practice 0-RTT clients will talk to 0-RTT enabled servers. Everyone else avoids the can of worms. The 0-RTT mechanism will support the specialized applications that need it. -- Viktor. From nobody Mon Mar 23 10:07: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 905311ACD8A for ; Mon, 23 Mar 2015 10:07:41 -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 wrmx_mlaA2fN for ; Mon, 23 Mar 2015 10:07:37 -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 D7A961AC3B4 for ; Mon, 23 Mar 2015 10:07:36 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 26B821A25F3; Mon, 23 Mar 2015 19:07:33 +0200 (EET) Date: Mon, 23 Mar 2015 19:07:33 +0200 From: Ilari Liusvaara To: Viktor Dukhovni Message-ID: <20150323170733.GA18328@LK-Perkele-VII> References: <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> <20150323165201.GA15202@LK-Perkele-VII> <20150323165936.GK9387@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150323165936.GK9387@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:07:41 -0000 On Mon, Mar 23, 2015 at 04:59:36PM +0000, Viktor Dukhovni wrote: > On Mon, Mar 23, 2015 at 06:52:01PM +0200, Ilari Liusvaara wrote: > > > On Mon, Mar 23, 2015 at 04:22:00PM +0000, Viktor Dukhovni wrote: > > > > > > * If clients make 0-RTT requests to a stack that does not > > > support these, all connection abort when the stack requests > > > non-expedited data, while expedited data is pending. > > > > I regard that as very bad idea. The server should reject the > > 0-RTT data, not abort the connection, because the former can > > sanely be handled by the client, the latter can't. > > A connection on which the initial data was lost is broken. Signalling > such loss is simplest by dropping the connection. No, it isn't. The client will need to handle 0-RTT being lost anyway. And even if the client manages to guess what went wrong (if it doesn't non-retry error is the best case), recovering from abort much more expensive. -Ilari From nobody Mon Mar 23 10:09: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 6B88A1ACE2A for ; Mon, 23 Mar 2015 10:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBLoB7lN-gO4 for ; Mon, 23 Mar 2015 10:09:55 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 708581ACE11 for ; Mon, 23 Mar 2015 10:09:55 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 411E65408A; Mon, 23 Mar 2015 10:09:55 -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=0hLTwmy/LNj3b4 mY7fbl15/aUYQ=; b=RfaGCU0CLikIE3v6ILyWTf75mgw/uAS7+XJUDgBlWomHk+ IQu+zTGdxukvfgyRB8sqi1W0eD4dfACKOfqC35XGAswLpXng/EL2zfFUchwyF2kZ OpPFezujqq93jm0gifob5fMryg11pEpEG1eV2csQKf0wVhFFHh5OkbzzqZPqU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 817615408B; Mon, 23 Mar 2015 10:09:54 -0700 (PDT) Date: Mon, 23 Mar 2015 12:08:52 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150323170851.GN21267@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:09:56 -0000 I'm missing some of the context. Is this 0-RTT fast reconnect (a la TCP-FO) or is this 0-RTT even for first-meet? Regardless: - I don't really believe that distributed replay caches, are feasible without adding back a lot of the latency to be gained from having 0-RTT. Fast non-distributed replay caches are feasible, but from the discussion so far it seems like that's not interesting anyways. This is Kerberos experience talking. Kerberos, you'll recall, hearts replay caches. We do know how to make fast local replay caches, and even adaptive ones that respond to load. - I've made this point in the past that 0-RTT data has to be of the sort that is safe to use in this way, and therefore I agree strongly with comments made so far that this must show up in the API (client- and server-side) as such. - Idempotence isn't necessarily enough. "Launch missiles" might be idempotent (e.g., world ending) or not ("accidental launch?"), but in the latter case a replay might then be idempotent (not accidental -> world ending). - And just in case anyone is proposing it, I object to TLS interpreting supposed-to-be-idempotent HTTP requests as idempotent. As others have mentioned, there exist plenty of "HTTP APIs" that violate HTTP idempotence requirements. Perhaps we should point and laugh, but ignoring them seems unwise. - Data to be delivered in a 0-RTT way really must be used with care. Any API must require that the application [developer] be aware of this. FYI, I had an I-D once about combining SASL mechanism negotiation into the TLS handshake so as to speed up LDAP, IMAP, and other SASL applications. There the 0-RTT data was the SASL mechanism negotiation, and though it was used prior to handshake completion, its integrity was also confirmed before any incorrectly-chosen SASL mechanism could yield success and access for the attacker. My I-D was specifically about SASL. Generalizing this to "any protocol" without taking care to explain what kind of data can be used is dangerous. Also FYI, GSS-API has ways to send/receive generic 0-RTT data with complete handshakes, and has the same considerations that we are describing for TLS. The GS2 SASL mechanism uses this, again, for negotiation purposes, not for application data, but the technique used works for application data as well, with the caveats that we're discussing. The GSS case has not had a full treatment in any RFCs, but there's some hints about it here and there. At least GSS got the API right: the application has to take extra steps to send and use 0-RTT data. TLS is much more widespread than GSS, therefore the potential harm of misuse of 0-RTT data is much higher. Nico -- From nobody Mon Mar 23 10:14:43 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 EB0AF1ACE55 for ; Mon, 23 Mar 2015 10:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUN5y4oOhOch for ; Mon, 23 Mar 2015 10:14: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 E1C2B1ACE4F for ; Mon, 23 Mar 2015 10:14:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D72E8283011; Mon, 23 Mar 2015 17:14:39 +0000 (UTC) Date: Mon, 23 Mar 2015 17:14:39 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20150323171439.GL9387@mournblade.imrryr.org> References: <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> <20150323165201.GA15202@LK-Perkele-VII> <20150323165936.GK9387@mournblade.imrryr.org> <20150323170733.GA18328@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150323170733.GA18328@LK-Perkele-VII> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay 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, 23 Mar 2015 17:14:42 -0000 On Mon, Mar 23, 2015 at 07:07:33PM +0200, Ilari Liusvaara wrote: > > A connection on which the initial data was lost is broken. Signalling > > such loss is simplest by dropping the connection. > > No, it isn't. The client will need to handle 0-RTT being lost > anyway. Naturally before disconnecting, the server stack should send an appropriate alert. But since clients should only be configured for 0-RTT with application protocols where the server is required to support 0-RTT, there's no point in falling back. I don't see 0-RTT as an "opportunistic" feature. I see it as support for latency-sensitive idempotent applications in which it is always used. Eliminating fallback to 1-RTT avoids much complexity. -- Viktor. From nobody Mon Mar 23 10:16: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 64F431ACE59 for ; Mon, 23 Mar 2015 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATzjpGuWTZGz for ; Mon, 23 Mar 2015 10:16:35 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A76721ACE58 for ; Mon, 23 Mar 2015 10:16:35 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 867CF2005E61E; Mon, 23 Mar 2015 10:16:35 -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:content-transfer-encoding; s= cryptonector.com; bh=VZ4VYGHzqSuGabHBSjMJRKCGgQk=; b=mCej2MzF5wX yLss0iJ/Q/8aQQhJL24StOqYR0LLNvAGsGOaRvkvb+yePCsUb9mvRSVFuypLo8eI 0hNy5F8IKg5DU6u7jCHB3E2wL56B5hE35lihfafDSQDOgsat9kXLHCtQ8LMF7keU NxU+oQFPMsybM3Tnz5TMCXPPGZw/3f6w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id A03152005E61C; Mon, 23 Mar 2015 10:16:34 -0700 (PDT) Date: Mon, 23 Mar 2015 12:15:32 -0500 From: Nico Williams To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Message-ID: <20150323171532.GO21267@localhost> References: <550F6582.9040602@brainhub.org> <20150323083308.GL21267@localhost> <20150323144052.GF9387@mournblade.imrryr.org> <55102E3A.70300@zinks.de> <20150323152831.GG9387@mournblade.imrryr.org> <55103A6E.4060409@zinks.de> <20150323162200.GI9387@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:16:36 -0000 On Mon, Mar 23, 2015 at 09:44:16AM -0700, Colm MacC=E1rthaigh wrote: > On Mon, Mar 23, 2015 at 9:22 AM, Viktor Dukhovni wrote: > > Deliberately so, for people who know what they are doing, to support > > latency sensitive idempotent requests that don't need request replay > > protection. >=20 > Should using TLS securely rely on that level of expertise? it is also > an incredible temptation to have the possibility of optimistic > execution, and just not pay any attention to the idempotent (or > reliability) issues. In some sense this is unavoidable. Consider channel binding. In the SASL/GS2 framework we use the GSS channel binding data input to deliver data beyond just proper channel binding data, but the data so delivered is negotiation data. (Integrity protection of that data is delivered eventually.) Now, TLS may not have a proper channel binding data _input_, but developers, I'm sure, could marshall something. Imagine a StartTLS protocol where the client sends a request (launch missiles) and a request/offer to upgrade to TLS, with subsequent integrity protection of the "0-RTT" data from the first request: if the server has acted on the 0-RTT data by then, it's too late. Therefore it seems that the issue is somewhat unavoidable even if we exclude a 0-RTT mode in TLS, and so we should describe the associated security considerations. Nico --=20 From nobody Mon Mar 23 10:21: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 6972A1ACE62 for ; Mon, 23 Mar 2015 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyDfXM59E1Ok for ; Mon, 23 Mar 2015 10:20:58 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5D1ACE61 for ; Mon, 23 Mar 2015 10:20:58 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id C4DD377805F; Mon, 23 Mar 2015 10:20:57 -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=BWuQ/MuOUTqWNh oJtM2MEfNgbGQ=; b=VNZ7tMKhi+f1DFu+16zgOUbUYvkurVAI57Cruojo8a+vOl Z8f87b6k51L548KspyT8z4y2kueJfxzA88axGwOO5kCdShqpVHP5iWj/0XTB8ys0 +aLCccJYSTrUEr6vO9n8ULm8Ay3fg7eeYnTwdkDjkZONOrbEJGncITuEugPyc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id 55B0E77805B; Mon, 23 Mar 2015 10:20:57 -0700 (PDT) Date: Mon, 23 Mar 2015 12:19:55 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150323171955.GP21267@localhost> References: <20150323084716.GM21267@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] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:20:59 -0000 On Mon, Mar 23, 2015 at 08:11:59AM -0500, Eric Rescorla wrote: > On Mon, Mar 23, 2015 at 3:47 AM, Nico Williams > wrote: > > This is an optimization. > > > > If the server loses its replay state then it must cause every 0-RTT > > connection to become a 1-RTT connection. There's no question of "want". > > Maybe I wasn't clear. When I said "reject" I meant "hard-fail" rather than > make it 1-RTT. Sorry it wasn't clear to me. Is there any reason that fallback to 1-RTT is not feasible? For context, I'm proposing similar fallbacks (but for other reasons) for Kerberos (which never had such a fallback). This has proven desirable in the context of Kerberos, and so I suspect it will be for TLS. Obviously I'm missing some of the TLS 0-RTT context. Nico -- From nobody Mon Mar 23 10:42: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 DE7231ACEEE for ; Mon, 23 Mar 2015 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlzkcbLqmTXo for ; Mon, 23 Mar 2015 10:42:23 -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 64B911ACED5 for ; Mon, 23 Mar 2015 10:42:15 -0700 (PDT) Received: by wixw10 with SMTP id w10so38970405wix.0 for ; Mon, 23 Mar 2015 10:42: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=Pd78JMOaI7UpkWRX0M3hYCpg4z1DpKT9/bwFHMKaI3A=; b=LlnLSTZPJCwKpU/d5YxZqn7mVTAHZsD8sKeQNfyFPGyazT01zUMA2cGyAK5m2/nKXe PCjKUpjPIIoKlEuh3gA/eYDiCsXqI3PImrj3Zv+8YSNhd7bvAwOvC6PF1RNXDtxqjgn/ l8yb4lWlTyv0IJkhjA5KJArdr/0CnAopLfI2F8+6+v3lAm6TfBvKOj5SH5PZtuDF+qM0 nfvoDiMDsGuBtcIIsrLFFieq4XnivS1w/cB+go92c3ivCmHu3hsKGg9pniLiIIUf3Al4 4T3EmqNMlTdDSFoqiuTXp3yY7Y7s2lozp836najxlHnBqgmJJagz+VQSUz02ErQf3Prq m70A== X-Gm-Message-State: ALoCoQkoDr4R9R/SAfFCJq+saaaJ+/HBGiR3h2/WjfMMM9kDq3l4uUHbOZmv109k30qIQtWHEUfg X-Received: by 10.180.7.194 with SMTP id l2mr21459655wia.39.1427132534115; Mon, 23 Mar 2015 10:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 10:41:33 -0700 (PDT) In-Reply-To: <20150323171955.GP21267@localhost> References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@localhost> From: Eric Rescorla Date: Mon, 23 Mar 2015 12:41:33 -0500 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=90e6ba614138be62d40511f82f2a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:42:25 -0000 --90e6ba614138be62d40511f82f2a Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 12:19 PM, Nico Williams wrote: > On Mon, Mar 23, 2015 at 08:11:59AM -0500, Eric Rescorla wrote: > > On Mon, Mar 23, 2015 at 3:47 AM, Nico Williams > > wrote: > > > This is an optimization. > > > > > > If the server loses its replay state then it must cause every 0-RTT > > > connection to become a 1-RTT connection. There's no question of > "want". > > > > Maybe I wasn't clear. When I said "reject" I meant "hard-fail" rather > than > > make it 1-RTT. > > Sorry it wasn't clear to me. Is there any reason that fallback to 1-RTT > is not feasible? > Yes. The issue is that the client has no way of knowing whether the 0-RTT message was duplicated and processed by a separate server instance, so when it falls back to 1-RTT, resending the initial data may be a replay. -Ekr For context, I'm proposing similar fallbacks (but for other reasons) for > Kerberos (which never had such a fallback). This has proven desirable > in the context of Kerberos, and so I suspect it will be for TLS. > > Obviously I'm missing some of the TLS 0-RTT context. > > Nico > -- > --90e6ba614138be62d40511f82f2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 23, 2015 at 12:19 PM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
On Mon, Mar 23, 2015 at 08:11:59AM -0500, Eric Rescorla wrote:
> On Mon, Mar 23, 2015 at 3:47 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > This is an optimization.
> >
> > If the server loses its replay state then it must cause every 0-R= TT
> > connection to become a 1-RTT connection.=C2=A0 There's no que= stion of "want".
>
> Maybe I wasn't clear. When I said "reject" I meant "= ;hard-fail" rather than
> make it 1-RTT.

Sorry it wasn't clear to me.=C2=A0 Is there any reason that fall= back to 1-RTT
is not feasible?

Yes. The issue is that= the client has no way of knowing whether the 0-RTT
message was d= uplicated and processed by a separate server instance, so
when it= falls back to 1-RTT, resending the initial data may be a replay.

-Ekr



=
For context, I'm proposing similar fallbacks (but for other reasons) fo= r
Kerberos (which never had such a fallback).=C2=A0 This has proven desirable=
in the context of Kerberos, and so I suspect it will be for TLS.

Obviously I'm missing some of the TLS 0-RTT context.

Nico
--

--90e6ba614138be62d40511f82f2a-- From nobody Mon Mar 23 10:47: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 300C11ACEF4 for ; Mon, 23 Mar 2015 10:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQrRijZmN5nt for ; Mon, 23 Mar 2015 10:47:33 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 61EAC1ACEE5 for ; Mon, 23 Mar 2015 10:47:33 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 0CB73778070 for ; Mon, 23 Mar 2015 10:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fNMSaunGfdH4icnbtMqH rm2nJJE=; b=MOneipUS8p9q38V/Z5nrwuoSpNn6O5bbhZPTpi0wyEgXMOJLjBH4 xRpSCY2++xKOXMjLpL23pUrpsEy2PpMY2M13o90MPhdCmtG/3y5I2Eyz1yTJeMmP 7jjpBrF1kkyZYQF8kDBUk+e4KEdO7HntsChEzfm5AWf9h61Nt2nF/fM= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id C91EF77805F for ; Mon, 23 Mar 2015 10:47:32 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so41885262iec.0 for ; Mon, 23 Mar 2015 10:47:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr508111iod.11.1427132852012; Mon, 23 Mar 2015 10:47:32 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Mon, 23 Mar 2015 10:47:31 -0700 (PDT) In-Reply-To: References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@localhost> Date: Mon, 23 Mar 2015 12:47:31 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:47:34 -0000 On Mon, Mar 23, 2015 at 12:41 PM, Eric Rescorla wrote: >> > Maybe I wasn't clear. When I said "reject" I meant "hard-fail" rather >> > than >> > make it 1-RTT. >> >> Sorry it wasn't clear to me. Is there any reason that fallback to 1-RTT >> is not feasible? > > > Yes. The issue is that the client has no way of knowing whether the 0-RTT > message was duplicated and processed by a separate server instance, so > when it falls back to 1-RTT, resending the initial data may be a replay. The server can certainly indicate what, if any 0-RTT, it received (by sending a hash back). If it did not receive the 0-RTT data then the client can fail (TLS over TCP) or retransmit (DTLS over UDP or similar). If the server received the wrong 0-RTT data then the client can fail and/or sound the alarms, or even retransmit if the data was inconsequential (e.g., a SASL mechanism negotiation, which can then be redone). Nico -- From nobody Mon Mar 23 10:56: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 4B9561AD05B for ; Mon, 23 Mar 2015 10:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHIiYO_O7OjA for ; Mon, 23 Mar 2015 10:56:21 -0700 (PDT) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 199941AD070 for ; Mon, 23 Mar 2015 10:56:05 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id EEFF33A1C7 for ; Mon, 23 Mar 2015 13:55:37 -0400 (EDT) Received: by qgfa8 with SMTP id a8so157139420qgf.0 for ; Mon, 23 Mar 2015 10:55:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.31.97 with SMTP id f94mr1032297qkf.10.1427133315943; Mon, 23 Mar 2015 10:55:15 -0700 (PDT) Received: by 10.140.104.115 with HTTP; Mon, 23 Mar 2015 10:55:15 -0700 (PDT) In-Reply-To: References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@localhost> Date: Mon, 23 Mar 2015 12:55:15 -0500 Message-ID: From: Patrick McManus Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1147ec1e58141a0511f85e1e Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:56:22 -0000 --001a1147ec1e58141a0511f85e1e Content-Type: text/plain; charset=UTF-8 It seems to me this is strongly analogous to how applications need to deal with tcp fast open. And indeed, only applications strongly motivated to need low latency embrace its complexity. The tact with TFO is basically that any data sent with the fast open has to be tolerant to replay. I like the proposed refinement here, what I perceive of as #3, that the stack does not replay it (sacrificing reliability). That seems both like less of a footgun, and gives a chance for a little more application flexibility on how to handle the exception. --001a1147ec1e58141a0511f85e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems to me this is strongly analogous to how= applications need to deal with tcp fast open. And indeed, only application= s strongly motivated to need low latency embrace its complexity.

The tact with TFO is basically that any data sent with the fast open has= to be tolerant to replay.

I like the proposed refinement here= , what I perceive of as #3, that the stack does not replay it (sacrificing = reliability). That seems both like less of a footgun, and gives a chance fo= r a little more application flexibility on how to handle the exception.
=

--001a1147ec1e58141a0511f85e1e-- From nobody Mon Mar 23 10:59: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 C01611ACF5D for ; Mon, 23 Mar 2015 10:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r186S_pBu2fi for ; Mon, 23 Mar 2015 10:59:46 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 C65161AD064 for ; Mon, 23 Mar 2015 10:59:45 -0700 (PDT) Received: by qgf74 with SMTP id 74so31085239qgf.2 for ; Mon, 23 Mar 2015 10:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=KY8d19HzZF0Etw7GtXacaQR8SrXVFYUdx6tyb9S+atg=; b=ccISuQzv4EBW8dZiS8W2bu4knXC3p6xRwRkaeJVrw213NBjGf1cXWwLTGYo1gvFH26 S6T2E84hMVRZlsXDP4FA9/lW2UcdCMyB9nkM+tCByb4fNXnZuPoCYQRRGy1sISfPw16C /u7hpVCuL4blR1rpkCVEIjtC3wqCtUG2lkANF+lVOeKDOnnwDlYrboYoK+vD3Bn+U6ZH dOrNXTp4cQTwDFrMb1l4PJP5t4PXHiB78dV3oWLhsSG1HXKDghY68m+ttvLp6ACdqor1 i+sWLsJ4MG3uljr8e333r9o0d0lrdKSg0leQtSBDzgVnPyTJa2itNPD5cht3wTUp5BZg SgnQ== X-Received: by 10.55.53.85 with SMTP id c82mr712415qka.45.1427133561097; Mon, 23 Mar 2015 10:59:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id j66sm968680qgf.25.2015.03.23.10.59.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 10:59:20 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" , Eric Rescorla Date: Mon, 23 Mar 2015 13:59:19 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201503231359.19484.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:59:47 -0000 At this point in the discussion, it might be a good idea to fork the currently proposed Early Data extension. Instead of one general box, have two specialized boxes. The first would be an Early Handshake Data extension and would be explicitly limited to handshake messages. The second would be an Early Idempotent Application Data extension and would be explicitly limited to application data messages that must be safe and idempotent. The purpose of this is to reduce consideration of early data as a generic mechanism without specific considerations needed for proper usage. Servers that wish to refuse the latter could do so more easily. Dave From nobody Mon Mar 23 11:05: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 B447A1AD09F for ; Mon, 23 Mar 2015 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwc5NAXqx2ev for ; Mon, 23 Mar 2015 11:05:48 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 8C4B11AD069 for ; Mon, 23 Mar 2015 11:05:48 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so129335993obc.0 for ; Mon, 23 Mar 2015 11:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BE3LbgWKmNkDWDwmZ6IDfe07e4vbEdci07sEXxSkrDk=; b=m0dgvNI5lRlXyBr73r9uTWMTZhUyLCXit+4tEHVwLnIDAdRXypGpWFc5hru1dH0Hx9 M/1us+syDjO7EzD3OP2uvXCcbtMkSzPOsUO9Fw5IZxUQcrCSZ5FJ94P2PbMSgkHnD8O3 SVL+HEqSmGeAdPV1yuOsxTv/UhcW85l/PlJuDROT8IUDNScKD6H1jVV1nNhKClT/ZhjL dIAzqBpLG0g/vIYxt7R5gq+yEa9JmZQ6vkRjNRowHSQ8b8FpfAIqL/qYM0doqyEJiA/N y1M7Wp9l6eweMEzwSayJwrIeny/dAWG3+E25zL9tsflyqvbqCL02wTMR4wi34gHwJF04 XHaA== MIME-Version: 1.0 X-Received: by 10.60.129.161 with SMTP id nx1mr239292oeb.77.1427133948041; Mon, 23 Mar 2015 11:05:48 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 11:05:47 -0700 (PDT) In-Reply-To: References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@localhost> Date: Mon, 23 Mar 2015 11:05:47 -0700 Message-ID: From: Martin Thomson To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:05:49 -0000 On 23 March 2015 at 10:55, Patrick McManus wrote: > I like the proposed refinement here, what I perceive of as #3, that the > stack does not replay it (sacrificing reliability). That seems both like > less of a footgun, and gives a chance for a little more application > flexibility on how to handle the exception. I get the sense from the discussion that people have different takes on #2 and #3. Do we really need to decide here? Can we offer TLS APIs the choice? Some might even choose to implement both models and kick the can even further down the road. I don't actually see any problem with that. From nobody Mon Mar 23 11:13: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 7CE8A1AD0C3 for ; Mon, 23 Mar 2015 11:13: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 i1_nIZczdUjX for ; Mon, 23 Mar 2015 11:13:39 -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 CD8EB1AD0C8 for ; Mon, 23 Mar 2015 11:13:38 -0700 (PDT) Received: by wixw10 with SMTP id w10so71091847wix.0 for ; Mon, 23 Mar 2015 11:13:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8911NthcTYWVIfgLVLvMBdn4P0almBcquyuv11w7LkY=; b=lgoyhraHv972i4v8DCOG9/uMBIu3Z5/lnwc0J3b2Jau6tLvh+aFNv8l0sQ4Wu0m2R/ DeDheVoGC/8pUPaPaieM5j5sfZlqF13TKpts0yR5SOrLN9w8lMfBiQbmCilK/tMJDYfa FamEsbcHE8PzBGnecHPiNIWLyuKHvrrgk/1wsuUR5UprYU/+cnfxiAtEAh9IsTnp0vL8 tYM2Y9n62SGJiopWoVzA08Ds3fDNBtcFxrnR/vikt6AM2u5QWTlOjAHQ8Lwifc4L6lVO 4mFOpPzcq838B3JNbPUMp0lLZuuCBjAJEsoTDA/gDKReq9jRTXr9BAR4nyyC6RvxbHN2 P1Ow== X-Gm-Message-State: ALoCoQmWry5QPdQTiqujXHh1KdFmLYNa8Qocmt0kO6ToXXkHRmyls3mEB7YPOooGhz49GXlF8KLU X-Received: by 10.180.106.68 with SMTP id gs4mr21672685wib.39.1427134417565; Mon, 23 Mar 2015 11:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 11:12:57 -0700 (PDT) In-Reply-To: References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@localhost> From: Eric Rescorla Date: Mon, 23 Mar 2015 13:12:57 -0500 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=f46d04451a110194430511f8a0cd Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:13:49 -0000 --f46d04451a110194430511f8a0cd Content-Type: text/plain; charset=UTF-8 If I can refer you back to the diagrams I provided in my e-mail, I think you'll see that this doesn't help. The issue is that the first time that the client's data is handled there is *no* feedback from the server to the client, so nothing that the server says is going to help. -Ekr On Mon, Mar 23, 2015 at 12:47 PM, Nico Williams wrote: > On Mon, Mar 23, 2015 at 12:41 PM, Eric Rescorla wrote: > >> > Maybe I wasn't clear. When I said "reject" I meant "hard-fail" rather > >> > than > >> > make it 1-RTT. > >> > >> Sorry it wasn't clear to me. Is there any reason that fallback to 1-RTT > >> is not feasible? > > > > > > Yes. The issue is that the client has no way of knowing whether the 0-RTT > > message was duplicated and processed by a separate server instance, so > > when it falls back to 1-RTT, resending the initial data may be a replay. > > The server can certainly indicate what, if any 0-RTT, it received (by > sending a hash back). If it did not receive the 0-RTT data then the > client can fail (TLS over TCP) or retransmit (DTLS over UDP or > similar). If the server received the wrong 0-RTT data then the client > can fail and/or sound the alarms, or even retransmit if the data was > inconsequential (e.g., a SASL mechanism negotiation, which can then be > redone). > > Nico > -- > --f46d04451a110194430511f8a0cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I can refer you back to the diagrams I provided in my e= -mail, I think you'll
see that this doesn't help. The issue is = that the first time that the client's
data is handled there i= s *no* feedback from the server to the client, so nothing
that th= e server says is going to help.

-Ekr
=

O= n Mon, Mar 23, 2015 at 12:47 PM, Nico Williams <nico@cryptonector.com<= /a>> wrote:
On= Mon, Mar 23, 2015 at 12:41 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> > Maybe I wasn't clear. When I said "reject" I me= ant "hard-fail" rather
>> > than
>> > make it 1-RTT.
>>
>> Sorry it wasn't clear to me.=C2=A0 Is there any reason that fa= llback to 1-RTT
>> is not feasible?
>
>
> Yes. The issue is that the client has no way of knowing whether the 0-= RTT
> message was duplicated and processed by a separate server instance, so=
> when it falls back to 1-RTT, resending the initial data may be a repla= y.

The server can certainly indicate what, if any 0-RTT, it received (b= y
sending a hash back).=C2=A0 If it did not receive the 0-RTT data then the client can fail (TLS over TCP) or retransmit (DTLS over UDP or
similar).=C2=A0 If the server received the wrong 0-RTT data then the client=
can fail and/or sound the alarms, or even retransmit if the data was
inconsequential (e.g., a SASL mechanism negotiation, which can then be
redone).

Nico
--

--f46d04451a110194430511f8a0cd-- From nobody Mon Mar 23 11:16: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 0F21F1ACED0 for ; Mon, 23 Mar 2015 11:16: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 SDVAW9o_0K8m for ; Mon, 23 Mar 2015 11:16:48 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.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 7562A1AD0A7 for ; Mon, 23 Mar 2015 11:16:48 -0700 (PDT) Received: by wetk59 with SMTP id k59so144824828wet.3 for ; Mon, 23 Mar 2015 11:16: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=zEdOYfCYW08nIQVdQEA+z0bFWUU6IjNEB1qts3mM2h4=; b=NC/1dMf+iw3mjLI8rS2DHGdUwiQW1nEpQHGBe29LaNK+lestqjC3Ic4dOZvkBuhlNH kdo/nWOPkxxavfilhJWnOaQtldcPx7FdT4FyhRYA4OdL+m2dSB/3oBtJzDt6xrp+mN2+ AaQZ9u/xhDdkB9XFoulCscyR8bG07ybVSd4D3s13BVYldB0en7vLYUyCUJEiB0y3nXOI THqoA8KXCZuYqUZtAA5r2ZrUjezoRwjKrNYJkBTU/Ad8LTTaB3K+A49UDlkFuN7iNqkI HD8v621vDpAPK7UB73daWAOH2JWBTGiU/BMv1pOhro16bmYU8oIdPAwJADM4CBNUDSWA uRvQ== X-Gm-Message-State: ALoCoQld0lOqGyiOtwr4E0xpr1LwUK+ioPqRYeuNlRXklI2wK5XcAByizRsNWYEbIIHm2hSOqHyu X-Received: by 10.194.191.228 with SMTP id hb4mr778219wjc.116.1427134607207; Mon, 23 Mar 2015 11:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 11:16:07 -0700 (PDT) In-Reply-To: <201503231359.19484.davemgarrett@gmail.com> References: <201503231359.19484.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 23 Mar 2015 13:16:07 -0500 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b8750be4f49cc0511f8ab58 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:16:50 -0000 --047d7b8750be4f49cc0511f8ab58 Content-Type: text/plain; charset=UTF-8 Dave, Thanks for raising this. In the interim I actually proposed ditching Early Data and pushing ClientKeyShare into the ClientHello directly and having the rest of the data go directly on the wire as TLS records, so I think this is generally a good idea. The idea here is that clients will never send unsolicited Replayable/Idempotent data to naive servers, and that servers which indicate support for 0-RTT must be able to at least tolerate these messages and fall back to 1-RTT. -Ekr On Mon, Mar 23, 2015 at 12:59 PM, Dave Garrett wrote: > At this point in the discussion, it might be a good idea to fork the > currently proposed Early Data extension. Instead of one general box, have > two specialized boxes. The first would be an Early Handshake Data extension > and would be explicitly limited to handshake messages. The second would be > an Early Idempotent Application Data extension and would be explicitly > limited to application data messages that must be safe and idempotent. The > purpose of this is to reduce consideration of early data as a generic > mechanism without specific considerations needed for proper usage. Servers > that wish to refuse the latter could do so more easily. > > > Dave > --047d7b8750be4f49cc0511f8ab58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave,

Thanks for raising thi= s. In the interim I actually proposed ditching
Early Data and pus= hing ClientKeyShare into the ClientHello directly
and having the = rest of the data go directly on the wire as TLS records,
so I thi= nk this is generally a good idea.

The idea here is= that clients will never send unsolicited Replayable/Idempotent
d= ata to naive servers, and that servers which indicate support for 0-RTT
must be able to at least tolerate these messages and fall back to
1-RTT.

-Ekr

=


On Mon, Mar 23, 2015 at 12:59 PM, Dave Garrett <d= avemgarrett@gmail.com> wrote:
At this point in the discussion, it might be a good idea to fork the cur= rently proposed Early Data extension. Instead of one general box, have two = specialized boxes. The first would be an Early Handshake Data extension and= would be explicitly limited to handshake messages. The second would be an = Early Idempotent Application Data extension and would be explicitly limited= to application data messages that must be safe and idempotent. The purpose= of this is to reduce consideration of early data as a generic mechanism wi= thout specific considerations needed for proper usage. Servers that wish to= refuse the latter could do so more easily.


Dave

--047d7b8750be4f49cc0511f8ab58-- From nobody Mon Mar 23 11: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 E541C1AD1D5 for ; Mon, 23 Mar 2015 11:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.497 X-Spam-Level: ** X-Spam-Status: No, score=2.497 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 2xryu193_18f for ; Mon, 23 Mar 2015 11:39:47 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id A89A71AD2AF for ; Mon, 23 Mar 2015 11:39:47 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id t2NIdkgq008845 for ; Tue, 24 Mar 2015 03:39:46 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id t2NIdkQJ023643 for tls@ietf.org; Tue, 24 Mar 2015 03:39:46 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id DAA23642; Tue, 24 Mar 2015 03:39:46 +0900 Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id t2NIdjjG029851 for ; Tue, 24 Mar 2015 03:39:45 +0900 Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id t2NIdjOR005983 for ; Tue, 24 Mar 2015 03:39:45 +0900 Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id t2NIdjWn005980 for ; Tue, 24 Mar 2015 03:39:45 +0900 Message-ID: <551059B3.1020604@po.ntts.co.jp> Date: Tue, 24 Mar 2015 03:21:39 +0900 From: KATO Akihiro User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Archived-At: Subject: [TLS] Comments on tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:39:49 -0000 Hi All$B!%(B I will comment TLS 1.3 MTI. I'm holding the following points of view. (a) To be avoided Single points of failure, (b) If possible, back up algorithm suitable for low spec system, (c) Second point algorithm developed by different concept. > o Symmetric: > MUST AES-GCM 128 > [SHOULD ChaCha20-Poly1305] I have no objection, it is AES-GCM is a MUST. Protocols used DTLS (fg. CoAP) can not deploy by ChaCha20, which is not second point cipher for AES. MTI will have second point block cipher using CCM. > o Hash: > MUST SHA-256 MTI will have another algorithm, but we do not have candidate. > o Signature: > MUST ECDSA P-256 > MUST RSA MUST ECDSA P-256 SHOULD RSA >From point of view (b), I wiil hold ECDSA P-256. RSA move to SHOULD. Regards. From nobody Mon Mar 23 11:50: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 3E5AA1AD34E for ; Mon, 23 Mar 2015 11:50: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 FEQAduqQW3bF for ; Mon, 23 Mar 2015 11:49:58 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.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 A73911AD34C for ; Mon, 23 Mar 2015 11:49:57 -0700 (PDT) Received: by wgdm6 with SMTP id m6so153442668wgd.2 for ; Mon, 23 Mar 2015 11:49:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7CBZUvLqf7s/izIIcghrvsTBxuxFZE2okQ5tB0omkco=; b=WA3Rs+8h5yArNVTG68W3KFKyGNlFZmU8I8GIdkoSO7uiH0D/xtVtzHNh8KpT42xMCl 6uq9oE/NwcoXG/rrGUhjAvgE2lH4oyuY/7Vi8WT0LR1hrO3sXbnICpJb4Epby7wOzCbD ViK/KxnmVD5lw6FLT+HMQqRbrvEjewAntBkd+Nv4kTLurx9xXwIWXBGmecfpXPcE4OIJ dSuSgWgamAWfSP9DY5BIn5u/Rt7LzMNoQWjdY5IeosUqXzFTAbE6u8R92dUmA743GZGo wiUb0X9BmVh8W0OaudWi6opgRrUMIqx8A8ot+ZApmIa8W+WhdlO/1Reklhw1A76WV5Ra m6Eg== X-Gm-Message-State: ALoCoQl9L+yuYRFxOGlYXbwAB3x9/Uh/iTbbVDMYelnmAGm4t5mtbbYoQPOIwW8JYBYzHNnRdDx0 X-Received: by 10.180.86.201 with SMTP id r9mr21872839wiz.56.1427136596371; Mon, 23 Mar 2015 11:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 11:49:16 -0700 (PDT) In-Reply-To: <551059B3.1020604@po.ntts.co.jp> References: <551059B3.1020604@po.ntts.co.jp> From: Eric Rescorla Date: Mon, 23 Mar 2015 13:49:16 -0500 Message-ID: To: KATO Akihiro Content-Type: multipart/alternative; boundary=f46d0442861cdf7f630511f92164 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:50:02 -0000 --f46d0442861cdf7f630511f92164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 23, 2015 at 1:21 PM, KATO Akihiro wrote: > Hi All=EF=BC=8E > > I will comment TLS 1.3 MTI. I'm holding the following points of view. > > (a) To be avoided Single points of failure, > (b) If possible, back up algorithm suitable for low spec system, > (c) Second point algorithm developed by different concept. > > > o Symmetric: > > MUST AES-GCM 128 > > [SHOULD ChaCha20-Poly1305] > > I have no objection, it is AES-GCM is a MUST. Protocols used DTLS (fg. > CoAP) can not deploy by ChaCha20, which is not second point cipher for > AES. MTI will have second point block cipher using CCM. > Why can't DTLS do ChaCha20? -Ekr > o Hash: > > MUST SHA-256 > MTI will have another algorithm, but we do not have candidate. > > > o Signature: > > MUST ECDSA P-256 > > MUST RSA > MUST ECDSA P-256 > SHOULD RSA > > >From point of view (b), I wiil hold ECDSA P-256. RSA move to SHOULD. > > Regards. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0442861cdf7f630511f92164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 23, 2015 at 1:21 PM, KATO Akihiro <kato.akihiro@p= o.ntts.co.jp> wrote:
Hi All= =EF=BC=8E

I will comment TLS 1.3 MTI. I'm holding the following points of view.
(a) To be avoided Single points of failure,
(b) If possible, back up algorithm suitable for low spec system,
(c) Second point algorithm developed by different concept.

> o Symmetric:
>=C2=A0 =C2=A0 =C2=A0MUST AES-GCM 128
>=C2=A0 =C2=A0 =C2=A0[SHOULD ChaCha20-Poly1305]

I have no objection, it is AES-GCM is a MUST. Protocols used DTLS (fg.
CoAP) can not deploy by ChaCha20, which is not second point cipher for
AES. MTI will have second point block cipher using CCM.

Why can't DTLS do ChaCha20?

-= Ekr

> o Hash:
>=C2=A0 =C2=A0 =C2=A0MUST SHA-256
MTI will have another algorithm, but we do not have candidate.

> o Signature:
>=C2=A0 =C2=A0 =C2=A0MUST ECDSA P-256
>=C2=A0 =C2=A0 =C2=A0MUST RSA
=C2=A0 =C2=A0 =C2=A0MUST ECDSA P-256
=C2=A0 =C2=A0 =C2=A0SHOULD RSA

>From point of view (b), I wiil hold ECDSA P-256. RSA move to SHOULD.
Regards.

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

--f46d0442861cdf7f630511f92164-- From nobody Mon Mar 23 11:56: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 47CEE1AD355 for ; Mon, 23 Mar 2015 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6C66xEtLM9w6 for ; Mon, 23 Mar 2015 11:56:17 -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 590FA1AD244 for ; Mon, 23 Mar 2015 11:56:17 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 19BDC69970; Mon, 23 Mar 2015 20:56:14 +0200 (EET) Date: Mon, 23 Mar 2015 20:56:14 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150323185614.GA21432@LK-Perkele-VII> References: <551059B3.1020604@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:56:20 -0000 On Mon, Mar 23, 2015 at 01:49:16PM -0500, Eric Rescorla wrote: > On Mon, Mar 23, 2015 at 1:21 PM, KATO Akihiro > wrote: > > > Hi All． > > > > I will comment TLS 1.3 MTI. I'm holding the following points of view. > > > > (a) To be avoided Single points of failure, > > (b) If possible, back up algorithm suitable for low spec system, > > (c) Second point algorithm developed by different concept. > > > > > o Symmetric: > > > MUST AES-GCM 128 > > > [SHOULD ChaCha20-Poly1305] > > > > I have no objection, it is AES-GCM is a MUST. Protocols used DTLS (fg. > > CoAP) can not deploy by ChaCha20, which is not second point cipher for > > AES. MTI will have second point block cipher using CCM. > > > > Why can't DTLS do ChaCha20? I presume KATO Akihiro meant that constrained systems can't do Chacha20, not that AEAD #29 (Chacha20-Poly1305) has any special problems with doing DTLS. -Ilari From nobody Mon Mar 23 12: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 0FCBB1B29BD for ; Mon, 23 Mar 2015 12: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 LhvSRBDT2wj9 for ; Mon, 23 Mar 2015 12:06:33 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::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 7B6F81B29FC for ; Mon, 23 Mar 2015 12:05:31 -0700 (PDT) Received: by webck51 with SMTP id ck51so19006871web.2 for ; Mon, 23 Mar 2015 12:05:30 -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=jMJVj1TGZkEcbloqGolBhsMW4LbBQ8Z4nxtePNRNb88=; b=wpER2IcuACx779BedcUJqlVRUa57z7MJx6z3LsRgmvvGhQY1KXIegxVXX/HyXUaK7w rSei2FVC9dIUrhwRQhg4LNkaWFUkdo2JmMwX5SylcptW7v25XZ8LEInVfE8xJhyCqVA5 PQjIaO74btVvFo8ZQT5xZev0q9kofWJlC37QPNLJ/EFD0/m1tFEgrbtLbXlaYE+b0Iz2 t49c5ea98Zp7c51XZmaZdhdWyG0gUF0W4GwBYOZMohhAe7ucveIvUOrw+hiwfbigLOkI wQwNddTZPBAKPqEN2qO1qG0Vn4xNOlJ4S2Eew5iu/cRRAytOIJq+j+PFdIchAfhhPQE/ GJlQ== X-Received: by 10.180.206.101 with SMTP id ln5mr22388113wic.55.1427137530297; Mon, 23 Mar 2015 12:05:30 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:145:3f20:7f79:2bf6? ([2001:67c:370:176:145:3f20:7f79:2bf6]) by mx.google.com with ESMTPSA id lb6sm2672115wjb.22.2015.03.23.12.05.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 12:05:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150323185614.GA21432@LK-Perkele-VII> Date: Mon, 23 Mar 2015 14:05:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551059B3.1020604@po.ntts.co.jp> <20150323185614.GA21432@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on tales from the TLS interim: TLS 1.3 MTI algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:06:35 -0000 > On Mar 23, 2015, at 1:56 PM, Ilari Liusvaara = wrote: >=20 > On Mon, Mar 23, 2015 at 01:49:16PM -0500, Eric Rescorla wrote: >> On Mon, Mar 23, 2015 at 1:21 PM, KATO Akihiro = >> wrote: >>=20 >>> Hi All=EF=BC=8E >>>=20 >>> I will comment TLS 1.3 MTI. I'm holding the following points of = view. >>>=20 >>> (a) To be avoided Single points of failure, >>> (b) If possible, back up algorithm suitable for low spec system, >>> (c) Second point algorithm developed by different concept. >>>=20 >>>> o Symmetric: >>>> MUST AES-GCM 128 >>>> [SHOULD ChaCha20-Poly1305] >>>=20 >>> I have no objection, it is AES-GCM is a MUST. Protocols used DTLS = (fg. >>> CoAP) can not deploy by ChaCha20, which is not second point cipher = for >>> AES. MTI will have second point block cipher using CCM. >>>=20 >>=20 >> Why can't DTLS do ChaCha20? >=20 > I presume KATO Akihiro meant that constrained systems can't do = Chacha20, > not that AEAD #29 (Chacha20-Poly1305) has any special problems with > doing DTLS. I don=E2=80=99t know why that would be true. The state for ChaCha20 is = 64 bytes (16 32-bit integers) with Poly1305 probably rounding it up to a = little over 80, and only about 32 of those need to be kept between = packets. AES-GCM requires an expanded key and ghash table that total = over 800 bytes. The code for both ChaCha and Poly is small enough for = even the most constrained systems. Of course if you anyway have the = AES-GCM code, the ChaCha code is extra, but I don=E2=80=99t think it=E2=80= =99s a big issue for even the 20 KB class of device. Yoav= From nobody Mon Mar 23 12:22: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 599FF1A079D for ; Mon, 23 Mar 2015 12:22:49 -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 xMrCs-V9ynZy for ; Mon, 23 Mar 2015 12:22:45 -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 B697A1B29D8 for ; Mon, 23 Mar 2015 12:22:37 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so15652686lbc.0 for ; Mon, 23 Mar 2015 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CovSjXHazM3jA7jd/o/Yh4qOimE9GT1PgGSIV9LrJ6o=; b=FMReI1JKwGdHyescABWpk46QdkEDNg0cXJpwxHCPQZJlmyU+L0YKxRo8KwK83XbiSh SgV0kkteeq8mEjnKqXy7C8RrlZXcDNLeBsWQiB5db4ZTntJqwM+u28DEp8fbboc0wXqp oPipvHrFuRbcqjMIEF1i8oIYvOdHa+pYll45/VXMIQN6XUsmg2ZCN6649WzckkhLJyfG +V0cK152dwF5eHRJBgJPjTFg/Cveap3IDMMSRW6xiAWLplWhKgI1vxFxzTi8kK2lHKoK /NqUalkQ9ax31rg0BTSriA6XO5ApaGr7iSixAIPv98+NwYWQdm0Y4QW6kByEXtrxsQxa j5FQ== X-Received: by 10.152.27.39 with SMTP id q7mr498747lag.49.1427138556227; Mon, 23 Mar 2015 12:22:36 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Mon, 23 Mar 2015 12:22:05 -0700 (PDT) In-Reply-To: <1427123147.19595.62.camel@redhat.com> References: <1427123147.19595.62.camel@redhat.com> From: Hugo Krawczyk Date: Mon, 23 Mar 2015 15:22:05 -0400 X-Google-Sender-Auth: 1_Gsizr4lIPLpsNuON3L56jeLP4 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=089e0160aca4b0774d0511f99619 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:22:49 -0000 --089e0160aca4b0774d0511f99619 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nikos, These are good questions - see responses below. On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote: > > Folks, > > At the interim discussed transitioning to a DH-based handshake (rather > > than a signature-based one) like that proposed by Hugo Krawczyk and > > Hoeteck Wee. The major rationale for this change is that any 0-RTT > > mode is inherently DH-based and so if we make that our basic mode, > > then we can simplify the protocol logic and key derivation model. This > > model also allows us to pull in PSK modes under the same basic > > structure. > [...] > > The WG sentiment was generally favorable to exploring this avenue but > > there was also airly strong WG sentiment that we didn't presently want > > to do an offline signatures. This leaves with a model in which the > > client initially learns the server's semi-static DH share through > > an online-signed 1-RTT handshake but then can cache it for use with > > future connections. > > Wasn't that discussed in the list before? My impression was that the > outcome of that discussion was not to add that. > =E2=80=8BThe objections to the original proposal were related to the use of= offline signatures to sign a semi-static DH key. This is not an option in ekr's draft. Neither the draft accommodates DH certificates. All server's authentication is based on regular (online) TLS signatures except if the client has cached a semi-static key from the server as needed to support 0-RTT. In the latte case authentication must be done via the possession of the semi-static DH secret by the server (a 0-RTT flow cannot be authenticated via signatures). =E2=80=8B > > Anyway, a first question that comes to mind, is why this isn't defined > as separate ciphersuites? Why does it even have to be TLS 1.3 related? > Static DH parameters is an experiment that failed years ago. What has > changed since then that we believe now it is going to work? You even > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B - Forward secrecy (PFS) is now mandatory. - The protocol accommodate a 0-RTT mode. These two changes can only be implemented via Diffie-Hellman transforms (in theory, any CCA-secure public key encryption can be used but (EC)DH is the only currently practical instantiation in this setting). In particular, 0-RTT requires supporting semi-static DH keys for the server. All that ekr draft does is to build a protocol where PFS is supported, 0-RTT is supported, semi-static keys are supported, and TLS-type signatures are supported in any case where the client does not have a cached semi-static key of the server. The beauty of it, if I can say so, is that all these modes are just subsets of a single protocol with a single crypto logic and uniform specification (which also covers uniformly PSK and resumption). The alternative is to keep TLS 1.2 and add to it the semi-static case as a patch, hence requiring essentially implementing all that is now in ekr's draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the cryptographic analysis point of view this would mean analyzing two separate protocols as well as making sure these two protocols do not have any bad interaction when put together. =E2=80=8B > dropped the static DH ciphersuites from TLS 1.3. Please make that part > optional so you don't doom the whole TLS 1.3 protocol enhancements if > no-one switches to static DH keys (in the document they are described as > semi-static DH keys - but there is no definition of what that means). > > A second question is why HKDF? Why is it even there? Is there any issue > with the current TLS PRF and we need another? Is there a valid reason to > bloat implementations with shipping multiple KDFs? This kind of changes > shouldn't be done without thought, as it is now there cannot be any code > sharing between TLS 1.2 and 1.3 and we risk having implementers stay > with TLS 1.2 for the next decade. > =E2=80=8BHKDF is just a way of structuring the use of TLS PRF (HMAC-PRF) in= a way that supports a uniform, hierarchical key derivation scheme which is common to all the modes of the protocol as discussed above (including PSK, Export, resumption, etc.) and which accommodates deriving keys from possibly non-uniform secrets such as DH values, passphrases, etc. In particular, it sets no requirements or assumptions in the form of the secret/entropy source from which keys are derived, hence freeing the protocol instantiation from things like point representation in an elliptic curve (it will work with compressed representation, uncompressed ones, etc). I believe these are all huge benefits at all levels: design, analysis, specification, implementation, maintenance of the protocol (future changes/additions). I cannot comment on code sharing though, although I hope we do not ruin the future by tying ourselves too much to the past. Hugo =E2=80=8B > > regards, > Nikos > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --089e0160aca4b0774d0511f99619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nikos,

These are goo= d questions - see responses below.

=
On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogia= nnopoulos <nmav@redhat.com> wrote:
On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla = wrote:
> Folks,
> At the interim discussed transitioning to a DH-based handshake (rather=
> than a signature-based one) like that proposed by Hugo Krawczyk and > Hoeteck Wee. The major rationale for this change is that any 0-RTT
> mode is inherently DH-based and so if we make that our basic mode,
> then we can simplify the protocol logic and key derivation model. This=
> model also allows us to pull in PSK modes under the same basic
> structure.
[...]
> The WG sentiment was generally favorable to exploring= this avenue but
> there was also airly strong WG sentiment that we didn't presently = want
> to do an offline signatures. This leaves with a model in which the
> client initially learns the server's semi-static DH share through<= br> > an online-signed 1-RTT handshake but then can cache it for use with > future connections.

Wasn't that discussed in the list before? My impression was that= the
outcome of that discussion was not to add that.

=E2=80=8BThe objections to the original proposal we= re related to the use of offline signatures to sign a semi-static DH key. T= his is not an option in ekr's draft. Neither the draft accommodates DH = certificates. All server's authentication is based on regular (online) = TLS signatures except if the client has cached a semi-static key from the s= erver as needed to support 0-RTT. In the latte case authentication must be = done via the possession of the semi-static DH secret by the server (a 0-RTT= flow cannot be authenticated via signatures).
=E2=80=8B
=C2=A0

Anyway, a first question that comes to mind, is why this isn't defined<= br> as separate ciphersuites? Why does it even have to be TLS 1.3 related?
Static DH parameters is an experiment that failed years ago. What has
changed since then that we believe now it is going to work? You even

=E2=80=8BTwo important things change in TLS 1= .3:=E2=80=8B
- Forward secrecy (PFS) is now = mandatory.
- The protocol accommodate a = 0-RTT mode.

These two changes can on= ly be implemented via Diffie-Hellman transforms (in theory, any CCA-secure = public key encryption can be used but (EC)DH is the only currently practica= l instantiation in this setting). In particular, 0-RTT requires supporting = semi-static DH keys for the server. All that ekr draft does is to build a p= rotocol where PFS is supported, 0-RTT is supported, semi-static keys are su= pported, and TLS-type signatures are supported in any case where the client= does not have a cached semi-static key of the server. The beauty of it, if= I can say so, is that all these modes are just subsets of a single protoco= l with a single crypto logic and uniform specification (which also covers u= niformly PSK and resumption).

The al= ternative is to keep TLS 1.2 and add to it the semi-static case as a patch,= hence requiring essentially implementing all that is now in ekr's draf= t (for PFS and 0-RTT) plus all the mechanics of 1.2. From the cryptographic= analysis point of view this would mean analyzing two separate protocols as= well as making sure these two protocols do not have any bad interaction wh= en put together.

=E2=80=8B
=C2=A0
dropped the static DH ciphersuites from TLS 1.3. Please make that part
optional so you don't doom the whole TLS 1.3 protocol enhancements if no-one switches to static DH keys (in the document they are described as semi-static DH keys - but there is no definition of what that means).

A second question is why HKDF? Why is it even there? Is there any issue
with the current TLS PRF and we need another? Is there a valid reason to bloat implementations with shipping multiple KDFs? This kind of changes
shouldn't be done without thought, as it is now there cannot be any cod= e
sharing between TLS 1.2 and 1.3 and we risk having implementers stay
with TLS 1.2 for the next decade.

=E2=80=8BHKDF is just a way of structuring the use of TLS PRF (HM= AC-PRF) in a way that supports a uniform, hierarchical key derivation schem= e which is common to all the modes of the protocol as discussed above (incl= uding PSK, Export, resumption, etc.) and which accommodates deriving keys f= rom possibly non-uniform secrets such as DH values, passphrases, etc. In pa= rticular, it sets no requirements or assumptions in the form of the secret/= entropy source from which keys are derived, hence freeing the protocol inst= antiation from things like point representation in an elliptic curve (it wi= ll work with compressed representation, uncompressed ones, etc).

I believe these are all huge benefits at all l= evels: design, analysis, specification, implementation, maintenance of the = protocol (future changes/additions). I cannot comment on code sharing thoug= h, although I hope we do not ruin the future by tying ourselves too much to= the past.

Hugo
=E2=80=8B
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
regards,
Nikos



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

--089e0160aca4b0774d0511f99619-- From nobody Mon Mar 23 12:30: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 E62001B29AC for ; Mon, 23 Mar 2015 12:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4dlNCangOqC for ; Mon, 23 Mar 2015 12:30:30 -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 4F6DF1B29A7 for ; Mon, 23 Mar 2015 12:30:30 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 2B2381612; Mon, 23 Mar 2015 12:30:30 -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=qkpiSAKiwQ9MiP Av9cxwNVneURA=; b=HqbqLSc2yc2jnkQFYiwrjjpJdaDY7Rp856jKfnEojc0nuv JynpBJkim+xkFzDRbofvfn6PAiUhGmIR3IgOxPfMLCzkYDCQsdS4fHtkIrL22NUn M3Slu5q6VxTAeBDiq5Xc7wO6Y82qdY04mMrK0KOpq0SvFBLWh0z/8YZ3HATHo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 76ADC163B; Mon, 23 Mar 2015 12:30:29 -0700 (PDT) Date: Mon, 23 Mar 2015 14:29:36 -0500 From: Nico Williams To: Eric Rescorla Message-ID: <20150323192935.GR21267@localhost> References: <20150323084716.GM21267@localhost> <20150323171955.GP21267@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] 0-RTT and Anti-Replay X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:30:31 -0000 On Mon, Mar 23, 2015 at 01:12:57PM -0500, Eric Rescorla wrote: > If I can refer you back to the diagrams I provided in my e-mail, I > think you'll see that this doesn't help. The issue is that the first > time that the client's data is handled there is *no* feedback from the > server to the client, so nothing that the server says is going to > help. Indeed. If the server ever responds to the client (for that connection), then there is feedback, but such feedback is too late, and might never arrive (the client application times out, maybe retries). Therefore such feedback must not be security-critical, which means that the data sent must be more than idempotent: it must yield no meaningful side-effects on the server-side. Again, optimizing something like a SASL mechanism negotiation, "open INBOX" (but not "open my-secret-design-for-xyz") -- that's fine. Optimizing arbitrary application protocols this way is not. This is really a security consideration, but it should come with API design advice (since TLS lacks an abstract API). Nico -- From nobody Mon Mar 23 12:31: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 AC76B1B29AC for ; Mon, 23 Mar 2015 12:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa65Gwfmdyco for ; Mon, 23 Mar 2015 12:31:54 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCF61B29A6 for ; Mon, 23 Mar 2015 12:31:54 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 867E99A400F for ; Mon, 23 Mar 2015 15:31:43 -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 KHZT9+hgI2nP for ; Mon, 23 Mar 2015 15:31:22 -0400 (EDT) Received: from dhcp-88c7.meeting.ietf.org (dhcp-88c7.meeting.ietf.org [31.133.136.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 709019A400D for ; Mon, 23 Mar 2015 15:31:22 -0400 (EDT) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-39-7789023 Date: Mon, 23 Mar 2015 15:31:11 -0400 In-Reply-To: To: IETF TLS References: Message-Id: <493A881F-9A1A-4AF7-A55F-85AC98D60F90@vigilsec.com> X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:31:55 -0000 --Apple-Mail-39-7789023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen wrote: On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla wrote: > During the interim we discussed discussion about adopting PSS for > RSA signatures in TLS 1.3. > > Clearly, we will not be able to just adopt PSS because certificates > will continue to be signed with PKCS#1 1.5. I would like to see TLS 1.3 allow certificates signed using PSS (RFC 4055 and 3447) and provide a way to signal the server that such certificates are supported.=20 I have wanted to see migration of signatures on certificates from PKCS#1 = v1.5 to PSS for many years. I think this is a nice step for that to = happen. That said, I'd like to see this done in a way that also encourages the = transition to ECDSA for the signatures on the certificates. So, I think = that means the suggested signaling needs to provide a list of = certificate signature algorithms that are supported, with a clear = mandatory to implement. Russ --Apple-Mail-39-7789023 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen <pzbowen@gmail.com> wrote:
On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> During the interim we discussed discussion about adopting PSS for
> RSA signatures in TLS 1.3.
>
> Clearly, we will not be able to just adopt PSS because certificates
> will continue to be signed with PKCS#1 1.5.

I would like to see TLS 1.3 allow certificates signed using PSS (RFC
4055 and 3447) and provide a way to signal the server that such
certificates are supported. 

I have wanted to see migration of signatures on certificates from PKCS#1 v1.5 to PSS for many years.  I think this is a nice step for that to happen.

That said, I'd like to see this done in a way that also encourages the transition to ECDSA for the signatures on the certificates.  So, I think that means the suggested signaling needs to provide a list of certificate signature algorithms that are supported, with a clear mandatory to implement.

Russ

--Apple-Mail-39-7789023-- From nobody Mon Mar 23 12:34: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 9E7151B29C6 for ; Mon, 23 Mar 2015 12:34:54 -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 Pe4acu33q2lY for ; Mon, 23 Mar 2015 12:34:53 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 959951B29DB for ; Mon, 23 Mar 2015 12:34:52 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3D0499A4012 for ; Mon, 23 Mar 2015 15:34:42 -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 fFd83njXVIlP for ; Mon, 23 Mar 2015 15:34:21 -0400 (EDT) Received: from dhcp-88c7.meeting.ietf.org (dhcp-88c7.meeting.ietf.org [31.133.136.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 6EC6C9A400F for ; Mon, 23 Mar 2015 15:34:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: <20150323112232.5964828b@pc1.fritz.box> Date: Mon, 23 Mar 2015 15:34:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150323112232.5964828b@pc1.fritz.box> To: IETF TLS X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:34:54 -0000 > I think this totally makes sense. I think we should see Signatures for = PKI > separately that for TLS (i.e. signing certificates versus signing = handshakes). > Pushing PKI to support PSS can be done separately, but it is probably = much > more difficult due to backwards compatibility issues. > But it doesn't need to happen inside the TLS 1.3 specification. > (and the tech / spec for doing so is already available) We want to accomodate the uptake of ECC, so ... If RSA keys, then sign handshake with RSA-PSS. If ECC keys, then sign handshake with ECDSA. Russ From nobody Mon Mar 23 12:42: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 AB1701A012D for ; Mon, 23 Mar 2015 12:42:49 -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 3EQYe6Sx2oGq for ; Mon, 23 Mar 2015 12:42:47 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0661.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::661]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C521A0242 for ; Mon, 23 Mar 2015 12:42:46 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 23 Mar 2015 19:42:26 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.021; Mon, 23 Mar 2015 19:42:26 +0000 From: "Paterson, Kenny" To: Russ Housley , IETF TLS Thread-Topic: [TLS] PSS for TLS 1.3 Thread-Index: AQHQZO0BzEWOClerrUGv/b0kfZLJhZ0p3LEAgACaIAD//650AA== Date: Mon, 23 Mar 2015 19:42:26 +0000 Message-ID: References: <20150323112232.5964828b@pc1.fritz.box> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [31.133.156.77] authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(479174004)(19580405001)(66066001)(19580395003)(36756003)(2900100001)(50986999)(76176999)(77156002)(62966003)(54356999)(15975445007)(106116001)(2950100001)(77096005)(122556002)(40100003)(46102003)(74482002)(2656002)(83506001)(92566002)(86362001)(102836002)(107886001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB384; x-forefront-prvs: 05245CA661 Content-Type: text/plain; charset="us-ascii" Content-ID: <6A785F1502ADAE44A4901CD0521E8C36@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2015 19:42:26.1108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384 Archived-At: Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:42:49 -0000 Hi On 23/03/2015 14:34, "Russ Housley" wrote: > >> I think this totally makes sense. I think we should see Signatures for >>PKI >> separately that for TLS (i.e. signing certificates versus signing >>handshakes). >> Pushing PKI to support PSS can be done separately, but it is probably >>much >> more difficult due to backwards compatibility issues. >> But it doesn't need to happen inside the TLS 1.3 specification. >> (and the tech / spec for doing so is already available) > >We want to accomodate the uptake of ECC, so ... > >If RSA keys, then sign handshake with RSA-PSS. >If ECC keys, then sign handshake with ECDSA. Just a quick heads-up with my CFRG hat on. We should soon be making a start over there on defining signature schemes for use with the curves that we have now selected; our DH deliberations are nearing completion. One quick question for this group: how important is it to you to have ECDSA - or something very close to it (e.g. a derandomised version) - for TLS use, and how much appetite is there for adopting schemes that deviate more significantly from ECDSA (e.g. EdDSA)? This question will surely be covered in forthcoming CFRG discussions as well, but I think it's useful to ask the question here too, given that TLS will be the first and primary customer for what we're working on in CFRG. Cheers Kenny > >Russ > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Mon Mar 23 13:15: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 C1A1F1B29D7 for ; Mon, 23 Mar 2015 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9qCKyuvYIGO for ; Mon, 23 Mar 2015 13:15:29 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d: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 E92FA1B29D8 for ; Mon, 23 Mar 2015 13:15:28 -0700 (PDT) Received: by qgfa8 with SMTP id a8so163500766qgf.0 for ; Mon, 23 Mar 2015 13:15: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:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=7QJR1mOm3rzZLjkHrAOraXRcVR4amL+o++WWeUNxVIM=; b=rBoyEzx4uoPNOWHetfptM+IRnglUhHA7YsBHRcsC9UEoJLE533ERH+1BJgkXxGsScG idxiDwb5sbfB78etFdqfNN+KZYYVjaqVTnsj4+k8gidxyZHaGE47ydvqokq4eZ+ItEhq pmB9WvJjIzfnHQDpOZ0yKz+r0UD5CFHiw5mQJn1x52sg18cDXJl8jexghIusu6gTyrIC 4chV6xf3/Xno+GBxwepa7GcfJyOmOx3JkYKhHViKPUKOqgrGMZE6VStGwP8nUMcJpjEn fzjHJUQvcT8tShLdunoQHNFmHlmzuA7WciE93MPaagUbsg/aBUVYvwEOOGpVQ3gqiAZk 9usA== X-Received: by 10.229.95.74 with SMTP id c10mr1343852qcn.17.1427141728268; Mon, 23 Mar 2015 13:15:28 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id b52sm1219390qgb.16.2015.03.23.13.15.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 13:15:27 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 23 Mar 2015 16:15:26 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-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: <201503231615.26528.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:15:30 -0000 On Monday, March 23, 2015 10:19:59 am Eric Rescorla wrote: > As I mentioned in a previous message [0] during the interim we discussed > moving from the TLS PRF to HKDF [RFC5869]. > > The general sentiment was: > > - Move to HKDF > - Specify both SHA-256 and SHA-384 (the latter being required for > Suite B) > > This is also the time when we would want to look at adjusting > the key expansion to separate keys and IVs (assuming we still > have IVs). > > Please use this thread to discuss this topic. > > -Ekr > > [0] https://www.ietf.org/mail-archive/web/tls/current/msg15621.html Adding support for SHA-3 hashes seems like a good idea at this point. There's also issue #26 [1] which proposed picking a one-true-hash. I also proposed a SHA2+SHA3 construct as a possible route, which was briefly discussed [2]. (construct TBD by CFRG) The basic premise of a combined hash in this instance is to provide a better guarantee of security if either SHA-2 or SHA-3 were to be broken. Any of this viable at this juncture? [1] https://github.com/tlswg/tls13-spec/issues/26 [2] https://www.ietf.org/mail-archive/web/tls/current/msg13264.html Dave From nobody Mon Mar 23 13:55: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 3FBB81A1A98 for ; Mon, 23 Mar 2015 13:55:03 -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 OdbOcdy8cNXH for ; Mon, 23 Mar 2015 13:55:01 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4411A1A92 for ; Mon, 23 Mar 2015 13:55:00 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8377481801; Mon, 23 Mar 2015 22:54:57 +0200 (EET) Date: Mon, 23 Mar 2015 22:54:57 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150323205457.GA23158@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:55:03 -0000 On Mon, Mar 23, 2015 at 03:22:05PM -0400, Hugo Krawczyk wrote: > Hi Nikos, > > These are good questions - see responses below. > > On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogiannopoulos > wrote: > > > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote: > > [...] > > > The WG sentiment was generally favorable to exploring this avenue but > > > there was also airly strong WG sentiment that we didn't presently want > > > to do an offline signatures. This leaves with a model in which the > > > client initially learns the server's semi-static DH share through > > > an online-signed 1-RTT handshake but then can cache it for use with > > > future connections. > > > > Wasn't that discussed in the list before? My impression was that the > > outcome of that discussion was not to add that. > > > > ​The objections to the original proposal were related to the use of offline > signatures to sign a semi-static DH key. This is not an option in ekr's > draft. Neither the draft accommodates DH certificates. All server's > authentication is based on regular (online) TLS signatures except if the > client has cached a semi-static key from the server as needed to support > 0-RTT. I think that is the worst case. ECC signature generation are faster than ECDH operation. But OTOH, ECDH operation is much easier to implement than ECC signature. So one gets slowdown for no simplification. Also, two-level key schemes have certain benefits, but lack of offline signing makes it one-level key scheme with two keys. > > Anyway, a first question that comes to mind, is why this isn't defined > > as separate ciphersuites? Why does it even have to be TLS 1.3 related? > > Static DH parameters is an experiment that failed years ago. What has > > changed since then that we believe now it is going to work? You even > > > > ​Two important things change in TLS 1.3:​ > - Forward secrecy (PFS) is now mandatory. > - The protocol accommodate a 0-RTT mode. > > These two changes can only be implemented via Diffie-Hellman transforms (in > theory, any CCA-secure public key encryption can be used but (EC)DH is the > only currently practical instantiation in this setting). In particular, > 0-RTT requires supporting semi-static DH keys for the server. All that ekr > draft does is to build a protocol where PFS is supported, 0-RTT is > supported, semi-static keys are supported, and TLS-type signatures are > supported in any case where the client does not have a cached semi-static > key of the server. The beauty of it, if I can say so, is that all these > modes are just subsets of a single protocol with a single crypto logic and > uniform specification (which also covers uniformly PSK and resumption). > > The alternative is to keep TLS 1.2 and add to it the semi-static case as a > patch, hence requiring essentially implementing all that is now in ekr's > draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the > cryptographic analysis point of view this would mean analyzing two separate > protocols as well as making sure these two protocols do not have any bad > interaction when put together. The simplest way to do 0RTT would be for server to signal parameters for 0RTT in extension and then client to put public keys and 0RTT data ((EC)IES) into ClientHello extension (doesn't work that well in TLS 1.2 still). Of course, that provodes absolutely no replay protection... > > dropped the static DH ciphersuites from TLS 1.3. Please make that part > > optional so you don't doom the whole TLS 1.3 protocol enhancements if > > no-one switches to static DH keys (in the document they are described as > > semi-static DH keys - but there is no definition of what that means). > > > > A second question is why HKDF? Why is it even there? Is there any issue > > with the current TLS PRF and we need another? Is there a valid reason to > > bloat implementations with shipping multiple KDFs? This kind of changes > > shouldn't be done without thought, as it is now there cannot be any code > > sharing between TLS 1.2 and 1.3 and we risk having implementers stay > > with TLS 1.2 for the next decade. > > > > ​HKDF is just a way of structuring the use of TLS PRF (HMAC-PRF) in a way > that supports a uniform, hierarchical key derivation scheme which is common > to all the modes of the protocol as discussed above (including PSK, Export, > resumption, etc.) and which accommodates deriving keys from possibly > non-uniform secrets such as DH values, passphrases, etc. In particular, it > sets no requirements or assumptions in the form of the secret/entropy > source from which keys are derived, hence freeing the protocol > instantiation from things like point representation in an elliptic curve > (it will work with compressed representation, uncompressed ones, etc). > > I believe these are all huge benefits at all levels: design, analysis, > specification, implementation, maintenance of the protocol (future > changes/additions). I cannot comment on code sharing though, although I > hope we do not ruin the future by tying ourselves too much to the past. Well, to me the key derivation in EKR draft (using HKDF) looks much more messy than the one in editor draft (using classic TLS PRF) -Ilari From nobody Mon Mar 23 14:02: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 A3DE81A1A6C for ; Mon, 23 Mar 2015 14:02: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 KD6q-7rrIDJT for ; Mon, 23 Mar 2015 14:02:17 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.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 AD63C1A1A67 for ; Mon, 23 Mar 2015 14:02:16 -0700 (PDT) Received: by wegp1 with SMTP id p1so148010249weg.1 for ; Mon, 23 Mar 2015 14:02: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:cc:content-type; bh=apUMlmpeH1SwER80qCI5m/jEhYYfZVxHkzxy29/SglE=; b=F0BuosgxKrjA6xz3oztlVzis5mGZMiL/myolMz/M2DaUIeExYSCloQ6HoVaSOIeAXw eyuGSQ29BIFBNMPWb02riToXl3/PWtnTZv3vPBw2sPcGbzbZD4AZPtkr0OjO1+OGLja9 keIQV3vZfV1fkQGyIlvxMqyu6jRttFVpRF36KsYgJ0HIV313Tp/fbFRAbV+3glhq+xVv cSfrbHD3/9leO0J+Hw/so0hwx8ShWrqtDwJtTGURq7CbxTLRySeNRw8DqkloRed/F/Au y3k3fLOkwv9AECyl0/i6v4O5mQqoEXgPBLyHTOeTsdyjltjBmBGxkczHW71B5FAFbFsY Cafg== X-Gm-Message-State: ALoCoQlLJeT0zXvtOs6Bmcyi75n1kiqN9LyfCdcCEKcy5kwLgc2SyOsI5erjNCat+FOQQ7pF+N83 X-Received: by 10.194.133.101 with SMTP id pb5mr2060657wjb.40.1427144535373; Mon, 23 Mar 2015 14:02:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 14:01:35 -0700 (PDT) In-Reply-To: <20150323205457.GA23158@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> <20150323205457.GA23158@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 23 Mar 2015 16:01:35 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e011771f31312f90511fafbc4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:02:18 -0000 --089e011771f31312f90511fafbc4 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 3:54 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > > Well, to me the key derivation in EKR draft (using HKDF) looks much more > messy than the one in editor draft (using classic TLS PRF) Note that we could certainly use the TLS PRF with this DH-based structure, I'm just trying to keep the number of branches I'm working on down to a managable structure and I had the sense from the interim that people wanted HKDF. -Ekr --089e011771f31312f90511fafbc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 23, 2015 at 3:54 PM, Ilari Liusvaara <ilari.liusvaara@e= lisanet.fi> wrote:
Well, to me = the key derivation in EKR draft (using HKDF) looks much more
messy than the one in editor draft (using classic TLS PRF)

Note that we could certainly use the TLS PRF with this DH-b= ased structure,
I'm just trying to keep the number of branche= s I'm working on down to a managable
structure and I had = the sense from the interim that people wanted HKDF.

-Ekr


--089e011771f31312f90511fafbc4-- From nobody Mon Mar 23 14:05: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 841F81A1AE3 for ; Mon, 23 Mar 2015 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKSpzLkat3ol for ; Mon, 23 Mar 2015 14:05:54 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 350331A1A6C for ; Mon, 23 Mar 2015 14:05:54 -0700 (PDT) Received: by laae1 with SMTP id e1so12364398laa.2 for ; Mon, 23 Mar 2015 14:05:52 -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:from:date:message-id :subject:to:cc:content-type; bh=rwRQ7Tqe5B1XksPQWNn34Yaoom5PGyzn7ZxYt1OQW8A=; b=ft66QNNHn7jFFRycty1zHeocWR+nPqPxaAzeacvS+672e6632sOrOqZFH/nspCxsbZ B2IBzRdvNXIDWTbVbp0lT/W4TdB9KVF5mEAKKbva/Jkd8HhVkYi7NJjeDURfFNQGsxUU h/3QbR7AVPH3RtZI5HCHN7smgOxU8vFSz/M0M1/FiLl61PBV1gW5wgESCp4eeooMezG2 DVtbd5tq5wNyvLVOgpjlWLuLcL86ekujL/urNmBymNvjcA617t6sElPT1Al3x3Gp0wRU JV1HA2vebakcj0VR1WFk2nD+gh7cLd7l3b7Wqewgtw1ZOs/mPw8fxzvSEWyjjld1zTLk jWJQ== X-Received: by 10.112.42.41 with SMTP id k9mr910292lbl.90.1427144752739; Mon, 23 Mar 2015 14:05:52 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Mon, 23 Mar 2015 14:05:22 -0700 (PDT) In-Reply-To: <20150323205457.GA23158@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> <20150323205457.GA23158@LK-Perkele-VII> From: Hugo Krawczyk Date: Mon, 23 Mar 2015 17:05:22 -0400 X-Google-Sender-Auth: BlgoCNxrEP-t5YBix1Kr1Fct5Go Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113367fc07bcb70511fb08db Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:05:57 -0000 --001a113367fc07bcb70511fb08db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 0-RTT with (EC)IES is exactly what we are doing. Keeping online signatures is what the WG wanted (the other option is offline signatures or DH certificates which had opposition). If you can come with a simplified design combining these things, I will be happy to hear. The KDF derivation scheme is as simple as it gets for all keys that need to be derived and is uniform for all modes. You could save one level of extraction if you were willing to key the prf with your DH secrets, which I do not recommend. Hugo On Mon, Mar 23, 2015 at 4:54 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Mon, Mar 23, 2015 at 03:22:05PM -0400, Hugo Krawczyk wrote: > > Hi Nikos, > > > > These are good questions - see responses below. > > > > On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogiannopoulos < > nmav@redhat.com> > > wrote: > > > > > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote: > > > [...] > > > > The WG sentiment was generally favorable to exploring this avenue b= ut > > > > there was also airly strong WG sentiment that we didn't presently > want > > > > to do an offline signatures. This leaves with a model in which the > > > > client initially learns the server's semi-static DH share through > > > > an online-signed 1-RTT handshake but then can cache it for use with > > > > future connections. > > > > > > Wasn't that discussed in the list before? My impression was that the > > > outcome of that discussion was not to add that. > > > > > > > =E2=80=8BThe objections to the original proposal were related to the us= e of > offline > > signatures to sign a semi-static DH key. This is not an option in ekr's > > draft. Neither the draft accommodates DH certificates. All server's > > authentication is based on regular (online) TLS signatures except if th= e > > client has cached a semi-static key from the server as needed to suppor= t > > 0-RTT. > > I think that is the worst case. > > ECC signature generation are faster than ECDH operation. But OTOH, ECDH > operation is much easier to implement than ECC signature. So one gets > slowdown for no simplification. > > Also, two-level key schemes have certain benefits, but lack of offline > signing makes it one-level key scheme with two keys. > > > > Anyway, a first question that comes to mind, is why this isn't define= d > > > as separate ciphersuites? Why does it even have to be TLS 1.3 related= ? > > > Static DH parameters is an experiment that failed years ago. What has > > > changed since then that we believe now it is going to work? You even > > > > > > > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B > > - Forward secrecy (PFS) is now mandatory. > > - The protocol accommodate a 0-RTT mode. > > > > These two changes can only be implemented via Diffie-Hellman transforms > (in > > theory, any CCA-secure public key encryption can be used but (EC)DH is > the > > only currently practical instantiation in this setting). In particular, > > 0-RTT requires supporting semi-static DH keys for the server. All that > ekr > > draft does is to build a protocol where PFS is supported, 0-RTT is > > supported, semi-static keys are supported, and TLS-type signatures are > > supported in any case where the client does not have a cached semi-stat= ic > > key of the server. The beauty of it, if I can say so, is that all these > > modes are just subsets of a single protocol with a single crypto logic > and > > uniform specification (which also covers uniformly PSK and resumption). > > > > The alternative is to keep TLS 1.2 and add to it the semi-static case a= s > a > > patch, hence requiring essentially implementing all that is now in ekr'= s > > draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the > > cryptographic analysis point of view this would mean analyzing two > separate > > protocols as well as making sure these two protocols do not have any ba= d > > interaction when put together. > > The simplest way to do 0RTT would be for server to signal parameters for > 0RTT in extension and then client to put public keys and 0RTT data > ((EC)IES) > into ClientHello extension (doesn't work that well in TLS 1.2 still). > > Of course, that provodes absolutely no replay protection... > > > > dropped the static DH ciphersuites from TLS 1.3. Please make that par= t > > > optional so you don't doom the whole TLS 1.3 protocol enhancements if > > > no-one switches to static DH keys (in the document they are described > as > > > semi-static DH keys - but there is no definition of what that means). > > > > > > A second question is why HKDF? Why is it even there? Is there any iss= ue > > > with the current TLS PRF and we need another? Is there a valid reason > to > > > bloat implementations with shipping multiple KDFs? This kind of chang= es > > > shouldn't be done without thought, as it is now there cannot be any > code > > > sharing between TLS 1.2 and 1.3 and we risk having implementers stay > > > with TLS 1.2 for the next decade. > > > > > > > =E2=80=8BHKDF is just a way of structuring the use of TLS PRF (HMAC-PRF= ) in a way > > that supports a uniform, hierarchical key derivation scheme which is > common > > to all the modes of the protocol as discussed above (including PSK, > Export, > > resumption, etc.) and which accommodates deriving keys from possibly > > non-uniform secrets such as DH values, passphrases, etc. In particular, > it > > sets no requirements or assumptions in the form of the secret/entropy > > source from which keys are derived, hence freeing the protocol > > instantiation from things like point representation in an elliptic curv= e > > (it will work with compressed representation, uncompressed ones, etc). > > > > I believe these are all huge benefits at all levels: design, analysis, > > specification, implementation, maintenance of the protocol (future > > changes/additions). I cannot comment on code sharing though, although I > > hope we do not ruin the future by tying ourselves too much to the past. > > Well, to me the key derivation in EKR draft (using HKDF) looks much more > messy than the one in editor draft (using classic TLS PRF) > > > -Ilari > --001a113367fc07bcb70511fb08db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
0-RTT with (EC)IES is exactly what we are doing= .
Keeping online signatures is what the WG wanted (the = other option is offline signatures or DH certificates which had opposition)= .
If you can come with a simplified design combining th= ese things, I will be happy to hear.

The KDF deriva= tion scheme is as simple as it gets for all keys that need to be derived an= d is uniform for all modes.
You could save one level of= extraction if you were willing to key the prf with your DH secrets, which = I do not recommend.

Hugo


On Mon, Mar 23, 2015 at = 4:54 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Mon, Mar = 23, 2015 at 03:22:05PM -0400, Hugo Krawczyk wrote:
> Hi Nikos,
>
> These are good questions - see responses below.
>
> On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
> wrote:
>
> > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote:
> > [...]
> > > The WG sentiment was generally favorable to exploring this a= venue but
> > > there was also airly strong WG sentiment that we didn't = presently want
> > > to do an offline signatures. This leaves with a model in whi= ch the
> > > client initially learns the server's semi-static DH shar= e through
> > > an online-signed 1-RTT handshake but then can cache it for u= se with
> > > future connections.
> >
> > Wasn't that discussed in the list before? My impression was t= hat the
> > outcome of that discussion was not to add that.
> >
>
> =E2=80=8BThe objections to the original proposal were related to the u= se of offline
> signatures to sign a semi-static DH key. This is not an option in ekr&= #39;s
> draft. Neither the draft accommodates DH certificates. All server'= s
> authentication is based on regular (online) TLS signatures except if t= he
> client has cached a semi-static key from the server as needed to suppo= rt
> 0-RTT.

I think that is the worst case.

ECC signature generation are faster than ECDH operation. But OTOH, ECDH
operation is much easier to implement than ECC signature. So one gets
slowdown for no simplification.

Also, two-level key schemes have certain benefits, but lack of offline
signing makes it one-level key scheme with two keys.

> > Anyway, a first question that comes to mind, is why this isn'= t defined
> > as separate ciphersuites? Why does it even have to be TLS 1.3 rel= ated?
> > Static DH parameters is an experiment that failed years ago. What= has
> > changed since then that we believe now it is going to work? You e= ven
> >
>
> =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B
> - Forward secrecy (PFS) is now mandatory.
> - The protocol accommodate a 0-RTT mode.
>
> These two changes can only be implemented via Diffie-Hellman transform= s (in
> theory, any CCA-secure public key encryption can be used but (EC)DH is= the
> only currently practical instantiation in this setting). In particular= ,
> 0-RTT requires supporting semi-static DH keys for the server. All that= ekr
> draft does is to build a protocol where PFS is supported, 0-RTT is
> supported, semi-static keys are supported, and TLS-type signatures are=
> supported in any case where the client does not have a cached semi-sta= tic
> key of the server. The beauty of it, if I can say so, is that all thes= e
> modes are just subsets of a single protocol with a single crypto logic= and
> uniform specification (which also covers uniformly PSK and resumption)= .
>
> The alternative is to keep TLS 1.2 and add to it the semi-static case = as a
> patch, hence requiring essentially implementing all that is now in ekr= 's
> draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the
> cryptographic analysis point of view this would mean analyzing two sep= arate
> protocols as well as making sure these two protocols do not have any b= ad
> interaction when put together.

The simplest way to do 0RTT would be for server to signal parameters= for
0RTT in extension and then client to put public keys and 0RTT data ((EC)IES= )
into ClientHello extension (doesn't work that well in TLS 1.2 still).
Of course, that provodes absolutely no replay protection...

> > dropped the static DH ciphersuites from TLS 1.3. Please make that= part
> > optional so you don't doom the whole TLS 1.3 protocol enhance= ments if
> > no-one switches to static DH keys (in the document they are descr= ibed as
> > semi-static DH keys - but there is no definition of what that mea= ns).
> >
> > A second question is why HKDF? Why is it even there? Is there any= issue
> > with the current TLS PRF and we need another? Is there a valid re= ason to
> > bloat implementations with shipping multiple KDFs? This kind of c= hanges
> > shouldn't be done without thought, as it is now there cannot = be any code
> > sharing between TLS 1.2 and 1.3 and we risk having implementers s= tay
> > with TLS 1.2 for the next decade.
> >
>
> =E2=80=8BHKDF is just a way of structuring the use of TLS PRF (HMAC-PR= F) in a way
> that supports a uniform, hierarchical key derivation scheme which is c= ommon
> to all the modes of the protocol as discussed above (including PSK, Ex= port,
> resumption, etc.) and which accommodates deriving keys from possibly > non-uniform secrets such as DH values, passphrases, etc. In particular= , it
> sets no requirements or assumptions in the form of the secret/entropy<= br> > source from which keys are derived, hence freeing the protocol
> instantiation from things like point representation in an elliptic cur= ve
> (it will work with compressed representation, uncompressed ones, etc).=
>
> I believe these are all huge benefits at all levels: design, analysis,=
> specification, implementation, maintenance of the protocol (future
> changes/additions). I cannot comment on code sharing though, although = I
> hope we do not ruin the future by tying ourselves too much to the past= .

Well, to me the key derivation in EKR draft (using HKDF) looks much = more
messy than the one in editor draft (using classic TLS PRF)


-Ilari

--001a113367fc07bcb70511fb08db-- From nobody Mon Mar 23 14:15: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 A409C1A1AB9 for ; Mon, 23 Mar 2015 14:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ncywoiaRzmk5 for ; Mon, 23 Mar 2015 14:15:46 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id F36EF1B2A5F for ; Mon, 23 Mar 2015 14:15:43 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3E1F247A14; Mon, 23 Mar 2015 21:15:43 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 31C8947989; Mon, 23 Mar 2015 21:15:43 +0000 (GMT) Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2E4A080058; Mon, 23 Mar 2015 21:15:43 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 23 Mar 2015 17:15:42 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 23 Mar 2015 17:15:42 -0400 From: "Salz, Rich" To: Hugo Krawczyk Thread-Topic: [TLS] Initial draft of DH-based key exchange Thread-Index: AQHQZW6FMJAAig7540yfXGlB5xzDAZ0qbeCAgABHnID//9vMEA== Date: Mon, 23 Mar 2015 21:15:41 +0000 Message-ID: <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> References: <1427123147.19595.62.camel@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.118.71] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:15:47 -0000 U28gdGhpcyBpcyBwcmV0dHkgYW1hemluZy4gIFdlIGhhdmUgYSBwcm9wb3NlZCB1bmlmb3JtIGtl eSBleGNoYW5nZSBtZXRob2QgdGhhdCB1c2VzIG9uZSBwcmltaXRpdmUgYW5kIGNvdmVycyBhbGwg dGhlIHVzZSBjYXNlcy4gIEFuZCB3ZSBoYXZlIGEgcHJvcG9zZWQgdW5pZm9ybSBLREYgZnVuY3Rp b24gdGhhdCBhbHNvIGNvdmVycyBhbGwgdXNlIGNhc2VzLg0KDQpIb3cgY2FuIHlvdSBub3QgbGlr ZSB0aGlzPyAgOikgTGV0J3MgY2FsbCBpdCAyLjAsIGRyb3AgcmVjb3JkIHZlcnNpb24sIElWIGR1 cGxpY2F0aW9uLCBldGMuICBKdXN0IGhhdmUgdG8ga2VlcCB0aGUgZXhpc3RpbmcgaGVsbG8gbWVz c2FnZXMgZm9yIGludGVyb3AuDQoNCgkvciQNCiANCg0K From nobody Mon Mar 23 14:21: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 80FD51B2A5D for ; Mon, 23 Mar 2015 14:21: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 lIXPuHWCv_yC for ; Mon, 23 Mar 2015 14:21:46 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 9AF1A1B2A65 for ; Mon, 23 Mar 2015 14:21:44 -0700 (PDT) Received: by wixw10 with SMTP id w10so75730318wix.0 for ; Mon, 23 Mar 2015 14:21: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=ema1npr/7aHvkZxWPuMd/1SeE6En9sscqtyzxEli3F4=; b=bU6PshYpL6YnKCz2AS4kX7zmQyy1meO43bxZVJdigLh2Sqcpw+UpQ1FoWBCEp5W/aU 3cfV/i5w406+tULn5KB9NQ+8qurJzyVJmJb5PVdQ1P0v4QuVuxvFBYgmm+WNGvM+bJs3 FptnvMETZNmTATFtXKc44LY2u8BhUsg4TDIPZ7b6l98HuIE5hfhCdJDMaiFhtWmViOQo IcoEfuvyfWhvpuPJ+WRALd7BCb5dytSWJWJ4kps9Sd/QdvyxlHj5YJIXlkptq2oTvNFQ rS7hHxXjI1sSkxyim+bep9lD3ALwlSNxiiOSiAv7P1tmAMuPWBlgRxSPqweUIfi2NvXT WwIg== X-Gm-Message-State: ALoCoQmnfwJKLoyn6p8VbMs0ZLQMU7azpfq94rZHkbmG37Ug2nkQJ372/9qNHxSYMOdO87VGaJtV X-Received: by 10.180.7.196 with SMTP id l4mr22305757wia.44.1427145703297; Mon, 23 Mar 2015 14:21:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Mon, 23 Mar 2015 14:21:03 -0700 (PDT) In-Reply-To: <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> References: <1427123147.19595.62.camel@redhat.com> <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> From: Eric Rescorla Date: Mon, 23 Mar 2015 16:21:03 -0500 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f46d041826b8b030240511fb4068 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:21:50 -0000 --f46d041826b8b030240511fb4068 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 4:15 PM, Salz, Rich wrote: > IV duplication, etc. Can you clarify what you mean about "IV duplication"? Are you referring to the per-record IVs? If so you might be interested in: https://github.com/tlswg/tls13-spec/pull/155 -Ekr --f46d041826b8b030240511fb4068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 23, 2015 at 4:15 PM, Salz, Rich <rsalz@akamai.com> wrote:
IV duplication, etc.

=
Can you clarify what you mean about "IV duplication"? = Are you referring
to the per-record IVs? If so you might be inter= ested in:

=

-Ekr
=C2=A0
--f46d041826b8b030240511fb4068-- From nobody Mon Mar 23 14:24: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 18A351A1B1E for ; Mon, 23 Mar 2015 14:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 sanrPoC6ViwW for ; Mon, 23 Mar 2015 14:23:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 059671A1AFF for ; Mon, 23 Mar 2015 14:23:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8742547ACA; Mon, 23 Mar 2015 21:23:56 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 757C147AC9; Mon, 23 Mar 2015 21:23:56 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 56A4180054; Mon, 23 Mar 2015 21:23:56 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 23 Mar 2015 17:23:55 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Mon, 23 Mar 2015 17:23:55 -0400 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [TLS] Initial draft of DH-based key exchange Thread-Index: AQHQZW6FMJAAig7540yfXGlB5xzDAZ0qbeCAgABHnID//9vMEIAARXGA//+9mIA= Date: Mon, 23 Mar 2015 21:23:54 +0000 Message-ID: References: <1427123147.19595.62.camel@redhat.com> <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.118.71] Content-Type: multipart/alternative; boundary="_000_a4ea97bf2535426dabbf5631db378c19usma1exdag1mb2msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:24:02 -0000 --_000_a4ea97bf2535426dabbf5631db378c19usma1exdag1mb2msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIG1lYW50IHRoZSBwZXItcmVjb3JkIElWLiAgSSB3YXMganVzdCB0b28gZGlzdHJhY3Rl ZCB0byBsb29rIHVwIHRoZSBQUi4NCg0KLS0NClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNo bm9sb2dpZXMNCklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRvOnJzYWx6QGphYmJlci5tZT4gVHdp dHRlcjogUmljaFNhbHoNCg0K --_000_a4ea97bf2535426dabbf5631db378c19usma1exdag1mb2msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBJIG1lYW50IHRoZSBwZXItcmVjb3Jk IElWLiZuYnNwOyBJIHdhcyBqdXN0IHRvbyBkaXN0cmFjdGVkIHRvIGxvb2sgdXAgdGhlIFBSLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZW5pb3Ig QXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklNOg0KPGEgaHJlZj0ibWFpbHRvOnJzYWx6QGphYmJlci5tZSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsdWUiPnJzYWx6QGphYmJlci5tZTwvc3Bhbj48L2E+IFR3aXR0ZXI6IFJpY2hTYWx6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_a4ea97bf2535426dabbf5631db378c19usma1exdag1mb2msgcorpak_-- From nobody Mon Mar 23 15:53: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 112601A0100 for ; Mon, 23 Mar 2015 15:53: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 2hpbGLo_DI9z for ; Mon, 23 Mar 2015 15:53:00 -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 9C9791A0162 for ; Mon, 23 Mar 2015 15:53:00 -0700 (PDT) Received: by qgep97 with SMTP id p97so40516368qge.1 for ; Mon, 23 Mar 2015 15:53: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=Sfa46smDvAw/HxK08ptwAtPbwIZsYUzQMYs1kk/tGn4=; b=VsD5YCpSrSFm/N1cswqisnp51jx4eKc1Hrx7OUKgJd36i6dtChUPSe+bnwJIfeInze bbBiSnxxmf2iOAQH71Zw5Sa/vptvMzdq+Eq48p7UXB3TvocReFGq8trB2vAuboMEpoIW p9n3UHyNoLa7pS3uu69vXA3meaYC+gTNAy2nCtTz5Dt+BxurBoPLnJ+PuA6xPD6sKGna Y0EP39eRq7IENGrnJ9sVLE68PLQJ1/hyI7dmAhm2IBdTEw9bs/etA0LzYtjYSdg1H0tP 4JfCfpS1PJexKNrzlL3+/nhc7+cMNlES72zl3kSDqc0rf+WiQ3G1Pfw4N1AEP3pf1CVl pbZw== X-Received: by 10.140.28.36 with SMTP id 33mr2104015qgy.6.1427151179935; Mon, 23 Mar 2015 15:52:59 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id z18sm1466630qkz.33.2015.03.23.15.52.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Mar 2015 15:52:59 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, "Salz, Rich" Date: Mon, 23 Mar 2015 18:52:57 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> In-Reply-To: <35f81edc61614437b1437c74f0b230e9@usma1ex-dag1mb2.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201503231852.58112.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:53:02 -0000 On Monday, March 23, 2015 05:15:41 pm Salz, Rich wrote: > So this is pretty amazing. We have a proposed uniform key exchange method that uses one primitive and covers all the use cases. And we have a proposed uniform KDF function that also covers all use cases. > > How can you not like this? :) Let's call it 2.0, drop record version, IV duplication, etc. Just have to keep the existing hello messages for interop. I'm in favor of naming this TLS 2.0 as well, but the on-the-wire version number should stay {3,4} and not {4,0} because TLS version intolerance >1.x is even worse. Probably time to change ProtocolVersion to a 16-bit enum with values based on the existing pattern instead of keeping up the {major,minor} farce. ;) Dave From nobody Mon Mar 23 21:58: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 7552D1B2C8A for ; Mon, 23 Mar 2015 21:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Du3OwjvKpWe for ; Mon, 23 Mar 2015 21:58:11 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 AF3E41B2C89 for ; Mon, 23 Mar 2015 21:58:11 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so139400931obd.3 for ; Mon, 23 Mar 2015 21:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Brd1vBYHmwJ+ZsJnQYQi9mADiZIEKSjw29Ji5gmkjt0=; b=mfvdStYXfTvjvy+Er9TPJWBubeNbrSubdmcwt/oY5dmaw5pQJPCL8/eVCm/h6SgEP+ eE1qO8mrjuqHyrVn3MCBt49Yl1KhrzRi3/ZMeu9detvb6CxbAalQBVNZ5+UunjyQ8GnF vkaXoqonS4qfAnJ6i7ThS3alCJvehjc9gh1z95qD4+TPq/u9rvNuAg9CtTmFp9/vts1n NFTzJ9a16MGmncADo/jbbMATgs/lPwlOKY/XyoDUw3y8OW9gTJd2Fry1aA15POmCBJtr aZNgmuPLAfdv+ScEM5pXWg99+HFCUGS2BpdkCJKkpXGGJhu91WsJKTXLp5Jr1NaW9zLe O2zw== X-Received: by 10.202.55.4 with SMTP id e4mr1741808oia.45.1427173091276; Mon, 23 Mar 2015 21:58:11 -0700 (PDT) Received: from [10.111.111.37] ([173.200.48.34]) by mx.google.com with ESMTPSA id h8sm1667179obe.2.2015.03.23.21.58.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 21:58:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 23 Mar 2015 23:58:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 04:58:13 -0000 > On Mar 23, 2015, at 9:19 AM, Eric Rescorla wrote: >=20 > As I mentioned in a previous message [0] during the interim we = discussed > moving from the TLS PRF to HKDF [RFC5869]. >=20 > The general sentiment was: >=20 > - Move to HKDF > - Specify both SHA-256 and SHA-384 (the latter being required for > Suite B) >=20 > This is also the time when we would want to look at adjusting > the key expansion to separate keys and IVs (assuming we still > have IVs). >=20 > Please use this thread to discuss this topic. >=20 OK, since you=E2=80=99re proposing to abandon the current TLS PRF: 1. Why? What is wrong with the TLS PRF, and=20 2. If we=E2=80=99re changing it, why not to a fast PRF such as blake2? Yoav From nobody Mon Mar 23 23:01: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 C977C1B2CA2 for ; Mon, 23 Mar 2015 23:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIVw8mxQ_40m for ; Mon, 23 Mar 2015 23:01:48 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C681B2CA4 for ; Mon, 23 Mar 2015 23:01:46 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-11v.sys.comcast.net with comcast id 7J1l1q0064tLnxL01J1lJc; Tue, 24 Mar 2015 06:01:45 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by resomta-po-02v.sys.comcast.net with comcast id 7J1k1q00A4uhcbK01J1kYH; Tue, 24 Mar 2015 06:01:45 +0000 Message-ID: <5510FDC8.1060702@brainhub.org> Date: Mon, 23 Mar 2015 23:01:44 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> In-Reply-To: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1427176905; bh=iGNLXPj0Y42XqVVZOZE+r30XnqGUWRWbox0DTTldq7I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pcjrpu/7CRarjkDU24EK3Ro13TsTHf4cHF+TxBTVZn6lOqvw9oc41IKH6fILzw2lq nfd3D0Mc3LXnUO+NoE3vyyYk5VjzCj1SJ5zM3D5fYVdpLOQTmqRvTuuJZEProQODBd OeoPmK0pu50petG//aNq0FvWPLO3CWkYAbxFVLJH8vnbuw51duIX6DiLZoOFq6/t59 0QMlYthzrKSqJLZKEziU26UuneL0kU6pCl96+0oE3orWV3B7nCmQyboHnTQZuayix4 8XOnScYS2FrVuTQa9VAZOtG1gdktagG9RFvjoSDOPYEqD1bPHywfyI91Wpk8hzAS0I PuWVc59lFBLSw== Archived-At: Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 06:01:50 -0000 On 03/23/2015 09:58 PM, Yoav Nir wrote: >> On Mar 23, 2015, at 9:19 AM, Eric Rescorla wrote: >> >> As I mentioned in a previous message [0] during the interim we discussed >> moving from the TLS PRF to HKDF [RFC5869]. >> >> The general sentiment was: >> >> - Move to HKDF >> - Specify both SHA-256 and SHA-384 (the latter being required for >> Suite B) >> >> This is also the time when we would want to look at adjusting >> the key expansion to separate keys and IVs (assuming we still >> have IVs). >> >> Please use this thread to discuss this topic. >> > OK, since you’re proposing to abandon the current TLS PRF: > > 1. Why? What is wrong with the TLS PRF, and > 2. If we’re changing it, why not to a fast PRF such as blake2? > > Yoav > I am somewhat sympathetic to this sentiment. Please also consider that KDFs and related processes are standardized by NIST. E.g.: 1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF for key expansion) 2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 criticizes the first revision; rev 2 is dated 2015) 3. NIST grandfathered TLS KDF in SP 800-135. 4. A very similar SP 800-56C that documents Extraction-then-Expansion, where expansion is done with #1 (credits Hugo Krawczyk, among others) Please note that at least some of these can be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of these approved KDFs. While NIST is perhaps too prolific with these, I feel that we should look into standard KDFs. There are test vectors, verifications systems, existing implementations... From nobody Tue Mar 24 01:12: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 B9AA01B2D10 for ; Tue, 24 Mar 2015 01:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06jPnKMurFwZ for ; Tue, 24 Mar 2015 01:12:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 83D781B2D08 for ; Tue, 24 Mar 2015 01:12:44 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2O8CUGM009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 24 Mar 2015 04:12:30 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2O8CQiv010212 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 04:12:28 -0400 Message-ID: <1427184746.3200.16.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hugo Krawczyk Date: Tue, 24 Mar 2015 09:12:26 +0100 In-Reply-To: References: <1427123147.19595.62.camel@redhat.com> <20150323205457.GA23158@LK-Perkele-VII> 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 08:12:45 -0000 On Mon, 2015-03-23 at 17:05 -0400, Hugo Krawczyk wrote: > The KDF derivation scheme is as simple as it gets for all keys that > need to be derived and is uniform for all modes. Note, that an implementation will still have to keep the original PRF to support all previous protocols. Given the average life time of a protocol that means keeping two separate KDFs for 10-20 years. That is not an enormous cost, but the piling of simple primitives don't make a simple protocol or even worse a simple implementation. regards, Nikos From nobody Tue Mar 24 01:28: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 A8DA51B2D2D for ; Tue, 24 Mar 2015 01:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnNvPRPRX_gh for ; Tue, 24 Mar 2015 01:28:33 -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 5BFA81B2D2A for ; Tue, 24 Mar 2015 01:28:33 -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 DF215A10B6; Tue, 24 Mar 2015 08:28:32 +0000 (UTC) Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2O8ST2g028675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2015 04:28:31 -0400 Message-ID: <1427185709.3200.23.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hugo Krawczyk Date: Tue, 24 Mar 2015 09:28:29 +0100 In-Reply-To: References: <1427123147.19595.62.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 08:28:34 -0000 On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote: > ​Two important things change in TLS 1.3:​ > - Forward secrecy (PFS) is now mandatory. > > - The protocol accommodate a 0-RTT mode. > > > These two changes can only be implemented via Diffie-Hellman > transforms (in theory, any CCA-secure public key encryption can be > used but (EC)DH is the only currently practical instantiation in this > setting). In particular, 0-RTT requires supporting semi-static DH keys > for the server. All that ekr draft does is to build a protocol where > PFS is supported, 0-RTT is supported, semi-static keys are supported, > and TLS-type signatures are supported in any case where the client > does not have a cached semi-static key of the server. The beauty of > it, if I can say so, is that all these modes are just subsets of a > single protocol with a single crypto logic and uniform specification > (which also covers uniformly PSK and resumption). So if I understand well the additional semi-static key is to support the 0-rtt case only, and otherwise it should be simply a copy of the ephemeral key? I cannot say I fully follow the protocol in all possible scenarios. It would be nice to have a message flow of the interactions for the DH key exchange in all the cases (e.g., PSK) either as an appendix or the main text. As we are moving to non-widely known key exchanges it makes sense to document them clearly, or at least link to documents which define them. regards, Nikos From nobody Tue Mar 24 04:39: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 D89D91A8993 for ; Tue, 24 Mar 2015 04:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9atuKQeDx_V4 for ; Tue, 24 Mar 2015 04:39:45 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 650841A898F for ; Tue, 24 Mar 2015 04:39:45 -0700 (PDT) Received: by oiag65 with SMTP id g65so165061976oia.2 for ; Tue, 24 Mar 2015 04:39:45 -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=3Wc5bjQdu+8cyRJ6PXYbQPkPruREGjHpikSgmnVwE+E=; b=OBbCq/6No83FlMnrJBpPbUvleWgd8B7UTIm2EqJbpwuZkO3M3mXOjh0Ba2HYordSMh v7CcMc0D3IhuiY9Ks2b5pFRh6UtCpUxU33mdSe6ID89oujjJSc8WHVDW/CJOJ084rxvu 92/7jesWudtmtF8WhEL3olaNK6PSUVvDVDWtfKUrX1bN6wDTs6ai985lIjlzVvqKXYzZ OcEbFHBivV+22d1BIIHtdzMC+WFlhq5TNsXo6x2Ew7VtQi2ZeIJggi8DdCZAFchvY8JI ePrQHwhg4aYaKq/oCkOIdWvPg/yq0kx2TVmXUGhFMh9I2+fxBO/cDo5kda0rp9m005k4 BsTw== X-Received: by 10.182.199.70 with SMTP id ji6mr2909704obc.3.1427197184868; Tue, 24 Mar 2015 04:39:44 -0700 (PDT) Received: from [10.111.111.122] ([173.200.48.34]) by mx.google.com with ESMTPSA id f133sm2033338oia.8.2015.03.24.04.39.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 04:39:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <5510FDC8.1060702@brainhub.org> Date: Tue, 24 Mar 2015 06:39:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:39:47 -0000 > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov = wrote: >=20 > On 03/23/2015 09:58 PM, Yoav Nir wrote: >>> On Mar 23, 2015, at 9:19 AM, Eric Rescorla wrote: >>>=20 >>> As I mentioned in a previous message [0] during the interim we = discussed >>> moving from the TLS PRF to HKDF [RFC5869]. >>>=20 >>> The general sentiment was: >>>=20 >>> - Move to HKDF >>> - Specify both SHA-256 and SHA-384 (the latter being required for >>> Suite B) >>>=20 >>> This is also the time when we would want to look at adjusting >>> the key expansion to separate keys and IVs (assuming we still >>> have IVs). >>>=20 >>> Please use this thread to discuss this topic. >>>=20 >> OK, since you=E2=80=99re proposing to abandon the current TLS PRF: >>=20 >> 1. Why? What is wrong with the TLS PRF, and >> 2. If we=E2=80=99re changing it, why not to a fast PRF such as = blake2? >>=20 >> Yoav >>=20 > I am somewhat sympathetic to this sentiment. Please also consider that = KDFs and related processes are standardized by NIST. E.g.: >=20 > 1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF = for key expansion) >=20 > 2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 = criticizes the first revision; rev 2 is dated 2015) >=20 > 3. NIST grandfathered TLS KDF in SP 800-135. >=20 > 4. A very similar SP 800-56C that documents Extraction-then-Expansion, = where expansion is done with #1 (credits Hugo Krawczyk, among others) >=20 > Please note that at least some of these can be FIPS 140 tested (in = particular, TLS PRF). Suite B expects the use of these approved KDFs. >=20 > While NIST is perhaps too prolific with these, I feel that we should = look into standard KDFs. There are test vectors, verifications systems, = existing implementations=E2=80=A6 If such a KDF is needed for Suite-B, then it makes sense for Suite-B = ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and = AES-GCM. =20 Why not include a different PRF in those suites that have = non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever = signature scheme CFRG are going to recommend? Yoav From nobody Tue Mar 24 05:16: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 823001B2CB4 for ; Tue, 24 Mar 2015 05:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cssbu6ow-Iyi for ; Tue, 24 Mar 2015 05:16:35 -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 4A8FC1A88C4 for ; Tue, 24 Mar 2015 05:16:35 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 641D14023; Tue, 24 Mar 2015 14:16:32 +0200 (EET) Date: Tue, 24 Mar 2015 14:16:32 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20150324121632.GA28552@LK-Perkele-VII> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 12:16:37 -0000 On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote: > > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov wrote: > > > > Please note that at least some of these can be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of these approved KDFs. > > > > While NIST is perhaps too prolific with these, I feel that we should look into standard KDFs. There are test vectors, verifications systems, existing implementations… > > If such a KDF is needed for Suite-B, then it makes sense for Suite-B ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM. > > Why not include a different PRF in those suites that have non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever signature scheme CFRG are going to recommend? Or even special Suite B ciphersuites. I think there are only 2 of those. - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256 - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384 The basic idea being: They who care can implement that. -Ilari From nobody Tue Mar 24 06:09: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 5A1951A00DC for ; Tue, 24 Mar 2015 06:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEXtCtmrGri9 for ; Tue, 24 Mar 2015 06:08:58 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 63B481A034C for ; Tue, 24 Mar 2015 06:08:58 -0700 (PDT) Received: by oifl3 with SMTP id l3so136959357oif.0 for ; Tue, 24 Mar 2015 06:08:57 -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; bh=jX2VnmnNVF1XhbngABhCS2PGbQS1QQwi9S8/ZFNYp+0=; b=cn8ZKEb7XllgF5vmuQk3vDM5ArNQ8gucNLTuoZ8hCJbJuFeIPApWb8SDq71hv9aTHZ cXbA370peypSfDk5xdbwhFQnkAXYsSmJrF35DNFexAGYBGLQ9b8ANzOPFrXvMA/omSXB l4zXbJhZupO27+193n7tD2oosxM0KS9mu8BFXAhfZbGRluSpW0Ml3u99Hk7s+4w12r2o kcFvDd3SIX4RQ++2EFnbi+mXdGp+OkAuj279e98vdeRXOpN9ykjxgeYlXA16TvpQlQx3 iuTdJ+Cj8vVdVIi8LrDrT0aO0QQL2myULT9So+O+vyp7pBDiJJ5iEjcACdnUxXFw+Fnw u0Qw== X-Received: by 10.202.9.132 with SMTP id 126mr3002458oij.77.1427202537780; Tue, 24 Mar 2015 06:08:57 -0700 (PDT) Received: from [192.168.0.81] (rrcs-50-84-137-11.sw.biz.rr.com. [50.84.137.11]) by mx.google.com with ESMTPSA id z142sm2130365oig.22.2015.03.24.06.08.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 06:08:57 -0700 (PDT) Message-ID: <551161E6.10900@gmail.com> Date: Tue, 24 Mar 2015 09:08:54 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hugo Krawczyk , "tls@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060305010106020106060506" Archived-At: Cc: Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less 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, 24 Mar 2015 13:09:02 -0000 This is a multi-part message in MIME format. --------------060305010106020106060506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Hugo: In your email of October 31, 2014 (see below), you introduced the OPTLS protocol to TLS. At the time, you omitted some details, since you simply wished to socialize the ideas. You did emphasize, though, that details matter and put forward that you were working on flashing out the full details of the protocol and security proof. After a few months of radio silence (to me), the protocol seems to be on the radar screen for discussion with TLS again. It would therefore be good to have a stable reference that describes this in full technical detail and makes this a stable and solid source for the cryptographic community to look at and reference. I do think that OPTLS has interesting features, perhaps also outside TLS, but would like to give this a thorough and critical look first (and invite others to do so as well). For this, it would help to have something beyond some emails on the TLS list and some "flashed out" draft spec Eric Rescorla worked on earlier this week (which, although useful, may change over time). Having a stable document would make this more appealing to study and discuss in a wider audience, esp. for important potential use cases. If you have a paper (e.g., one you could post on the IACR ePrint server), that would be great. {Rest assured, this does not have to have the same size as your 2005 paper on HMQV for it to be useful.} Best regards, Rene == "The presentation is sketchy and omits the exact procedure for key derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof." On 10/31/2014 8:54 PM, Hugo Krawczyk wrote: > During the TLS interim meeting of last week (Oct 22 2014) I suggested > that TLS > 1.3 should abandon signature-based authentication (other than for > certificates) > and be based solely on a combination of ephemeral Diffie-Hellman for > PFS and > static Diffie-Hellman for authentication. This has multiple benefits > including > major performance gain (by replacing the per-handshake RSA signature > by the > server with a much cheaper elliptic curve exponentiation), > compatibility with > the mechanisms required for forward secrecy, natural accommodation of > a 0-RTT > option, and a simple extension without signatures for client > authentication. > > Below I present a schematic representation of the proposed protocol > referred > to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. > The presentation is sketchy and omits the exact procedure for key > derivation. > The latter is a crucial component for the security of the protocol, but > before getting into these details we want to get a sense of whether > the WG is > interested in this approach. In the meantime, Hoeteck Wee and myself are > working on the details of the protocol and the security proof. > > We describe a setting with optional 0-RTT and server-only authentication. > Client authentication can be added as a further option or as an extension > (similar to the current 1.3 proposal) - see below. > > NOTATION AND TERMINOLOGY: > > [K] symbols represent pointers to key material whose exact derivation > is not > included here except for specifying the basic DH values from which the > key is > derived (actual derivation will include further information similar to the > extended hash mechanisms or SessionHash proposal considered for 1.3). > Asterisks represent optional fields that the WG can decide to leave as > optional, > mandatory, or simply remove without changing the core cryptographic > security of > the protocol. All references to encryption mean "authenticated encryption" > using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). > > KeyShare's represent ephemeral Diffie-Hellman values exchanged by the > parties. > All the public key and Diffie-Hellman operations are assumed to happen > over a > cyclic group with generator g of order q (typically implemented by an > elliptic > curve group). We use multiplicative notation where ^ denotes > exponentiation as > in g^x, g^{xy} (here xy denotes multiplication of the scalars x and > y), etc. > Omitted from the current high level description is a mechanism for > testing group > membership of DH values or cofactor exponentiation (the specific mechanism > depends on the group type and is typically very efficient for elliptic > curves). > > SERVER PUBLIC KEY AND CERTIFICATE: > > The server has a long term private-public key pair denoted by (s,g^s) > where > s is uniform random in [0..q-1] (we refer to s and g^s as "static keys"). > We assume that the server has a certificate that includes the server's > public > key g^s and a CA-signed binding of this key to the server's identity. > We discuss the implementation of such certificates below. > > PROTOCOL OPTLS: > > ClientHello > ClientKeyShare > ClientData* [K0] --------> > ServerHello > ServerKeyShare > ServerCertificate* [K1] > ServerFinished [K2] > <-------- ServerData* [K2] > ClientFinished* [K2] --------> > > > Protected Application Data [K3] > <-------> > > > > 1-RTT CASE: > > The basic 1-RTT case omits the ClientData* field. It includes a > ClientKeyShare > g^x and a ServerKeyShare g^y and an optional (encrypted) server > certificate. > If the certificate is sent (it can be omitted if the client has > indicated that > it knows the server key as in the case in the 0-RTT scenario) and is > encrypted, > the encryption key K1 is derived from g^{xy}. > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is > used to > authenticate-encrypt the ServerFinished and ClientFinished messages (which > include a hash of the previous traffic) and to encrypt data from the > server if > such data is piggybacked to the second message. > > Key K3 is the "application key" used to derive key material for > protection of > application data. This key material will include (directional) > Authenticated > Encryption keys and, possibly, keys for derivation of further re-key > material. > K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its > derivation > will be different than K2, e.g., using a separating key expansion > technique. > > SUPPORT FOR 0-RTT: > > The above protocol is compatible with a 0-RTT protocol such as QUIC. > In this > case, the client is assumed to have information about the server's > public key > and other security parameters. The server is assumed to have some > mechanism in > place for detecting replay (e.g., via timestamps, stored client > nonces, etc.). > The resulting protocol is as described above where the ClientData > field is sent > encrypted under key K0 derived from g^{xs}. > The rest of the protocol is identical to the above. > Note: In this case, ServerCertificate is not sent as the client had to > know > the server's public key before the first message (one can imagine a > setting > where the server may send a different certificate in the second > message - if > desired, this can be accommodated too as an option or extension). > > CLIENT AUTHENTICATION: > > Client authentication can be supported via an option or extension. It > would > include a client certificate for a static DH key g^c sent in the third > message > (the certificate can be encrypted under key K2 to provide client's > identity > protection). In this case, the key for computing the ClientFinished > message and > the application key K3 would be derived from a combination of the > values g^xy, > g^xs, g^yc (and possibly also g^{cs}). > > NOTES: > > Note on Finished messages: The above spec sets ServerFinished as > mandatory and > ClientFinished as optional. The latter option is needed for a 1-RTT > protocol. > In principle, both Finished messages could be omitted and still obtain > security > via implicit authentication (assuming the inputs to key derivation are > chosen > appropriately). But given the advantages of ServerFinished for providing > explicit authentication, key confirmation, and active forward secrecy (see > below), it seems advisable to always include it. Including ClientFinished > provides key confirmation from client and also explicit client > authentication > when client certificate is included. ClientFinished also provides > Universal > Composable (UC) security (this is a result of the Canetti-Krawczyk > proof that > CK security implies UC security when a client confirmation step is > included). > > Note on certificates: Since in current practice servers hold > certificates for > RSA signature keys rather than for static DH keys, the certificate > field in the > above protocol will be implemented by a pair consisting of (i) the > server's RSA > signature certificate and (ii) the server's signature using this RSA > key on the > server's static public DH key g^s. The latter signature by the server is > performed only when a new static DH key is created (how often this > happens and > how many such keys are created is completely up to the server - it has the > advantage that these keys can be changed often to increase security > against > leaked keys). This use of RSA also enjoys the high efficiency of RSA > verification for the client. > The handling of Client certificates would be similar. > > Note on forward security (a.k.a. as PFS for Perfect Forward Security): > PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. > The meaning of PFS is that an attacker that finds the (long-term) static > private keys of the parties cannot compromise past session keys. > Without the > ServerFinished message the above protocol ensures forward secrecy against > passive attackers (i.e., for sessions where the attacker did not > choose g^y). > With ServerFinished, PFS holds also against active attackers. A similar > consideration applies to ClientFinished. > > Client certificates in the first message: We note that in cases where > client > certificates can be sent in the clear in the first message of the > protocol, one > can provide PFS and mutual authentication in a 1-RTT at essentially > the same > cost of an unauthenticated DH exchange (i.e., a cost of little more > than two > exponentiations). In such a setting one can also obtain mutual > authentication in > a 0-RTT protocol (with forward secrecy with respect to the client's key). > These options, however, require HMQV-like mechanisms and may raise IP > issues (this > can be investigated further if the WG is interested). > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------060305010106020106060506 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Hugo:

In your email of October 31, 2014 (see below), you introduced the OPTLS protocol to TLS. At the time, you omitted some details, since you simply wished to socialize the ideas. You did emphasize, though, that details matter and put forward that you were working on flashing out the full details of the protocol and security proof.

After a few months of radio silence (to me), the protocol seems to be on the radar screen for discussion with TLS again. It would therefore be good to have a stable reference that describes this in full technical detail and makes this a stable and solid source for the cryptographic community to look at and reference.

I do think that OPTLS has interesting features, perhaps also outside TLS, but would like to give this a thorough and critical look first (and invite others to do so as well). For this, it would help to have something beyond some emails on the TLS list and some "flashed out" draft spec Eric Rescorla worked on earlier this week (which, although useful, may change over time).  Having a stable document would make this more appealing to study and discuss in a wider audience, esp. for important potential use cases.

If you have a paper (e.g., one you could post on the IACR ePrint server), that would be great. {Rest assured, this does not have to have the same size as your 2005 paper on HMQV for it to be useful.}

Best regards, Rene

==
"The presentation is sketchy and omits the exact procedure for key derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof."

On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. 
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as optional,
mandatory, or simply remove without changing the core cryptographic security of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). 

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]       -------->
                                           ServerHello  
                                           ServerKeyShare 
                                           ServerCertificate* [K1]
                                           ServerFinished [K2]
                       <--------           ServerData* [K2]
ClientFinished* [K2]   -------->


            Protected Application Data [K3]
                       <------->



1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection of
application data.  This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is sent
encrypted under key K0 derived from g^{xs}. 
The rest of the protocol is identical to the above. 
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included). 

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in the
above protocol will be implemented by a pair consisting of (i) the server's RSA
signature certificate and (ii) the server's signature using this RSA key on the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client. 
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.  A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key). 
These options, however, require HMQV-like mechanisms and may raise IP issues (this
can be investigated further if the WG is interested).



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------060305010106020106060506-- From nobody Tue Mar 24 07:03: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 3CB851A8713 for ; Tue, 24 Mar 2015 07:03: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 OENo4mVpeA53 for ; Tue, 24 Mar 2015 07:03:48 -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 A22091A870F for ; Tue, 24 Mar 2015 07:03:47 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 37F171887BF; Tue, 24 Mar 2015 16:03:45 +0200 (EET) Date: Tue, 24 Mar 2015 16:03:45 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20150324140344.GA797@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> <1427185709.3200.23.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1427185709.3200.23.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:03:50 -0000 On Tue, Mar 24, 2015 at 09:28:29AM +0100, Nikos Mavrogiannopoulos wrote: > On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote: > > > > ​Two important things change in TLS 1.3:​ > > - Forward secrecy (PFS) is now mandatory. > > > > - The protocol accommodate a 0-RTT mode. > > > > > > These two changes can only be implemented via Diffie-Hellman > > transforms (in theory, any CCA-secure public key encryption can be > > used but (EC)DH is the only currently practical instantiation in this > > setting). In particular, 0-RTT requires supporting semi-static DH keys > > for the server. All that ekr draft does is to build a protocol where > > PFS is supported, 0-RTT is supported, semi-static keys are supported, > > and TLS-type signatures are supported in any case where the client > > does not have a cached semi-static key of the server. The beauty of > > it, if I can say so, is that all these modes are just subsets of a > > single protocol with a single crypto logic and uniform specification > > (which also covers uniformly PSK and resumption). > > So if I understand well the additional semi-static key is to support the > 0-rtt case only, and otherwise it should be simply a copy of the > ephemeral key? I cannot say I fully follow the protocol in all possible > scenarios. It would be nice to have a message flow of the interactions > for the DH key exchange in all the cases (e.g., PSK) either as an > appendix or the main text. As we are moving to non-widely known key > exchanges it makes sense to document them clearly, or at least link to > documents which define them. >From what I can understand, it adds interrim server DH key, which server signs (which may be the same as the server eph. key), computes DH of both with client eph. key and mixes those to become session keys (the interrim key can be reused to become 0RTT key for the next connection). So roughly: - Client: C_pub_e - Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages) - 0RTT key: F(DH(S_pub_s_prev, C_pub_e) - Session keys: G(DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e)) To me, this looks to lose all the benefits of of offline version: - The offline version is two-level key scheme, this isn't. - This version is quite a bit slower unless you disable 0RTT. - The offline version avoids server to have implement online signature, simplifying the code a good bit (especially if the signature is apparently intentionally made difficult, like ECDSA). -Ilari From nobody Tue Mar 24 07:08: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 5ADE61A8739 for ; Tue, 24 Mar 2015 07:08:37 -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 yPRDuuqI-oYd for ; Tue, 24 Mar 2015 07:08:35 -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 17AF91A872D for ; Tue, 24 Mar 2015 07:08:35 -0700 (PDT) Received: by wixw10 with SMTP id w10so53645551wix.0 for ; Tue, 24 Mar 2015 07:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=svkcNso8yYoLhnnFc6qODuDShyr8eJfqGR6kc46Uiww=; b=P/m26DPR3LlCE+Nno/IdVGQz+eLjnY6llPXJ4+e+KlFwf28bSW2ea0hHifx5XwRrH+ eql7/XXGGPdtL5vOBN8Q9D/H7UblYYcMlR3oIMqTy//7GD6M9jOn36DfQ7s2FFBkWojH QaRQ3HSJ/H2dKLe2mAfGYasKeDQYegnfKPZXW7kTaUZxF90bf8Q0vpayGMvPgLIze9rU 8em/QtusTtXmWCmZk/3RngTUN6RPsKnqGppScwYG1DT40UQcyqqmTnc9jxNXNdLuML5q aZhCc8S/uWnUabaAukLBET9wHKSZGfah6fn593uESxbzjbBzgnkvnJAnLyheEiUEQ5dA 9IUQ== X-Gm-Message-State: ALoCoQnmtIkPLrfvrcCqDMyK5fKZrPxWxMmDWXhvaEYBj7jCeS1VsU+sYeYp986xvo4uA1Ch2ruA X-Received: by 10.194.191.228 with SMTP id hb4mr8610850wjc.116.1427206113780; Tue, 24 Mar 2015 07:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Tue, 24 Mar 2015 07:07:52 -0700 (PDT) In-Reply-To: <20150324140344.GA797@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> <1427185709.3200.23.camel@redhat.com> <20150324140344.GA797@LK-Perkele-VII> From: Eric Rescorla Date: Tue, 24 Mar 2015 09:07:52 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7b8750be6ef88005120951a4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:08:37 -0000 --047d7b8750be6ef88005120951a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 24, 2015 at 9:03 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Mar 24, 2015 at 09:28:29AM +0100, Nikos Mavrogiannopoulos wrote: > > On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote: > > > > > > > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B > > > - Forward secrecy (PFS) is now mandatory. > > > > > > - The protocol accommodate a 0-RTT mode. > > > > > > > > > These two changes can only be implemented via Diffie-Hellman > > > transforms (in theory, any CCA-secure public key encryption can be > > > used but (EC)DH is the only currently practical instantiation in this > > > setting). In particular, 0-RTT requires supporting semi-static DH key= s > > > for the server. All that ekr draft does is to build a protocol where > > > PFS is supported, 0-RTT is supported, semi-static keys are supported, > > > and TLS-type signatures are supported in any case where the client > > > does not have a cached semi-static key of the server. The beauty of > > > it, if I can say so, is that all these modes are just subsets of a > > > single protocol with a single crypto logic and uniform specification > > > (which also covers uniformly PSK and resumption). > > > > So if I understand well the additional semi-static key is to support th= e > > 0-rtt case only, and otherwise it should be simply a copy of the > > ephemeral key? I cannot say I fully follow the protocol in all possible > > scenarios. It would be nice to have a message flow of the interactions > > for the DH key exchange in all the cases (e.g., PSK) either as an > > appendix or the main text. As we are moving to non-widely known key > > exchanges it makes sense to document them clearly, or at least link to > > documents which define them. > > >From what I can understand, it adds interrim server DH key, which server > signs (which may be the same as the server eph. key), computes DH of > both with client eph. key and mixes those to become session keys > (the interrim key can be reused to become 0RTT key for the next > connection). > > So roughly: > - Client: C_pub_e > - Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages) > - 0RTT key: F(DH(S_pub_s_prev, C_pub_e) > - Session keys: G(DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e)) > > > To me, this looks to lose all the benefits of of offline version: > - The offline version is two-level key scheme, this isn't. > - This version is quite a bit slower unless you disable 0RTT. > Note: we haven't yet determined how we are going to establish the key for future 0-RTT messages. You could reuse the key as you said above, but you could also just send a second key in a separate message, in which case you wouldn't have to take the hit, but at slightly more protocol complexity. -Ekr --047d7b8750be6ef88005120951a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 24, 2015 at 9:03 AM, Ilari Liusvaara <= ilari.lius= vaara@elisanet.fi> wrote:
<= div class=3D"HOEnZb">
On Tue, Mar 24, 2015 at 09:28:29AM += 0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote:
>
>
> > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B
> > - Forward secrecy (PFS) is now mandatory.
> >
> > - The protocol accommodate a 0-RTT mode.
> >
> >
> > These two changes can only be implemented via Diffie-Hellman
> > transforms (in theory, any CCA-secure public key encryption can b= e
> > used but (EC)DH is the only currently practical instantiation in = this
> > setting). In particular, 0-RTT requires supporting semi-static DH= keys
> > for the server. All that ekr draft does is to build a protocol wh= ere
> > PFS is supported, 0-RTT is supported, semi-static keys are suppor= ted,
> > and TLS-type signatures are supported in any case where the clien= t
> > does not have a cached semi-static key of the server. The beauty = of
> > it, if I can say so, is that all these modes are just subsets of = a
> > single protocol with a single crypto logic and uniform specificat= ion
> > (which also covers uniformly PSK and resumption).
>
> So if I understand well the additional semi-static key is to support t= he
> 0-rtt case only, and otherwise it should be simply a copy of the
> ephemeral key? I cannot say I fully follow the protocol in all possibl= e
> scenarios. It would be nice to have a message flow of the interactions=
> for the DH key exchange in all the cases (e.g., PSK) either as an
> appendix or the main text. As we are moving to non-widely known key > exchanges it makes sense to document them clearly, or at least link to=
> documents which define them.

>From what I can understand, it adds interrim server DH key,= which server
signs (which may be the same as the server eph. key), computes DH of
both with client eph. key and mixes those to become session keys
(the interrim key can be reused to become 0RTT key for the next
connection).

So roughly:
- Client: C_pub_e
- Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages)
- 0RTT key: F(DH(S_pub_s_prev, C_pub_e)
- Session keys: G(DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e))


To me, this looks to lose all the benefits of of offline version:
- The offline version is two-level key scheme, this isn't.
- This version is quite a bit slower unless you disable 0RTT.

Note: we haven't yet determined how we are going= to establish
the key for =C2=A0future 0-RTT messages. You could = reuse the key
as you said above, but you could also just send a s= econd key
in a separate message, in which case you wouldn't h= ave to take
the hit, but at slightly more protocol complexity.

-Ekr

--047d7b8750be6ef88005120951a4-- From nobody Tue Mar 24 08:12: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 6AC8D1A8894 for ; Tue, 24 Mar 2015 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hndf51Yo1kb3 for ; Tue, 24 Mar 2015 08:12:19 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 060111A888C for ; Tue, 24 Mar 2015 08:12:15 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so48793688lbb.3 for ; Tue, 24 Mar 2015 08:12:13 -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:from:date:message-id :subject:to:cc:content-type; bh=ofFm9Q1PGtib4m2nGA9odguJinI4keTpgCMpu7VTTdQ=; b=jkzCHS33CwWc9jt9g/iBCKu6BRUrU2TkYEjr1z+GAMa/HIkRmfHX0AALn8k8h4QGhC LAB6BhfGtg3V4mYsOg/E6NKNRb+Mrf3JcJ9RLdhs+glv2Cvujga+H/Fb4gj4VYM+XZ2J r8GsvDveVuswsepeoMs7CyiGYyah81pJIdl5j30WSwPZsX+hfUzib/znSUSXDxKmoCz7 uc+04zCSi2XqRSsnDW5XSSrsddoHZ7oUWUz/elRTfFXAV6ZslXJ/7oFZkHJjZAEm4LXI UbVxFuTmrG40hLoR2UVETIubcPPfuWnBJ0JTzGk+eifjoZOeaikN7M7pgmwmlnvwtjtR FOQA== X-Received: by 10.152.26.169 with SMTP id m9mr4161828lag.45.1427209933499; Tue, 24 Mar 2015 08:12:13 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Tue, 24 Mar 2015 08:11:43 -0700 (PDT) In-Reply-To: <551161E6.10900@gmail.com> References: <551161E6.10900@gmail.com> From: Hugo Krawczyk Date: Tue, 24 Mar 2015 11:11:43 -0400 X-Google-Sender-Auth: 8-iXkCYXIMCG5kb13Ve98MDtUs8 Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=089e0158c9e61b353105120a35fc Archived-At: Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less 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, 24 Mar 2015 15:12:27 -0000 --089e0158c9e61b353105120a35fc Content-Type: text/plain; charset=UTF-8 Hi Rene, We are working on such a write up as we speak. Exactly because the details matter and we have been changing them to adapt to the WG requirements and preferences then the writing has been delayed. We are now converging to a protocol that the people in the interim meeting were quite happy with. It is in the same spirit of OPTLS but it is not signature-less, i.e., semi-static keys for the servers are now signed with online signatures that prove freshness by including the client's nonce under the signature. We should have something decent to post in two weeks. But let me note that there is nothing revolutionary in the protocol - it is crypto engineering with well understood components, not inventing new fundamental pieces. Hugo On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik wrote: > Hi Hugo: > > In your email of October 31, 2014 (see below), you introduced the OPTLS > protocol to TLS. At the time, you omitted some details, since you simply > wished to socialize the ideas. You did emphasize, though, that details > matter and put forward that you were working on flashing out the full > details of the protocol and security proof. > > After a few months of radio silence (to me), the protocol seems to be on > the radar screen for discussion with TLS again. It would therefore be good > to have a stable reference that describes this in full technical detail and > makes this a stable and solid source for the cryptographic community to > look at and reference. > > I do think that OPTLS has interesting features, perhaps also outside TLS, > but would like to give this a thorough and critical look first (and invite > others to do so as well). For this, it would help to have something beyond > some emails on the TLS list and some "flashed out" draft spec Eric Rescorla > worked on earlier this week (which, although useful, may change over > time). Having a stable document would make this more appealing to study > and discuss in a wider audience, esp. for important potential use cases. > > If you have a paper (e.g., one you could post on the IACR ePrint server), > that would be great. {Rest assured, this does not have to have the same > size as your 2005 paper on HMQV for it to be useful.} > > Best regards, Rene > > == > "The presentation is sketchy and omits the exact procedure for key > derivation. The latter is a crucial component for the security of the > protocol, but before getting into these details we want to get a sense of > whether the WG is interested in this approach. In the meantime, Hoeteck Wee > and myself are working on the details of the protocol and the security > proof." > > On 10/31/2014 8:54 PM, Hugo Krawczyk wrote: > > During the TLS interim meeting of last week (Oct 22 2014) I suggested > that TLS > 1.3 should abandon signature-based authentication (other than for > certificates) > and be based solely on a combination of ephemeral Diffie-Hellman for PFS > and > static Diffie-Hellman for authentication. This has multiple benefits > including > major performance gain (by replacing the per-handshake RSA signature by the > server with a much cheaper elliptic curve exponentiation), compatibility > with > the mechanisms required for forward secrecy, natural accommodation of a > 0-RTT > option, and a simple extension without signatures for client > authentication. > > Below I present a schematic representation of the proposed protocol > referred > to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. > The presentation is sketchy and omits the exact procedure for key > derivation. > The latter is a crucial component for the security of the protocol, but > before getting into these details we want to get a sense of whether the WG > is > interested in this approach. In the meantime, Hoeteck Wee and myself are > working on the details of the protocol and the security proof. > > We describe a setting with optional 0-RTT and server-only authentication. > Client authentication can be added as a further option or as an extension > (similar to the current 1.3 proposal) - see below. > > NOTATION AND TERMINOLOGY: > > [K] symbols represent pointers to key material whose exact derivation is > not > included here except for specifying the basic DH values from which the key > is > derived (actual derivation will include further information similar to the > extended hash mechanisms or SessionHash proposal considered for 1.3). > Asterisks represent optional fields that the WG can decide to leave as > optional, > mandatory, or simply remove without changing the core cryptographic > security of > the protocol. All references to encryption mean "authenticated encryption" > using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). > > KeyShare's represent ephemeral Diffie-Hellman values exchanged by the > parties. > All the public key and Diffie-Hellman operations are assumed to happen > over a > cyclic group with generator g of order q (typically implemented by an > elliptic > curve group). We use multiplicative notation where ^ denotes > exponentiation as > in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), > etc. > Omitted from the current high level description is a mechanism for testing > group > membership of DH values or cofactor exponentiation (the specific mechanism > depends on the group type and is typically very efficient for elliptic > curves). > > SERVER PUBLIC KEY AND CERTIFICATE: > > The server has a long term private-public key pair denoted by (s,g^s) > where > s is uniform random in [0..q-1] (we refer to s and g^s as "static keys"). > We assume that the server has a certificate that includes the server's > public > key g^s and a CA-signed binding of this key to the server's identity. > We discuss the implementation of such certificates below. > > PROTOCOL OPTLS: > > ClientHello > ClientKeyShare > ClientData* [K0] --------> > ServerHello > ServerKeyShare > ServerCertificate* [K1] > ServerFinished [K2] > <-------- ServerData* [K2] > ClientFinished* [K2] --------> > > > Protected Application Data [K3] > <-------> > > > > 1-RTT CASE: > > The basic 1-RTT case omits the ClientData* field. It includes a > ClientKeyShare > g^x and a ServerKeyShare g^y and an optional (encrypted) server > certificate. > If the certificate is sent (it can be omitted if the client has indicated > that > it knows the server key as in the case in the 0-RTT scenario) and is > encrypted, > the encryption key K1 is derived from g^{xy}. > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is > used to > authenticate-encrypt the ServerFinished and ClientFinished messages (which > include a hash of the previous traffic) and to encrypt data from the > server if > such data is piggybacked to the second message. > > Key K3 is the "application key" used to derive key material for protection > of > application data. This key material will include (directional) > Authenticated > Encryption keys and, possibly, keys for derivation of further re-key > material. > K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its > derivation > will be different than K2, e.g., using a separating key expansion > technique. > > SUPPORT FOR 0-RTT: > > The above protocol is compatible with a 0-RTT protocol such as QUIC. In > this > case, the client is assumed to have information about the server's public > key > and other security parameters. The server is assumed to have some > mechanism in > place for detecting replay (e.g., via timestamps, stored client nonces, > etc.). > The resulting protocol is as described above where the ClientData field is > sent > encrypted under key K0 derived from g^{xs}. > The rest of the protocol is identical to the above. > Note: In this case, ServerCertificate is not sent as the client had to know > the server's public key before the first message (one can imagine a setting > where the server may send a different certificate in the second message - > if > desired, this can be accommodated too as an option or extension). > > CLIENT AUTHENTICATION: > > Client authentication can be supported via an option or extension. It would > include a client certificate for a static DH key g^c sent in the third > message > (the certificate can be encrypted under key K2 to provide client's identity > protection). In this case, the key for computing the ClientFinished > message and > the application key K3 would be derived from a combination of the values > g^xy, > g^xs, g^yc (and possibly also g^{cs}). > > NOTES: > > Note on Finished messages: The above spec sets ServerFinished as mandatory > and > ClientFinished as optional. The latter option is needed for a 1-RTT > protocol. > In principle, both Finished messages could be omitted and still obtain > security > via implicit authentication (assuming the inputs to key derivation are > chosen > appropriately). But given the advantages of ServerFinished for providing > explicit authentication, key confirmation, and active forward secrecy (see > below), it seems advisable to always include it. Including ClientFinished > provides key confirmation from client and also explicit client > authentication > when client certificate is included. ClientFinished also provides Universal > Composable (UC) security (this is a result of the Canetti-Krawczyk proof > that > CK security implies UC security when a client confirmation step is > included). > > Note on certificates: Since in current practice servers hold certificates > for > RSA signature keys rather than for static DH keys, the certificate field > in the > above protocol will be implemented by a pair consisting of (i) the > server's RSA > signature certificate and (ii) the server's signature using this RSA key > on the > server's static public DH key g^s. The latter signature by the server is > performed only when a new static DH key is created (how often this happens > and > how many such keys are created is completely up to the server - it has the > advantage that these keys can be changed often to increase security against > leaked keys). This use of RSA also enjoys the high efficiency of RSA > verification for the client. > The handling of Client certificates would be similar. > > Note on forward security (a.k.a. as PFS for Perfect Forward Security): > PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. > The meaning of PFS is that an attacker that finds the (long-term) static > private keys of the parties cannot compromise past session keys. Without > the > ServerFinished message the above protocol ensures forward secrecy against > passive attackers (i.e., for sessions where the attacker did not choose > g^y). > With ServerFinished, PFS holds also against active attackers. A similar > consideration applies to ClientFinished. > > Client certificates in the first message: We note that in cases where > client > certificates can be sent in the clear in the first message of the > protocol, one > can provide PFS and mutual authentication in a 1-RTT at essentially the > same > cost of an unauthenticated DH exchange (i.e., a cost of little more than > two > exponentiations). In such a setting one can also obtain mutual > authentication in > a 0-RTT protocol (with forward secrecy with respect to the client's key). > These options, however, require HMQV-like mechanisms and may raise IP > issues (this > can be investigated further if the WG is interested). > > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > --089e0158c9e61b353105120a35fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rene,

We are working= on such a write up as=C2=A0 we speak. Exactly because the details matter a= nd we have been changing them to adapt to the WG requirements and preferenc= es then the writing has been delayed. We are now converging to a protocol t= hat the people in the interim meeting were quite happy with. It is in the s= ame spirit of OPTLS but it is not signature-less, i.e., semi-static keys fo= r the servers are now signed with online signatures that prove freshness by= including the client's nonce under the signature.

We should have something decent to post in two weeks.
But let me note that there is nothing revolutionary in the protocol - it= is crypto engineering with well understood components, not inventing new f= undamental pieces.

Hugo


On Tue, Mar 2= 4, 2015 at 9:08 AM, Rene Struik <rstruik.ext@gmail.com> = wrote:
=20 =20 =20
Hi Hugo:

In your email of October 31, 2014 (see below), you introduced the OPTLS protocol to TLS. At the time, you omitted some details, since you simply wished to socialize the ideas. You did emphasize, though, that details matter and put forward that you were working on flashing out the full details of the protocol and security proof.

After a few months of radio silence (to me), the protocol seems to be on the radar screen for discussion with TLS again. It would therefore be good to have a stable reference that describes this in full technical detail and makes this a stable and solid source for the cryptographic community to look at and reference.

I do think that OPTLS has interesting features, perhaps also outside TLS, but would like to give this a thorough and critical look first (and invite others to do so as well). For this, it would help to have something beyond some emails on the TLS list and some "flashed out" draft spec Eric Rescorla worked on e= arlier this week (which, although useful, may change over time).=C2=A0 Havin= g a stable document would make this more appealing to study and discuss in a wider audience, esp. for important potential use cases.

If you have a paper (e.g., one you could post on the IACR ePrint server), that would be great. {Rest assured, this does not have to have the same size as your 2005 paper on HMQV for it to be useful.}

Best regards, Rene

=3D=3D
"The presentation is sketchy and omits the exact procedure for k= ey derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof."

On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
Durin= g the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.=C2=A0
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.
We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as optional,
mandatory, or simply remove without changing the core cryptographic security of
the protocol. All references to encryption mean "authenticat= ed encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).=C2=A0

KeyShare's represent ephemeral Diffie-Hellman values exchange= d by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -------->=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerHello=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerKeyShare=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-= -------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerD= ata* [K2]
ClientFinished* [K2]=C2=A0=C2=A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Protected Application Data [K3]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-= ------>



1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key mate= rial for protection of
application data.=C2=A0 This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from=C2=A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is sent
encrypted under key K0 derived from g^{xs}.=C2=A0
The rest of the protocol is identical to the above.=C2=A0
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included).=C2=A0

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in the
above protocol will be implemented by a pair consisting of (i) the server's RSA
signature certificate and (ii) the server's signature using this RSA key on the
server's static public DH key g^s. The latter signature by th= e server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client.=C2=A0
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.=C2= =A0 A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key).=C2=A0
These options, however, require HMQV-like mechanisms and may raise IP issues (this
can be investigated further if the WG is interested).



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



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=

--089e0158c9e61b353105120a35fc-- From nobody Tue Mar 24 08:31: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 8732E1A88F9 for ; Tue, 24 Mar 2015 08:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pRcUkBE0ccr for ; Tue, 24 Mar 2015 08:31:15 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 90DEF1A88D6 for ; Tue, 24 Mar 2015 08:31:14 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so400869wib.1 for ; Tue, 24 Mar 2015 08:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Cjkj3i+YgRXqnDXl+XSSmo1J3hb8PhCZY1/TpZRm0oU=; b=bb+je1ZuPvGhsFGoKyVTlwdKle39nsGfwJsSBR/KyvdyAf9iR6587n4ZN8yfInW5vp /QLw6RFoF6ukbRwsE8rnHpxmBZU3l+AMkD+rGMJLd1B+m9PRE8XWUGSGp3/Qk8jC5ORT uDLviRekykqRtQXxtrBx78dtMCh6BwmI2SmTvRyd3T4Lg3jcwqA+VAK/veQcg+hoSGJZ 62Xxc4iFUbmwx9xAjJfGeCsTHXznzavCF5D3IP6eSWTD5ac3nexN+7EWRms/+4Fz9BHO Di2PuoObdAAOlnymO7XZaetJkFojnXBRqN3Fvl6b4ztZRHW8misDcayQdKalha+MAIL3 EcjA== X-Received: by 10.180.189.37 with SMTP id gf5mr29771626wic.86.1427211073248; Tue, 24 Mar 2015 08:31:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:713e:89f5:8f43:7e48? ([2001:67c:370:160:713e:89f5:8f43:7e48]) by mx.google.com with ESMTPSA id ey10sm11590384wib.2.2015.03.24.08.31.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 08:31:12 -0700 (PDT) Message-ID: <5511833B.5070108@gmail.com> Date: Tue, 24 Mar 2015 11:31:07 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hugo Krawczyk References: <551161E6.10900@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020606020404030800070309" Archived-At: Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less 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, 24 Mar 2015 15:31:19 -0000 This is a multi-part message in MIME format. --------------020606020404030800070309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Great - looking forward to the technical write-up, when it becomes available. One quick question: if I remember correctly from your original OPTLS sketch, you paid some tribute to a "modus operandi" that includes client authentication as well (i.e., making this into a mutually authenticated key agreement scheme). I would be curious whether this is still on the table and, if so, whether this would also follow the same online signing approach you sketched below for the server. Apologies in case I missed some of this finer detail (hence, my interest in having a concise overall and technically complete description). While I do appreciate lots of this is "simply" cryptographic engineering, I do think you would have to agree that TLS has a mixed record here. Hence, some reflection and careful analysis seems to be in order, in addition to the great contributions you made yourself so far. Best regards, Rene On 3/24/2015 11:11 AM, Hugo Krawczyk wrote: > Hi Rene, > > We are working on such a write up as we speak. Exactly because the > details matter and we have been changing them to adapt to the WG > requirements and preferences then the writing has been delayed. We are > now converging to a protocol that the people in the interim meeting > were quite happy with. It is in the same spirit of OPTLS but it is not > signature-less, i.e., semi-static keys for the servers are now signed > with online signatures that prove freshness by including the client's > nonce under the signature. > > We should have something decent to post in two weeks. > But let me note that there is nothing revolutionary in the protocol - > it is crypto engineering with well understood components, not > inventing new fundamental pieces. > > Hugo > > > On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik > wrote: > > Hi Hugo: > > In your email of October 31, 2014 (see below), you introduced the > OPTLS protocol to TLS. At the time, you omitted some details, > since you simply wished to socialize the ideas. You did emphasize, > though, that details matter and put forward that you were working > on flashing out the full details of the protocol and security proof. > > After a few months of radio silence (to me), the protocol seems to > be on the radar screen for discussion with TLS again. It would > therefore be good to have a stable reference that describes this > in full technical detail and makes this a stable and solid source > for the cryptographic community to look at and reference. > > I do think that OPTLS has interesting features, perhaps also > outside TLS, but would like to give this a thorough and critical > look first (and invite others to do so as well). For this, it > would help to have something beyond some emails on the TLS list > and some "flashed out" draft spec Eric Rescorla worked on earlier > this week (which, although useful, may change over time). Having > a stable document would make this more appealing to study and > discuss in a wider audience, esp. for important potential use cases. > > If you have a paper (e.g., one you could post on the IACR ePrint > server), that would be great. {Rest assured, this does not have to > have the same size as your 2005 paper on HMQV for it to be useful.} > > Best regards, Rene > > == > "The presentation is sketchy and omits the exact procedure for key > derivation. The latter is a crucial component for the security of > the protocol, but before getting into these details we want to get > a sense of whether the WG is interested in this approach. In the > meantime, Hoeteck Wee and myself are working on the details of the > protocol and the security proof." > > On 10/31/2014 8:54 PM, Hugo Krawczyk wrote: >> During the TLS interim meeting of last week (Oct 22 2014) I >> suggested that TLS >> 1.3 should abandon signature-based authentication (other than for >> certificates) >> and be based solely on a combination of ephemeral Diffie-Hellman >> for PFS and >> static Diffie-Hellman for authentication. This has multiple >> benefits including >> major performance gain (by replacing the per-handshake RSA >> signature by the >> server with a much cheaper elliptic curve exponentiation), >> compatibility with >> the mechanisms required for forward secrecy, natural >> accommodation of a 0-RTT >> option, and a simple extension without signatures for client >> authentication. >> >> Below I present a schematic representation of the proposed >> protocol referred >> to as OPTLS where OPT stands for OPTimized and/or for >> One-Point-Three. >> The presentation is sketchy and omits the exact procedure for key >> derivation. >> The latter is a crucial component for the security of the >> protocol, but >> before getting into these details we want to get a sense of >> whether the WG is >> interested in this approach. In the meantime, Hoeteck Wee and >> myself are >> working on the details of the protocol and the security proof. >> >> We describe a setting with optional 0-RTT and server-only >> authentication. >> Client authentication can be added as a further option or as an >> extension >> (similar to the current 1.3 proposal) - see below. >> >> NOTATION AND TERMINOLOGY: >> >> [K] symbols represent pointers to key material whose exact >> derivation is not >> included here except for specifying the basic DH values from >> which the key is >> derived (actual derivation will include further information >> similar to the >> extended hash mechanisms or SessionHash proposal considered for >> 1.3). >> Asterisks represent optional fields that the WG can decide to >> leave as optional, >> mandatory, or simply remove without changing the core >> cryptographic security of >> the protocol. All references to encryption mean "authenticated >> encryption" >> using the encrypt-then-mac paradigm (or any other secure AEAD >> mechanism). >> >> KeyShare's represent ephemeral Diffie-Hellman values exchanged by >> the parties. >> All the public key and Diffie-Hellman operations are assumed to >> happen over a >> cyclic group with generator g of order q (typically implemented >> by an elliptic >> curve group). We use multiplicative notation where ^ denotes >> exponentiation as >> in g^x, g^{xy} (here xy denotes multiplication of the scalars x >> and y), etc. >> Omitted from the current high level description is a mechanism >> for testing group >> membership of DH values or cofactor exponentiation (the specific >> mechanism >> depends on the group type and is typically very efficient for >> elliptic curves). >> >> SERVER PUBLIC KEY AND CERTIFICATE: >> >> The server has a long term private-public key pair denoted by >> (s,g^s) where >> s is uniform random in [0..q-1] (we refer to s and g^s as "static >> keys"). >> We assume that the server has a certificate that includes the >> server's public >> key g^s and a CA-signed binding of this key to the server's identity. >> We discuss the implementation of such certificates below. >> >> PROTOCOL OPTLS: >> >> ClientHello >> ClientKeyShare >> ClientData* [K0] --------> >> ServerHello >> ServerKeyShare >> ServerCertificate* [K1] >> ServerFinished [K2] >> <-------- ServerData* [K2] >> ClientFinished* [K2] --------> >> >> >> Protected Application Data [K3] >> <-------> >> >> >> >> 1-RTT CASE: >> >> The basic 1-RTT case omits the ClientData* field. It includes a >> ClientKeyShare >> g^x and a ServerKeyShare g^y and an optional (encrypted) server >> certificate. >> If the certificate is sent (it can be omitted if the client has >> indicated that >> it knows the server key as in the case in the 0-RTT scenario) and >> is encrypted, >> the encryption key K1 is derived from g^{xy}. >> >> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. >> It is used to >> authenticate-encrypt the ServerFinished and ClientFinished >> messages (which >> include a hash of the previous traffic) and to encrypt data from >> the server if >> such data is piggybacked to the second message. >> >> Key K3 is the "application key" used to derive key material for >> protection of >> application data. This key material will include (directional) >> Authenticated >> Encryption keys and, possibly, keys for derivation of further >> re-key material. >> K3 is computed from both g^{xs} and g^{xy} similarly to K2, but >> its derivation >> will be different than K2, e.g., using a separating key expansion >> technique. >> >> SUPPORT FOR 0-RTT: >> >> The above protocol is compatible with a 0-RTT protocol such as >> QUIC. In this >> case, the client is assumed to have information about the >> server's public key >> and other security parameters. The server is assumed to have some >> mechanism in >> place for detecting replay (e.g., via timestamps, stored client >> nonces, etc.). >> The resulting protocol is as described above where the ClientData >> field is sent >> encrypted under key K0 derived from g^{xs}. >> The rest of the protocol is identical to the above. >> Note: In this case, ServerCertificate is not sent as the client >> had to know >> the server's public key before the first message (one can imagine >> a setting >> where the server may send a different certificate in the second >> message - if >> desired, this can be accommodated too as an option or extension). >> >> CLIENT AUTHENTICATION: >> >> Client authentication can be supported via an option or >> extension. It would >> include a client certificate for a static DH key g^c sent in the >> third message >> (the certificate can be encrypted under key K2 to provide >> client's identity >> protection). In this case, the key for computing the >> ClientFinished message and >> the application key K3 would be derived from a combination of the >> values g^xy, >> g^xs, g^yc (and possibly also g^{cs}). >> >> NOTES: >> >> Note on Finished messages: The above spec sets ServerFinished as >> mandatory and >> ClientFinished as optional. The latter option is needed for a >> 1-RTT protocol. >> In principle, both Finished messages could be omitted and still >> obtain security >> via implicit authentication (assuming the inputs to key >> derivation are chosen >> appropriately). But given the advantages of ServerFinished for >> providing >> explicit authentication, key confirmation, and active forward >> secrecy (see >> below), it seems advisable to always include it. Including >> ClientFinished >> provides key confirmation from client and also explicit client >> authentication >> when client certificate is included. ClientFinished also provides >> Universal >> Composable (UC) security (this is a result of the >> Canetti-Krawczyk proof that >> CK security implies UC security when a client confirmation step >> is included). >> >> Note on certificates: Since in current practice servers hold >> certificates for >> RSA signature keys rather than for static DH keys, the >> certificate field in the >> above protocol will be implemented by a pair consisting of (i) >> the server's RSA >> signature certificate and (ii) the server's signature using this >> RSA key on the >> server's static public DH key g^s. The latter signature by the >> server is >> performed only when a new static DH key is created (how often >> this happens and >> how many such keys are created is completely up to the server - >> it has the >> advantage that these keys can be changed often to increase >> security against >> leaked keys). This use of RSA also enjoys the high efficiency of RSA >> verification for the client. >> The handling of Client certificates would be similar. >> >> Note on forward security (a.k.a. as PFS for Perfect Forward >> Security): >> PFS is provided by the (mandatory) use of ephemeral >> Diffie-Hellman keys. >> The meaning of PFS is that an attacker that finds the (long-term) >> static >> private keys of the parties cannot compromise past session keys. >> Without the >> ServerFinished message the above protocol ensures forward secrecy >> against >> passive attackers (i.e., for sessions where the attacker did not >> choose g^y). >> With ServerFinished, PFS holds also against active attackers. A >> similar >> consideration applies to ClientFinished. >> >> Client certificates in the first message: We note that in cases >> where client >> certificates can be sent in the clear in the first message of the >> protocol, one >> can provide PFS and mutual authentication in a 1-RTT at >> essentially the same >> cost of an unauthenticated DH exchange (i.e., a cost of little >> more than two >> exponentiations). In such a setting one can also obtain mutual >> authentication in >> a 0-RTT protocol (with forward secrecy with respect to the >> client's key). >> These options, however, require HMQV-like mechanisms and may >> raise IP issues (this >> can be investigated further if the WG is interested). >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell:+1 (647) 867-5658 | US:+1 (415) 690-7363 > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------020606020404030800070309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Great - looking forward to the technical write-up, when it becomes available.

One quick question: if I remember correctly from your original OPTLS sketch, you paid some tribute to a "modus operandi" that includes client authentication as well (i.e., making this into a mutually authenticated key agreement scheme). I would be curious whether this is still on the table and, if so, whether this would also follow the same online signing approach you sketched below for the server. Apologies in case I missed some of this finer detail (hence, my interest in having a concise overall and technically complete description).

While I do appreciate lots of this is "simply" cryptographic engineering, I do think you would have to agree that TLS has a mixed record here. Hence, some reflection and careful analysis seems to be in order, in addition to the great contributions you made yourself so far.

Best regards, Rene

On 3/24/2015 11:11 AM, Hugo Krawczyk wrote:
Hi Rene,

We are working on such a write up as  we speak. Exactly because the details matter and we have been changing them to adapt to the WG requirements and preferences then the writing has been delayed. We are now converging to a protocol that the people in the interim meeting were quite happy with. It is in the same spirit of OPTLS but it is not signature-less, i.e., semi-static keys for the servers are now signed with online signatures that prove freshness by including the client's nonce under the signature.

We should have something decent to post in two weeks.
But let me note that there is nothing revolutionary in the protocol - it is crypto engineering with well understood components, not inventing new fundamental pieces.

Hugo


On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik <rstruik.ext@gmail.com> wrote:
Hi Hugo:

In your email of October 31, 2014 (see below), you introduced the OPTLS protocol to TLS. At the time, you omitted some details, since you simply wished to socialize the ideas. You did emphasize, though, that details matter and put forward that you were working on flashing out the full details of the protocol and security proof.

After a few months of radio silence (to me), the protocol seems to be on the radar screen for discussion with TLS again. It would therefore be good to have a stable reference that describes this in full technical detail and makes this a stable and solid source for the cryptographic community to look at and reference.

I do think that OPTLS has interesting features, perhaps also outside TLS, but would like to give this a thorough and critical look first (and invite others to do so as well). For this, it would help to have something beyond some emails on the TLS list and some "flashed out" draft spec Eric Rescorla worked on earlier this week (which, although useful, may change over time).  Having a stable document would make this more appealing to study and discuss in a wider audience, esp. for important potential use cases.

If you have a paper (e.g., one you could post on the IACR ePrint server), that would be great. {Rest assured, this does not have to have the same size as your 2005 paper on HMQV for it to be useful.}

Best regards, Rene

==
"The presentation is sketchy and omits the exact procedure for key derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof."
On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. 
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as optional,
mandatory, or simply remove without changing the core cryptographic security of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism). 

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]       -------->
                                           ServerHello  
                                           ServerKeyShare 
                                           ServerCertificate* [K1]
                                           ServerFinished [K2]
                       <--------           ServerData* [K2]
ClientFinished* [K2]   -------->


            Protected Application Data [K3]
                       <------->



1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to derive key material for protection of
application data.  This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from  both g^{xs} and g^{xy} similarly to K2, but its derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is sent
encrypted under key K0 derived from g^{xs}. 
The rest of the protocol is identical to the above. 
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included). 

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in the
above protocol will be implemented by a pair consisting of (i) the server's RSA
signature certificate and (ii) the server's signature using this RSA key on the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client. 
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.  A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key). 
These options, however, require HMQV-like mechanisms and may raise IP issues (this
can be investigated further if the WG is interested).



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------020606020404030800070309-- From nobody Tue Mar 24 08:31: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 D46CE1A8911 for ; Tue, 24 Mar 2015 08:31:51 -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 O2hjUnGNk28m for ; Tue, 24 Mar 2015 08:31:50 -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 0800B1A891D for ; Tue, 24 Mar 2015 08:31:38 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so143450092lbc.2 for ; Tue, 24 Mar 2015 08:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=mZad591Yi2CYX5gFNKpaBLFX5iufIwvlMJacjmSrs3w=; b=THttRbWFPQqknM1Vy3GVvtL5p48tmLPSaUOdq8BRDsXNRDe90rFD7ZQ+1EOohxwWfY dewTw9pZVqr0jlpJSqlsaVI9YHdwhhCLMPj69DWj3QP+bCqxkTuCIi4QpzeDQgkncxhX 2g6alsQLIonzd7yzqfQkQli4NPDEpNQ0c+2DFYl5/jBCRip6dKhJuGdhgqKpLlekGlro HlLZrXYdd8Pey3TC5sBP8tjwcK/6UwR37mLscK5bgGZaYnatkJBMP9ltcvYlqcgjaqaC ELFQNjd8vI5CoN8WuQ24mmduoNj0gHKZsEwm7SETGe6GreOiZvr6xvvhSzuoXhXICJvg wC/A== X-Received: by 10.152.178.164 with SMTP id cz4mr4171393lac.39.1427211096557; Tue, 24 Mar 2015 08:31:36 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Tue, 24 Mar 2015 08:31:06 -0700 (PDT) In-Reply-To: <20150324140344.GA797@LK-Perkele-VII> References: <1427123147.19595.62.camel@redhat.com> <1427185709.3200.23.camel@redhat.com> <20150324140344.GA797@LK-Perkele-VII> From: Hugo Krawczyk Date: Tue, 24 Mar 2015 11:31:06 -0400 X-Google-Sender-Auth: IAbDiBF9sRM0T4AiABzAwFGkTwk Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113406f46e10c805120a7a9f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:31:52 -0000 --001a113406f46e10c805120a7a9f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 24, 2015 at 10:03 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Mar 24, 2015 at 09:28:29AM +0100, Nikos Mavrogiannopoulos wrote: > > On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote: > > > > > > > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B > > > - Forward secrecy (PFS) is now mandatory. > > > > > > - The protocol accommodate a 0-RTT mode. > > > > > > > > > These two changes can only be implemented via Diffie-Hellman > > > transforms (in theory, any CCA-secure public key encryption can be > > > used but (EC)DH is the only currently practical instantiation in this > > > setting). In particular, 0-RTT requires supporting semi-static DH key= s > > > for the server. All that ekr draft does is to build a protocol where > > > PFS is supported, 0-RTT is supported, semi-static keys are supported, > > > and TLS-type signatures are supported in any case where the client > > > does not have a cached semi-static key of the server. The beauty of > > > it, if I can say so, is that all these modes are just subsets of a > > > single protocol with a single crypto logic and uniform specification > > > (which also covers uniformly PSK and resumption). > > > > So if I understand well the additional semi-static key is to support th= e > > 0-rtt case only, and otherwise it should be simply a copy of the > > ephemeral key? I cannot say I fully follow the protocol in all possible > > scenarios. It would be nice to have a message flow of the interactions > > for the DH key exchange in all the cases (e.g., PSK) either as an > > appendix or the main text. As we are moving to non-widely known key > > exchanges it makes sense to document them clearly, or at least link to > > documents which define them. > > From what I can understand, it adds interrim server DH key, which server > signs (which may be the same as the server eph. key), computes DH of > both with client eph. key and mixes those to become session keys > (the interrim key can be reused to become 0RTT key for the next > connection). > > So roughly: > - Client: C_pub_e > - Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages) > - 0RTT key: F(DH( > =E2=80=8B=E2=80=8B > S_pub_s_prev, C_pub_e) > - Session keys: G( > =E2=80=8B=E2=80=8B > DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e)) > =E2=80=8BYup. That's the basic idea. In the case that there is no =E2=80=8B=E2=80=8BS_pub_s_prev cached at the c= lient (hence not in 0-RTT mode), one can save one exponentiation in the computation of session keys by making the new S_pub_s ephemeral, or equal to S_pub_e. In this case DH(S_pub_s, C_pub_e) =3D DH(S_pub_e, C_pub_e) hence requiring a single exponentiation. This is as efficient as it gets if you want to use online signatures for freshness and also provide PFS. (Note that you are getting PFS by virtue of S_sub_s being ephemeral, i.e., used for a single session.) Those happy with the signature mode of TLS 1.3 prior to the inclusion of OPTLS techniques should be happy with the above ephemeral-only mode. It is essentially equivalent to what was there before except that it is structured to match the overall logic of OPTLS. > > To me, this looks to lose all the benefits of of offline version: > - The offline version is two-level key scheme, this isn't. > - This version is quite a bit slower unless you disable 0RTT. > - The offline version avoids server to have implement online > signature, simplifying the code a good bit (especially if the > signature is apparently intentionally made difficult, like ECDSA). > =E2=80=8BI agree with your sentiment. These were all advantages of the orig= inal OPTLS but people raised objections to offline signatures=E2=80=8B =E2=80=8Bso we had to keep as many of the original advantages while resorti= ng to online signatures. Still, there are significant advantages in providing a simple and uniform structure to all the modes of the protocol (0-RTT, cached server's semi-static key at the client, ephemeral-only server key, and pre-shared key with and without PFS). Moreover, the protocol is already structured for possible future adaptations to the case of offline signatures (possibly eliminating all signatures other than for certificate verification) and/or use of DH certificates. Hugo > > > -Ilari > --001a113406f46e10c805120a7a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 24, 2015 at 10:03 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Tu= e, Mar 24, 2015 at 09:28:29AM +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote:
>
>
> > =E2=80=8BTwo important things change in TLS 1.3:=E2=80=8B
> > - Forward secrecy (PFS) is now mandatory.
> >
> > - The protocol accommodate a 0-RTT mode.
> >
> >
> > These two changes can only be implemented via Diffie-Hellman
> > transforms (in theory, any CCA-secure public key encryption can b= e
> > used but (EC)DH is the only currently practical instantiation in = this
> > setting). In particular, 0-RTT requires supporting semi-static DH= keys
> > for the server. All that ekr draft does is to build a protocol wh= ere
> > PFS is supported, 0-RTT is supported, semi-static keys are suppor= ted,
> > and TLS-type signatures are supported in any case where the clien= t
> > does not have a cached semi-static key of the server. The beauty = of
> > it, if I can say so, is that all these modes are just subsets of = a
> > single protocol with a single crypto logic and uniform specificat= ion
> > (which also covers uniformly PSK and resumption).
>
> So if I understand well the additional semi-static key is to support t= he
> 0-rtt case only, and otherwise it should be simply a copy of the
> ephemeral key? I cannot say I fully follow the protocol in all possibl= e
> scenarios. It would be nice to have a message flow of the interactions=
> for the DH key exchange in all the cases (e.g., PSK) either as an
> appendix or the main text. As we are moving to non-widely known key > exchanges it makes sense to document them clearly, or at least link to=
> documents which define them.

From what I can understand, it adds interrim server DH key, whi= ch server
signs (which may be the same as the server eph. key), computes DH of
both with client eph. key and mixes those to become session keys
(the interrim key can be reused to become 0RTT key for the next
connection).

So roughly:
- Client: C_pub_e
- Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages)
- 0RTT key: F(DH(
=E2=80=8B=E2=80=8B
S_pub_s_= prev, C_pub_e)
- Session keys: G(
=E2=80=8B=E2=80=8B
DH(S_pu= b_s, C_pub_e), DH(S_pub_e, C_pub_e))

=E2=80=8BYup. That's the basic idea.
In the case that there is no =E2=80=8B=E2=80=8BS_pub_s_prev= cached at the client (hence not in 0-RTT mode), one can save one exponenti= ation in the computation of session keys by making the new S_pub_s ephemera= l, or equal to S_pub_e.
In this case=C2=A0 DH(S_pub_s, C_pub_e) =3D DH(= S_pub_e, C_pub_e)
hence requiring a single exponentiation. This is as ef= ficient as it gets if you want to use online signatures for freshness and a= lso provide PFS.
(Note that you are gett= ing PFS by virtue of S_sub_s being ephemeral, i.e., used for a single sessi= on.)

Those happy with the signature mode of TLS 1.3 prior to the inclusion of = OPTLS techniques should be happy with the above ephemeral-only mode. It is = essentially equivalent to what was there before except that it is structure= d to match the overall logic of OPTLS.



To me, this looks to lose all the benefits of of offline version:
- The offline version is two-level key scheme, this isn't.
- This version is quite a bit slower unless you disable 0RTT.
- The offline version avoids server to have implement online
=C2=A0 signature, simplifying the code a good bit (especially if the
=C2=A0 signature is apparently intentionally made difficult, like ECDSA).

=E2=80=8BI agree with you= r sentiment. These were all advantages of the original OPTLS but people rai= sed objections to offline signatures=E2=80=8B
=C2=A0
=E2=80=8Bso we had to keep as many of the original advantages while= resorting to online signatures.
Still, = there are significant advantages in providing a simple and uniform structur= e to all the modes of the protocol (0-RTT, cached server's semi-static = key at the client, ephemeral-only server key, and pre-shared key with and w= ithout PFS).

Moreover, the protocol = is already structured for possible future adaptations to the case of offlin= e signatures (possibly eliminating all signatures other than for certificat= e verification)=C2=A0 and/or use of DH certificates.

Hugo




-Ilari

--001a113406f46e10c805120a7a9f-- From nobody Tue Mar 24 08:40: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 565CA1A893E for ; Tue, 24 Mar 2015 08:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPsi2K0OJfIK for ; Tue, 24 Mar 2015 08:40:39 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010: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 09FA11A896B for ; Tue, 24 Mar 2015 08:40:29 -0700 (PDT) Received: by lbbsy1 with SMTP id sy1so143915734lbb.1 for ; Tue, 24 Mar 2015 08:40:27 -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:from:date:message-id :subject:to:cc:content-type; bh=XivLCES712tUiO3tQb7vJTE/Lmeyl3aR33LCZkUE0KU=; b=YhoFXO24I2Af6mtiWcT/eJB7+mqtuMtvjTdGlP1YYBmcVSf+0lDH8km5mNTunswliw LZP25Lk8uG+eMYnzvEuAk2XjD0107gIg/1cLuEpW/LFA8NoQ7SmydDIzWUSTkFGBnvEx Dq46qE437VFXR29nChgyEIXs13faoc7th2atWyMza1hTH3jfvhPnJQLXKrSBrjXOI2A4 MybhnUUP0MZlDVP2eFE4vJYJ7dE7T64V1g3EZEm270yX9/QOcirOk+xUfT3TsAFR61Zs +lDA+phCchCBhVvCPaHqTLszfWzYyb+quEV9WX3bnMekZ/wUZVk64H5SVc4TXzkUSeLj B1wA== X-Received: by 10.152.206.70 with SMTP id lm6mr4346448lac.35.1427211627460; Tue, 24 Mar 2015 08:40:27 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Tue, 24 Mar 2015 08:39:57 -0700 (PDT) In-Reply-To: <5511833B.5070108@gmail.com> References: <551161E6.10900@gmail.com> <5511833B.5070108@gmail.com> From: Hugo Krawczyk Date: Tue, 24 Mar 2015 11:39:57 -0400 X-Google-Sender-Auth: IwHVwMgd8159MpGdbrpQQ9LDCRw Message-ID: To: Rene Struik Content-Type: multipart/alternative; boundary=001a1134a00a13006305120a9a33 Archived-At: Cc: "tls@ietf.org" , Hoeteck Wee Subject: Re: [TLS] OPTLS: Signature-less 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, 24 Mar 2015 15:40:45 -0000 --001a1134a00a13006305120a9a33 Content-Type: text/plain; charset=UTF-8 I absolutely agree with you and I am not asking to take my word on the cryptographic design. This all needs review. I am just saying that reviewers will not have to cope with some hard-to-digest revolutionary ideas. And, yes, we hope to improve on TLS mixed record... Hugo On Tue, Mar 24, 2015 at 11:31 AM, Rene Struik wrote: > Great - looking forward to the technical write-up, when it becomes > available. > > One quick question: if I remember correctly from your original OPTLS > sketch, you paid some tribute to a "modus operandi" that includes client > authentication as well (i.e., making this into a mutually authenticated key > agreement scheme). I would be curious whether this is still on the table > and, if so, whether this would also follow the same online signing approach > you sketched below for the server. Apologies in case I missed some of this > finer detail (hence, my interest in having a concise overall and > technically complete description). > > While I do appreciate lots of this is "simply" cryptographic engineering, > I do think you would have to agree that TLS has a mixed record here. Hence, > some reflection and careful analysis seems to be in order, in addition to > the great contributions you made yourself so far. > > Best regards, Rene > > > On 3/24/2015 11:11 AM, Hugo Krawczyk wrote: > > Hi Rene, > > We are working on such a write up as we speak. Exactly because the > details matter and we have been changing them to adapt to the WG > requirements and preferences then the writing has been delayed. We are now > converging to a protocol that the people in the interim meeting were quite > happy with. It is in the same spirit of OPTLS but it is not signature-less, > i.e., semi-static keys for the servers are now signed with online > signatures that prove freshness by including the client's nonce under the > signature. > > We should have something decent to post in two weeks. > But let me note that there is nothing revolutionary in the protocol - it > is crypto engineering with well understood components, not inventing new > fundamental pieces. > > Hugo > > > On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik > wrote: > >> Hi Hugo: >> >> In your email of October 31, 2014 (see below), you introduced the OPTLS >> protocol to TLS. At the time, you omitted some details, since you simply >> wished to socialize the ideas. You did emphasize, though, that details >> matter and put forward that you were working on flashing out the full >> details of the protocol and security proof. >> >> After a few months of radio silence (to me), the protocol seems to be on >> the radar screen for discussion with TLS again. It would therefore be good >> to have a stable reference that describes this in full technical detail and >> makes this a stable and solid source for the cryptographic community to >> look at and reference. >> >> I do think that OPTLS has interesting features, perhaps also outside TLS, >> but would like to give this a thorough and critical look first (and invite >> others to do so as well). For this, it would help to have something beyond >> some emails on the TLS list and some "flashed out" draft spec Eric Rescorla >> worked on earlier this week (which, although useful, may change over >> time). Having a stable document would make this more appealing to study >> and discuss in a wider audience, esp. for important potential use cases. >> >> If you have a paper (e.g., one you could post on the IACR ePrint server), >> that would be great. {Rest assured, this does not have to have the same >> size as your 2005 paper on HMQV for it to be useful.} >> >> Best regards, Rene >> >> == >> "The presentation is sketchy and omits the exact procedure for key >> derivation. The latter is a crucial component for the security of the >> protocol, but before getting into these details we want to get a sense of >> whether the WG is interested in this approach. In the meantime, Hoeteck Wee >> and myself are working on the details of the protocol and the security >> proof." >> >> On 10/31/2014 8:54 PM, Hugo Krawczyk wrote: >> >> During the TLS interim meeting of last week (Oct 22 2014) I suggested >> that TLS >> 1.3 should abandon signature-based authentication (other than for >> certificates) >> and be based solely on a combination of ephemeral Diffie-Hellman for PFS >> and >> static Diffie-Hellman for authentication. This has multiple benefits >> including >> major performance gain (by replacing the per-handshake RSA signature by >> the >> server with a much cheaper elliptic curve exponentiation), compatibility >> with >> the mechanisms required for forward secrecy, natural accommodation of a >> 0-RTT >> option, and a simple extension without signatures for client >> authentication. >> >> Below I present a schematic representation of the proposed protocol >> referred >> to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three. >> The presentation is sketchy and omits the exact procedure for key >> derivation. >> The latter is a crucial component for the security of the protocol, but >> before getting into these details we want to get a sense of whether the >> WG is >> interested in this approach. In the meantime, Hoeteck Wee and myself are >> working on the details of the protocol and the security proof. >> >> We describe a setting with optional 0-RTT and server-only authentication. >> Client authentication can be added as a further option or as an extension >> (similar to the current 1.3 proposal) - see below. >> >> NOTATION AND TERMINOLOGY: >> >> [K] symbols represent pointers to key material whose exact derivation is >> not >> included here except for specifying the basic DH values from which the >> key is >> derived (actual derivation will include further information similar to the >> extended hash mechanisms or SessionHash proposal considered for 1.3). >> Asterisks represent optional fields that the WG can decide to leave as >> optional, >> mandatory, or simply remove without changing the core cryptographic >> security of >> the protocol. All references to encryption mean "authenticated encryption" >> using the encrypt-then-mac paradigm (or any other secure AEAD >> mechanism). >> >> KeyShare's represent ephemeral Diffie-Hellman values exchanged by the >> parties. >> All the public key and Diffie-Hellman operations are assumed to happen >> over a >> cyclic group with generator g of order q (typically implemented by an >> elliptic >> curve group). We use multiplicative notation where ^ denotes >> exponentiation as >> in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), >> etc. >> Omitted from the current high level description is a mechanism for >> testing group >> membership of DH values or cofactor exponentiation (the specific mechanism >> depends on the group type and is typically very efficient for elliptic >> curves). >> >> SERVER PUBLIC KEY AND CERTIFICATE: >> >> The server has a long term private-public key pair denoted by (s,g^s) >> where >> s is uniform random in [0..q-1] (we refer to s and g^s as "static keys"). >> We assume that the server has a certificate that includes the server's >> public >> key g^s and a CA-signed binding of this key to the server's identity. >> We discuss the implementation of such certificates below. >> >> PROTOCOL OPTLS: >> >> ClientHello >> ClientKeyShare >> ClientData* [K0] --------> >> ServerHello >> ServerKeyShare >> ServerCertificate* [K1] >> ServerFinished [K2] >> <-------- ServerData* [K2] >> ClientFinished* [K2] --------> >> >> >> Protected Application Data [K3] >> <-------> >> >> >> >> 1-RTT CASE: >> >> The basic 1-RTT case omits the ClientData* field. It includes a >> ClientKeyShare >> g^x and a ServerKeyShare g^y and an optional (encrypted) server >> certificate. >> If the certificate is sent (it can be omitted if the client has indicated >> that >> it knows the server key as in the case in the 0-RTT scenario) and is >> encrypted, >> the encryption key K1 is derived from g^{xy}. >> >> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is >> used to >> authenticate-encrypt the ServerFinished and ClientFinished messages (which >> include a hash of the previous traffic) and to encrypt data from the >> server if >> such data is piggybacked to the second message. >> >> Key K3 is the "application key" used to derive key material for >> protection of >> application data. This key material will include (directional) >> Authenticated >> Encryption keys and, possibly, keys for derivation of further re-key >> material. >> K3 is computed from both g^{xs} and g^{xy} similarly to K2, but its >> derivation >> will be different than K2, e.g., using a separating key expansion >> technique. >> >> SUPPORT FOR 0-RTT: >> >> The above protocol is compatible with a 0-RTT protocol such as QUIC. In >> this >> case, the client is assumed to have information about the server's public >> key >> and other security parameters. The server is assumed to have some >> mechanism in >> place for detecting replay (e.g., via timestamps, stored client nonces, >> etc.). >> The resulting protocol is as described above where the ClientData field >> is sent >> encrypted under key K0 derived from g^{xs}. >> The rest of the protocol is identical to the above. >> Note: In this case, ServerCertificate is not sent as the client had to >> know >> the server's public key before the first message (one can imagine a >> setting >> where the server may send a different certificate in the second message - >> if >> desired, this can be accommodated too as an option or extension). >> >> CLIENT AUTHENTICATION: >> >> Client authentication can be supported via an option or extension. It >> would >> include a client certificate for a static DH key g^c sent in the third >> message >> (the certificate can be encrypted under key K2 to provide client's >> identity >> protection). In this case, the key for computing the ClientFinished >> message and >> the application key K3 would be derived from a combination of the values >> g^xy, >> g^xs, g^yc (and possibly also g^{cs}). >> >> NOTES: >> >> Note on Finished messages: The above spec sets ServerFinished as >> mandatory and >> ClientFinished as optional. The latter option is needed for a 1-RTT >> protocol. >> In principle, both Finished messages could be omitted and still obtain >> security >> via implicit authentication (assuming the inputs to key derivation are >> chosen >> appropriately). But given the advantages of ServerFinished for providing >> explicit authentication, key confirmation, and active forward secrecy (see >> below), it seems advisable to always include it. Including ClientFinished >> provides key confirmation from client and also explicit client >> authentication >> when client certificate is included. ClientFinished also provides >> Universal >> Composable (UC) security (this is a result of the Canetti-Krawczyk proof >> that >> CK security implies UC security when a client confirmation step is >> included). >> >> Note on certificates: Since in current practice servers hold certificates >> for >> RSA signature keys rather than for static DH keys, the certificate field >> in the >> above protocol will be implemented by a pair consisting of (i) the >> server's RSA >> signature certificate and (ii) the server's signature using this RSA key >> on the >> server's static public DH key g^s. The latter signature by the server is >> performed only when a new static DH key is created (how often this >> happens and >> how many such keys are created is completely up to the server - it has the >> advantage that these keys can be changed often to increase security >> against >> leaked keys). This use of RSA also enjoys the high efficiency of RSA >> verification for the client. >> The handling of Client certificates would be similar. >> >> Note on forward security (a.k.a. as PFS for Perfect Forward Security): >> PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys. >> The meaning of PFS is that an attacker that finds the (long-term) static >> private keys of the parties cannot compromise past session keys. Without >> the >> ServerFinished message the above protocol ensures forward secrecy against >> passive attackers (i.e., for sessions where the attacker did not choose >> g^y). >> With ServerFinished, PFS holds also against active attackers. A similar >> consideration applies to ClientFinished. >> >> Client certificates in the first message: We note that in cases where >> client >> certificates can be sent in the clear in the first message of the >> protocol, one >> can provide PFS and mutual authentication in a 1-RTT at essentially the >> same >> cost of an unauthenticated DH exchange (i.e., a cost of little more than >> two >> exponentiations). In such a setting one can also obtain mutual >> authentication in >> a 0-RTT protocol (with forward secrecy with respect to the client's >> key). >> These options, however, require HMQV-like mechanisms and may raise IP >> issues (this >> can be investigated further if the WG is interested). >> >> >> >> _______________________________________________ >> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >> >> >> >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > --001a1134a00a13006305120a9a33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I absolutely agree with you and I am not asking= to take my word on the cryptographic design. This all needs review. I am j= ust saying that reviewers will not have to cope with some hard-to-digest re= volutionary ideas. And, yes, we hope to improve on TLS mixed record...
<= br>
Hugo

On Tue, Mar 24, 2015 at 11:31 AM, Rene Struik <= rstruik.ext@gmail.com> wrote:
=20 =20 =20
Great - looking forward to the technical write-up, when it becomes available.

One quick question: if I remember correctly from your original OPTLS sketch, you paid some tribute to a "modus operandi" t= hat includes client authentication as well (i.e., making this into a mutually authenticated key agreement scheme). I would be curious whether this is still on the table and, if so, whether this would also follow the same online signing approach you sketched below for the server. Apologies in case I missed some of this finer detail (hence, my interest in having a concise overall and technically complete description).

While I do appreciate lots of this is "simply" cryptographi= c engineering, I do think you would have to agree that TLS has a mixed record here. Hence, some reflection and careful analysis seems to be in order, in addition to the great contributions you made yourself so far.

Best regards, Rene


On 3/24/2015 11:11 AM, Hugo Krawczyk wrote:
Hi Rene,

We are working on such a write up as=C2=A0 we speak. Exactly because the details matter and we have been changing them to adapt to the WG requirements and preferences then the writing has been delayed. We are now converging to a protocol that the people in the interim meeting were quite happy with. It is in the same spirit of OPTLS but it is not signature-less, i.e., semi-static keys for the servers are now signed with online signatures that prove freshness by including the client's nonce under the signature.

We should have something decent to post in two weeks.
But let me note that there is nothing revolutionary in the protocol - it is crypto engineering with well understood components, not inventing new fundamental pieces.

Hugo


On Tue, Mar 24, 2015 at 9:08 AM, Rene Struik <rstruik.ext@gmail.com> wrote:
Hi Hugo:

In your email of October 31, 2014 (see below), you introduced the OPTLS protocol to TLS. At the time, you omitted some details, since you simply wished to socialize the ideas. You did emphasize, though, that details matter and put forward that you were working on flashing out the full details of the protocol and security proof.

After a few months of radio silence (to me), the protocol seems to be on the radar screen for discussion with TLS again. It would therefore be good to have a stable reference that describes this in full technical detail and makes this a stable and solid source for the cryptographic community to look at and reference.

I do think that OPTLS has interesting features, perhaps also outside TLS, but would like to give this a thorough and critical look first (and invite others to do so as well). For this, it would help to have something beyond some emails on the TLS list and some "flashed out" draft spec Eric Rescorla worked o= n earlier this week (which, although useful, may change over time).=C2=A0 Having a stable document would make thi= s more appealing to study and discuss in a wider audience, esp. for important potential use cases.

If you have a paper (e.g., one you could post on the IACR ePrint server), that would be great. {Rest assured, this does not have to have the same size as your 2005 paper on HMQV for it to be useful.}

Best regards, Rene

=3D=3D
"The presentation is sketchy and omits the exact procedure for key derivation. The latter is a crucial component for the security of the protocol, but before getting into these details we want to get a sense of whether the WG is interested in this approach. In the meantime, Hoeteck Wee and myself are working on the details of the protocol and the security proof."
On 10/31/2014 8:54 PM, Hugo Krawczyk wrote:
During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.

Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.=C2=A0
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.

We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.

NOTATION AND TERMINOLOGY:

[K] symbols represent pointers to key material whose exact derivation is not
included here except for specifying the basic DH values from which the key is
derived (actual derivation will include further information similar to the
extended hash mechanisms or SessionHash proposal considered for 1.3).
Asterisks represent optional fields that the WG can decide to leave as optional,
mandatory, or simply remove without changing the core cryptographic security of
the protocol. All references to encryption mean "authenticated encryption"
using the encrypt-then-mac paradigm (or any other secure AEAD mechanism).=C2=A0

KeyShare's represent ephemeral Diffie-Hellman values exchanged by the parties.
All the public key and Diffie-Hellman operations are assumed to happen over a
cyclic group with generator g of order q (typically implemented by an elliptic
curve group). We use multiplicative notation where ^ denotes exponentiation as
in g^x, g^{xy} (here xy denotes multiplication of the scalars x and y), etc.
Omitted from the current high level description is a mechanism for testing group
membership of DH values or cofactor exponentiation (the specific mechanism
depends on the group type and is typically very efficient for elliptic curves).

SERVER PUBLIC KEY AND CERTIFICATE:

The server has a long term private-public key pair denoted by (s,g^s) where
s is uniform random in [0..q-1] (we refer to s and g^s as "static keys").
We assume that the server has a certificate that includes the server's public
key g^s and a CA-signed binding of this key to the server's identity.
We discuss the implementation of such certificates below.

PROTOCOL OPTLS:

ClientHello
ClientKeyShare
ClientData* [K0]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -------->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerHello=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerKeyShare=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerCertificate* [K1]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ServerFinished [K2]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 <--------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ServerData* [K2]
ClientFinished* [K2]=C2=A0=C2=A0 -------->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Protected Application Data [K3]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 <------->



1-RTT CASE:

The basic 1-RTT case omits the ClientData* field. It includes a ClientKeyShare
g^x and a ServerKeyShare g^y and an optional (encrypted) server certificate.
If the certificate is sent (it can be omitted if the client has indicated that
it knows the server key as in the case in the 0-RTT scenario) and is encrypted,
the encryption key K1 is derived from g^{xy}.

Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used to
authenticate-encrypt the ServerFinished and ClientFinished messages (which
include a hash of the previous traffic) and to encrypt data from the server if
such data is piggybacked to the second message.

Key K3 is the "application key" used to= derive key material for protection of
application data.=C2=A0 This key material will include (directional) Authenticated
Encryption keys and, possibly, keys for derivation of further re-key material.
K3 is computed from=C2=A0 both g^{xs} and g^{xy} similarly to K2, but its derivation
will be different than K2, e.g., using a separating key expansion technique.

SUPPORT FOR 0-RTT:

The above protocol is compatible with a 0-RTT protocol such as QUIC. In this
case, the client is assumed to have information about the server's public key
and other security parameters. The server is assumed to have some mechanism in
place for detecting replay (e.g., via timestamps, stored client nonces, etc.).
The resulting protocol is as described above where the ClientData field is sent
encrypted under key K0 derived from g^{xs}.=C2=A0=
The rest of the protocol is identical to the above.=C2=A0
Note: In this case, ServerCertificate is not sent as the client had to know
the server's public key before the first message (one can imagine a setting
where the server may send a different certificate in the second message - if
desired, this can be accommodated too as an option or extension).

CLIENT AUTHENTICATION:

Client authentication can be supported via an option or extension. It would
include a client certificate for a static DH key g^c sent in the third message
(the certificate can be encrypted under key K2 to provide client's identity
protection). In this case, the key for computing the ClientFinished message and
the application key K3 would be derived from a combination of the values g^xy,
g^xs, g^yc (and possibly also g^{cs}).

NOTES:

Note on Finished messages: The above spec sets ServerFinished as mandatory and
ClientFinished as optional. The latter option is needed for a 1-RTT protocol.
In principle, both Finished messages could be omitted and still obtain security
via implicit authentication (assuming the inputs to key derivation are chosen
appropriately). But given the advantages of ServerFinished for providing
explicit authentication, key confirmation, and active forward secrecy (see
below), it seems advisable to always include it. Including ClientFinished
provides key confirmation from client and also explicit client authentication
when client certificate is included. ClientFinished also provides Universal
Composable (UC) security (this is a result of the Canetti-Krawczyk proof that
CK security implies UC security when a client confirmation step is included).=C2=A0

Note on certificates: Since in current practice servers hold certificates for
RSA signature keys rather than for static DH keys, the certificate field in the
above protocol will be implemented by a pair consisting of (i) the server's RSA
signature certificate and (ii) the server's signature using this RSA key on the
server's static public DH key g^s. The latter signature by the server is
performed only when a new static DH key is created (how often this happens and
how many such keys are created is completely up to the server - it has the
advantage that these keys can be changed often to increase security against
leaked keys). This use of RSA also enjoys the high efficiency of RSA
verification for the client.=C2=A0
The handling of Client certificates would be similar.

Note on forward security (a.k.a. as PFS for Perfect Forward Security):
PFS is provided by the (mandatory) use of ephemeral Diffie-Hellman keys.
The meaning of PFS is that an attacker that finds the (long-term) static
private keys of the parties cannot compromise past session keys. Without the
ServerFinished message the above protocol ensures forward secrecy against
passive attackers (i.e., for sessions where the attacker did not choose g^y).
With ServerFinished, PFS holds also against active attackers.=C2=A0 A similar
consideration applies to ClientFinished.

Client certificates in the first message: We note that in cases where client
certificates can be sent in the clear in the first message of the protocol, one
can provide PFS and mutual authentication in a 1-RTT at essentially the same
cost of an unauthenticated DH exchange (i.e., a cost of little more than two
exponentiations). In such a setting one can also obtain mutual authentication in
a 0-RTT protocol (with forward secrecy with respect to the client's key).=C2=A0
These options, however, require HMQV-like mechanisms and may raise IP issues (this
can be investigated further if the WG is interested).



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



--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=




--=20
email: rstruik.e=
xt@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363=

--001a1134a00a13006305120a9a33-- From nobody Tue Mar 24 10:02: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 F35D21A9169; Tue, 24 Mar 2015 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-Lj00GUA5_O; Tue, 24 Mar 2015 10:02:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F961A9167; Tue, 24 Mar 2015 10:02:43 -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: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324170243.6257.18639.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 10:02:43 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-pwd-06.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: Tue, 24 Mar 2015 17:02: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 : Secure Password Ciphersuites for Transport Layer Security (TLS) Authors : Dan Harkins Dave Halasz Filename : draft-ietf-tls-pwd-06.txt Pages : 35 Date : 2015-03-24 Abstract: This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-pwd-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-06 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 Tue Mar 24 10:11:34 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 384621A9151 for ; Tue, 24 Mar 2015 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K2TY_ryOXYhx for ; Tue, 24 Mar 2015 10:11:31 -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 081751A9026 for ; Tue, 24 Mar 2015 10:11:31 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id B80FF9005B; Tue, 24 Mar 2015 19:11:28 +0200 (EET) Date: Tue, 24 Mar 2015 19:11:28 +0200 From: Ilari Liusvaara To: "Paterson, Kenny" Message-ID: <20150324171128.GA3561@LK-Perkele-VII> References: <20150323112232.5964828b@pc1.fritz.box> 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: IETF TLS Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:11:33 -0000 On Mon, Mar 23, 2015 at 07:42:26PM +0000, Paterson, Kenny wrote: > > > >We want to accomodate the uptake of ECC, so ... > > > >If RSA keys, then sign handshake with RSA-PSS. > >If ECC keys, then sign handshake with ECDSA. > > Just a quick heads-up with my CFRG hat on. We should soon be making a > start over there on defining signature schemes for use with the curves > that we have now selected; our DH deliberations are nearing completion. > > One quick question for this group: how important is it to you to have > ECDSA - or something very close to it (e.g. a derandomised version) - for > TLS use, and how much appetite is there for adopting schemes that deviate > more significantly from ECDSA (e.g. EdDSA)? My personal view (I have also looked at what this would take): Not important, I would very much like a modern signature system (esp. inversion-free[1]). But I would want: - Both curves usable in the same signature framework. - Only use common hash function propeties for both curves[2], especially for verification interop[3]. Assignments required: - TLS signaturealgorithm codepoint - TLS namedcurve codepoints - OIDs for the signature curves - OIDs for PKIX (Signature,Hash) algorithm pair. All can be done with RFC & expert review. [1] Inversions are not only highly annoying to implement safe way, but are also pretty slow. [2] Good test: Does this work with standard-issue SHA-512? [3] This is for the case if anything happens to the primary algorithm. -Ilari From nobody Tue Mar 24 10:29: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 B62721AC3CF for ; Tue, 24 Mar 2015 10:29:51 -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 CER2owxFuSwW for ; Tue, 24 Mar 2015 10:29:48 -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 380CA1A923B for ; Tue, 24 Mar 2015 10:29:48 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so145992878lbc.2 for ; Tue, 24 Mar 2015 10:29:46 -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:from:date:message-id :subject:to:cc:content-type; bh=cfpaOcFh7o4LVkYGfnE2HC6GkE+Ip7mtWaNsoAtLJuo=; b=zdZMczlMM2Dq9iApxDD+/nfXdGHz/bUFvqCPVpdLGxOZGHS7ZwVsWqWPih7mY+uqMa IG1N/BhT21fgMMD4j0YRpiq5h/xJmKYIEGPi0L49DSjrrk4gjC4t3mvUxLfSL7G5VTzg c9jSPzHq2BnvYEtCRXTGbIDvg8jJYXHYgWagb5YyOvjjsb95Krbdu3NX+jv52szrKgdv oWAtGaI+YRT6CgZIIbzJnnVj2uRQzrGKnQwazlsAsU7N8OuhohTkcRkTV3sSZVKFYFh6 HIioJuGlIo2O61FIU/3o1JNWkYB0PP/j3d4gqdg2iWlTPYBfoKyvaIUicVoemSOnk3Mx kphg== X-Received: by 10.112.170.100 with SMTP id al4mr4801328lbc.42.1427218185635; Tue, 24 Mar 2015 10:29:45 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.19 with HTTP; Tue, 24 Mar 2015 10:29:15 -0700 (PDT) In-Reply-To: <20150324121632.GA28552@LK-Perkele-VII> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> From: Hugo Krawczyk Date: Tue, 24 Mar 2015 13:29:15 -0400 X-Google-Sender-Auth: BEbwnk9aPeHWZJ02_yadqXUvyHk Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c23686f8cbe305120c208a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:29:51 -0000 --001a11c23686f8cbe305120c208a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHere are some clarifications about HKDF that can help better under= standing its rationale and use in (OP)TLS. Note: all places where I say random it can (and sometimes should) be replaced by pseudo-random meaning indistinguishable from a uniform random string. - HKDF is standardized by NIST (as an *approved* KDF mechanism) in SP-800-56C where it is explicitly stated that HKDF complies with this standard: "IETF RFC 5869 [10] describes an instantiation of the above extraction-then-expansion key derivation procedure using HMAC for the extraction and expansion steps. For extensive rationale on the key derivation through the extraction-then-expansion procedure specified in this Recommendation see [11]." For those interested, [11] appeared in Crypto 2010 and is here http://eprint.iacr.org/2010/264. - HKDF uses a two-step mechanism by which one first extracts randomness from a possibly non-uniform secret input to create a uniformly random string that is then used with a regular PRF to generate keying material. In (OP)TLS we denote the two steps as HKDF-Extract and HKDF-Expand. The rationale of the extraction part is to concentrate the "secret entropy" of the input on a single strong cryptographic key (from which more keys can be derived). - HKDF uses HMAC for both extract and expand but it could use, in principle, any regular PRF (including those from NIST) for expansion. Extraction is trickier since it is not a generic property of PRFs. The reason to use HMAC for it is that the HMAC construction has properties that support the extraction functionality under reasonable cryptographic assumptions. - Skipping the extraction property would require keying a PRF with a non-uniform key in which case the usual properties of PRF cannot be guaranteed as these properties assume a uniform random key. In TLS with RSA this was not a problem since the key transported under RSA was chosen as a random uniform string= . When using a DH key or passphrase this is not the case. - Beyond the important cryptographic reasons for the extraction step, this also solves the problem of having to adapt the size of the secret input to that of a length of the key in the PRF: for example, how do you key AES-256 with = a point on a 512 elliptic curve? Even with a 256 curve you would require point compression which you may or may not want to use (I hope this comment does not open a discussion of EC point representations :-). - The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE SAME as in previous TLS. It even has the same feedback mode that TLS uses to expand a key (the exact inputs to the iterations changes a bit but nothing major). - There is no need for ultimate performance in the key derivation in TLS. These operations are relative minor compared to the algebraic operations. - There is nothing that ties HKDF to OPTLS in a fundamental way other than it supports the provability of the protocol, hence improving the confidence on its design. In particular, it supports a clean hierarchical key derivation for all the protocol modes. Hugo =E2=80=8B On Tue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote: > > > > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov > wrote: > > > > > > Please note that at least some of these can be FIPS 140 tested (in > particular, TLS PRF). Suite B expects the use of these approved KDFs. > > > > > > While NIST is perhaps too prolific with these, I feel that we should > look into standard KDFs. There are test vectors, verifications systems, > existing implementations=E2=80=A6 > > > > If such a KDF is needed for Suite-B, then it makes sense for Suite-B > ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM= . > > > > Why not include a different PRF in those suites that have > non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever > signature scheme CFRG are going to recommend? > > Or even special Suite B ciphersuites. I think there are only 2 of > those. > > - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256 > - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384 > > The basic idea being: They who care can implement that. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c23686f8cbe305120c208a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHere are some clarifications about HKD= F that can help better understanding its
rationale and use in (OP)TLS.
Note: all places where I say random it can (and sometimes should) be = replaced by
pseudo-random meaning indistinguishable from a uniform rando= m string.

- HKDF is standardized by NIST (as an *approved* KDF mecha= nism) in SP-800-56C
=C2=A0 where it is explicitly stated that HKDF compl= ies with this standard:
=C2=A0 "IETF RFC 5869 [10] describes an in= stantiation of the above
=C2=A0 extraction-then-expansion key derivation= procedure using HMAC for the
=C2=A0 extraction and expansion steps. For= extensive rationale on the key derivation
=C2=A0 through the extraction= -then-expansion procedure specified in this
=C2=A0 Recommendation see [1= 1]." For those interested, [11] appeared in Crypto 2010
=C2=A0 and = is here http:= //eprint.iacr.org/2010/264.

- HKDF uses a two-step mechanism by = which one first extracts randomness from a
=C2=A0 possibly non-uniform s= ecret input to create a uniformly random string that is
=C2=A0 then used= with a regular PRF to generate keying material. In (OP)TLS we denote
= =C2=A0 the two steps as HKDF-Extract and HKDF-Expand. The rationale of the = extraction
=C2=A0 part is to concentrate the "secret entropy" = of the input on a single strong
=C2=A0 cryptographic key (from which mor= e keys can be derived).

- HKDF uses HMAC for both extract and expand= but it could use, in principle, any
=C2=A0 regular PRF (including those= from NIST) for expansion. Extraction is trickier
=C2=A0 since it is not= a generic property of PRFs. The reason to use HMAC for it is
=C2=A0 tha= t the HMAC construction has properties that support the extraction
=C2= =A0 functionality under reasonable cryptographic assumptions.

- Skip= ping the extraction property would require keying a PRF with a non-uniform<= br>=C2=A0 key in which case the usual properties of PRF cannot be guarantee= d as these
=C2=A0 properties assume a uniform random key. In TLS with RS= A this was not a problem
=C2=A0 since the key transported under RSA was = chosen as a random uniform string.
=C2=A0 When using a DH key or passphr= ase this is not the case.
=C2=A0
- Beyond the important cryptographi= c reasons for the extraction step, this also
=C2=A0 solves the problem o= f having to adapt the size of the secret input to that of
=C2=A0 a lengt= h of the key in the PRF: for example, how do you key AES-256 with a
=C2= =A0 point on a 512 elliptic curve? Even with a 256 curve you would require = point
=C2=A0 compression which you may or may not want to use (I hope th= is comment does not
=C2=A0 open a discussion of EC point representations= :-).

- The expansion function of HKDF is HMAC-based and is ESSENTIA= LLY THE SAME as in
=C2=A0 previous TLS. It even has the same feedback mo= de that TLS uses to expand a key
=C2=A0 (the exact inputs to the iterati= ons changes a bit but nothing major).

- There is no need for ultimat= e performance in the key derivation in TLS. These
=C2=A0 operations are = relative minor compared to the algebraic operations.

- There is noth= ing that ties HKDF to OPTLS in a fundamental way other than it
=C2=A0 su= pports the provability of the protocol, hence improving the confidence on=C2=A0 its design. In particular, it supports a clean hierarchical key de= rivation for
=C2=A0 all the protocol modes.
=C2=A0
Hugo
=E2=80= =8B


On T= ue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara <ilari.liusvaara@e= lisanet.fi> wrote:
On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
>
> > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org> wrote:
> >
> > Please note that at least some of these c= an be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of = these approved KDFs.
> >
> > While NIST is perhaps too prolific with these, I feel that we sho= uld look into standard KDFs. There are test vectors, verifications systems,= existing implementations=E2=80=A6
>
> If such a KDF is needed for Suite-B, then it makes sense for Suite-B c= iphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM. >
> Why not include a different PRF in those suites that have non-NIST-app= roved algorithms such as ChaCha20, Curve25519, and whatever signature schem= e CFRG are going to recommend?

Or even special Suite B ciphersuites. I think there are only 2 of those.

- ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
- ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384

The basic idea being: They who care can implement that.


-Ilari

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

--001a11c23686f8cbe305120c208a-- From nobody Tue Mar 24 10:48: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 CE1291A923C; Tue, 24 Mar 2015 10:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 iudAB-9ictW4; Tue, 24 Mar 2015 10:48:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF81A8A17; Tue, 24 Mar 2015 10:48:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A8FF5180205; Tue, 24 Mar 2015 10:46:52 -0700 (PDT) To: radix@twistedmatrix.com, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324174652.A8FF5180205@rfc-editor.org> Date: Tue, 24 Mar 2015 10:46:52 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Verified] RFC5246 (4109) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:48:23 -0000 The following errata report has been verified for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4109 -------------------------------------- Status: Verified Type: Technical Reported by: Christopher Armstrong Date Reported: 2014-09-11 Verified by: Stephen Farrell (IESG) Section: A.4.2 Original Text ------------- opaque ASN.1Cert<2^24-1>; Corrected Text -------------- opaque ASN.1Cert<1..2^24-1>; Notes ----- The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be specified according to the vector syntax specification in section 4.3. Fortunately, the original definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be updated to match. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Mar 24 10:48: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 9DDD21AC3FB; Tue, 24 Mar 2015 10:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TrtrSZP8VgKG; Tue, 24 Mar 2015 10:48:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7231A00E0; Tue, 24 Mar 2015 10:48:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DA321180205; Tue, 24 Mar 2015 10:47:18 -0700 (PDT) To: kikuchi@lepidum.co.jp, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324174718.DA321180205@rfc-editor.org> Date: Tue, 24 Mar 2015 10:47:18 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Held for Document Update] RFC5246 (4007) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:48:48 -0000 The following errata report has been held for document update for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4007 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: KIKUCHI Masashi Date Reported: 2014-06-06 Held by: Stephen Farrell (IESG) Section: 7.3. Original Text ------------- Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message. Corrected Text -------------- Note: To avoid ChangeCipherSpec being transmitted in mix with other handshake fragments in one record, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message. To help avoid pipeline stalls, ChangeCipherSpec is sent from both the server and the client. Notes ----- The original text can be read like we can handle ChangeCipherSpec asynchronously. This is harmful and may be a cause of CCS Injection vulnerability. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Mar 24 10:50: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 5A94D1AC3EE; Tue, 24 Mar 2015 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 nsO351HzwcsH; Tue, 24 Mar 2015 10:49:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD881A92AB; Tue, 24 Mar 2015 10:49:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C4F19180205; Tue, 24 Mar 2015 10:48:29 -0700 (PDT) To: fielding@gbiv.com, rohit@4K-associates.com, lawrence@agranat.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324174829.C4F19180205@rfc-editor.org> Date: Tue, 24 Mar 2015 10:48:29 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Held for Document Update] RFC2817 (4187) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:50:00 -0000 The following errata report has been held for document update for RFC2817, "Upgrading to TLS Within HTTP/1.1". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2817&eid=4187 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Roy T. Fielding Date Reported: 2014-11-20 Held by: Stephen Farrell (IESG) Section: 7.2 Original Text ------------- The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product': product = token ["/" product-version] product-version = token [...] This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol [6]. Corrected Text -------------- The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey the production for 'product': product = token ["/" product-version] product-version = token [...] This specification defines the product token "TLS" as the identifier for the protocol specified by The TLS Protocol [6]. When a specific version of TLS is desired, it is indicated by appending a slash ("/") and the TLS version number as the product-version (e.g., "TLS/1.0"). Notes ----- This erratum clarifies that "TLS" is the product token and any TLS version number (currently DIGIT "." DIGIT) is the product-version token. This has already been corrected in the Upgrade Token Registry. -------------------------------------- RFC2817 (draft-ietf-tls-http-upgrade-05) -------------------------------------- Title : Upgrading to TLS Within HTTP/1.1 Publication Date : May 2000 Author(s) : R. Khare, S. Lawrence Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From sergio@coinspect.com Tue Mar 24 20:10: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 957A51ACD35 for ; Tue, 24 Mar 2015 20:10: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=[AC_DIV_BONANZA=0.001, 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 0zRUDJKJfJjj for ; Tue, 24 Mar 2015 20:10:00 -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 E4B251ACD33 for ; Tue, 24 Mar 2015 20:09:59 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so8230490lbb.3 for ; Tue, 24 Mar 2015 20:09:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YCpi8Seys4w+ziWiwNQuoYeOSPaLrMVEXASPHAORfkQ=; b=nH81T+oymS0nbnBFwoN/Tdr3VUYG09ctvs+qisKSFKqcriK78QjN2wlxusiIGeGVvl x75pqJvxftK7xZXjzDpf9c8BgQfUzJ7qGZXkTsjsQaJyp0HH8o2/XHXCviUrWVsvpL1L 3ZAtRsSIZKcDqFoa75VkPVeaR8jlxOVJJicuUL7cnDEDsLJJaDlWE8v6aLFJrGNYfR2a 6uAe4gQ+PcGaHbwlqx1Dfi+aBsjVNy+r7DdMIhAzlJhLMpPYvg1QnpBDjGDCW86x6Hxg onYOyekCCX5aHSbnHyGLNpZMfl7XnK7SLODWDSXd+AEHKiQ9fEZISyhIw4RfN5gliv3t RrBw== X-Gm-Message-State: ALoCoQlQdSdSTWqPtdOHgPYzhRd9OpJ/nIb6NfzMtUU3i2D11O2f2RsTqFbK8z3VDW8654kfpBrD MIME-Version: 1.0 X-Received: by 10.112.89.71 with SMTP id bm7mr6545047lbb.20.1427252998295; Tue, 24 Mar 2015 20:09:58 -0700 (PDT) Received: by 10.25.143.4 with HTTP; Tue, 24 Mar 2015 20:09:58 -0700 (PDT) X-Originating-IP: [190.247.34.93] Date: Wed, 25 Mar 2015 00:09:58 -0300 Message-ID: From: Sergio Demian Lerner To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c36d74f7e9ad0512143b6b Archived-At: Subject: [TLS] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 03:14:01 -0000 --001a11c36d74f7e9ad0512143b6b Content-Type: text/plain; charset=UTF-8 Hi, This is my first post to this mailing list and I if I break some prestablished rule, I apologize in advance. One of our clients requires the notarization of TLS sessions. One interesting application I found is the TLSNotary project, but it only partially solves this problem: is only allows auditing a single stream direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers considerably the protocol security. Of course he wants transparent notarization for eavy website, not a higher-level protocol provided by a website on purpose, and this is completely logical and coherent with the attributes of a notary. I would be interesting if TLS 1.3 could allow optional and easy notarization of the streams. TLS 1.3 has eliminated renegotiation, which may be a bulding block for notarization, so I hope in incorporates another way of providing that functionality. For example: if every MAC computed included the the MAC digest of each previous message sent in that stream, then a single signature of the last MAC would be enought to validate one of the streams. Or in AEAD terminology, every packet payload additional_data would include the authentication tag of the previous packet. If key renegocitation is allowed, then a renegotiation done by a third party after a protocol interaction would be enought to notariaze all previous interactions. To get a join notarization of both streams, TLS in notarization could add a new message GetMAC that should be responded with the message SendMAC, containing the sequence number and MAC of the the last packet decrypted in the other stream (client->server). Since the MAC on one stream would contain the previous packet MAC digest, then the MAC sent with sendMAC would provide a MAC validating both streams (client->server and servcer->client) A full communication would be Client Server ClientHello --------> (client specifies a NOTARY extension somehow) ServerHello ..... [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Now the client gives the notary the control of the streams. The server does a renegotiation to obtain a signature of the previuously sent data. Notary tunneled over Client Server ClientHello --------> ServerHello ..... [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data getMAC --------> <-------- sendMAC This "notarization" can only convince the notary of the encrypted information exchange, but cannot convince a third party. Also it gives the notary some control over the streams. So better than this would be that instead of getMAC/sendMAC there can be two messages getSignature/SendSignature that send a digitally signed MAC using a server's pubkey, instead of only the MAC. Another option is that in notarization mode, each MAC sent would include the nseq and the MAC of the last packets received/sent of both streams. Then an exact reproduction of the message interaction would be available for notarization, but the seq_num of the opposed stream would need to be transmitted in the header or encrypted in the payload (it cannot be part of the additional_data because it is not known to the client, because of the delay of the network) In AEAD terminology the first idea would be done by modifying the additional_data: additional_data = seq_num +* prev_authentication_tag* + TLSPlaintext.type + TLSPlaintext.version while the second would be: additional_data = seq_num + *prev_authentication_tag + opposite_stream_prev_authentication_tag* + TLSPlaintext.type + TLSPlaintext.version Again, this would be an optional mode, orthogonal with ciphersuite chosen, extensions, etc. I hope you find this extension as usefull as we do. Last, we have several use cases for key renegotiation, and it's a pity it will be excluded from TLS 1.3. I will present my arguments in another e-mail. Best regards, -- Sergio D. Lerner Cryptocurrency Security Auditor Coinspect.com --001a11c36d74f7e9ad0512143b6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
This is my firs= t post to this mailing list and I if I break some prestablished rule, I apo= logize in advance.

One of our clients requires the notarizatio= n of TLS sessions. One interesting application I found is the TLSNotary pro= ject, but it only partially solves this problem: is only allows auditing a = single stream direction, is is not compatible with TLS 1.2 nor 1.3 and it l= owers considerably the protocol security. Of course he wants transparent no= tarization for eavy website, not a higher-level protocol provided by a webs= ite on purpose, and this is completely logical and coherent with the attrib= utes of a notary. =C2=A0

I would be interesting if TLS 1.3 co= uld allow optional and easy notarization of the streams. TLS 1.3 has elimin= ated renegotiation, which may be a bulding block for notarization, so I hop= e in incorporates another way of providing that functionality.
=C2=A0
For example: if every MAC computed included the the MAC digest of ea= ch previous message sent in that stream, then a single signature of the las= t MAC would be enought to validate one of the streams. Or in AEAD=C2=A0 ter= minology, every packet payload additional_data would include the authentica= tion tag of the previous packet.=C2=A0

If key renegocitation = is allowed, then a renegotiation done by a third party after a protocol int= eraction would be enought to notariaze all previous interactions.

To= get a join notarization of both streams, TLS in notarization could add a n= ew message GetMAC that should be responded with the message SendMAC, contai= ning the sequence number and MAC of the the last packet decrypted in the ot= her stream (client->server). Since the MAC on one stream would contain t= he previous packet MAC digest, then the MAC sent with sendMAC would provide= a MAC validating both streams (client->server and servcer->client) <= br>
A full communication would be 
      C=
lient                                               Server

      ClientHello                  -------->
      (client specifies a NOTARY extension somehow)        ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data
=

      Now the client gives the notary the control of =
the streams.
      The server does a renegotiation=
 to obtain a signature of the 
      previuously s=
ent data.

      Notary tunneled over Client   =
                  Server

      ClientHello                  -------->
                                                      ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data
=

      getMAC                       -------->
                                   <--------     sen=
dMAC

<= /div>
This "notarization" can only convince the notary of the= encrypted information exchange, but cannot convince a third party. Also it= gives the notary some control over the streams. So better than this would = be that instead of getMAC/sendMAC there can be two messages getSignature/Se= ndSignature that send a digitally signed MAC using a server's pubkey, i= nstead of only the MAC.

Another option is that in notari= zation mode, each MAC sent would include the nseq and the MAC of the last p= ackets received/sent of both streams. Then an exact reproduction of the mes= sage interaction would be available for notarization, but the seq_num of th= e opposed stream would need to be transmitted in the header or encrypted in= the payload (it cannot be part of the additional_data because it is not kn= own to the client, because of the delay of the network)

I= n AEAD terminology the first idea would be done by modifying the additional= _data:
 additional_data =3D seq_num + prev=
_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version
while=
 the second would be:
=C2=A0
 additional_data =
=3D seq_num + prev_authentication_tag +
                    opposite_=
stream_prev_authentication_tag +
                    TLSPlaintext.ty=
pe +
                        TLSPlaintext.version
Again, this wo= uld be an optional mode, orthogonal with ciphersuite chosen, extensions, et= c.

I hope you find this extension as usefull as we do.=C2= =A0 Last, we have several use cases for key renegotiation, and it's a p= ity it will be excluded from TLS 1.3. I will present my arguments in anothe= r e-mail.

Best regards,

-- <= br>
Sergio D. Lern= er
Cryptocurrency Security Auditor
Coinspect.com
--001a11c36d74f7e9ad0512143b6b-- From nobody Tue Mar 24 21:32: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 0CC6C1ACD91 for ; Tue, 24 Mar 2015 21:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e94zjQ0cSESK for ; Tue, 24 Mar 2015 21:32:45 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003: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 C85ED1ACD8A for ; Tue, 24 Mar 2015 21:32:45 -0700 (PDT) Received: by oiag65 with SMTP id g65so12059683oia.2 for ; Tue, 24 Mar 2015 21:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dv9h9YtM683+jfkZESFMApoUkwH+IiPoSu11SJJp9Mk=; b=yZuMapCavp6DlFP+bW5VCSOQVXqR2bXlBrAMlHiEqOqFRitY/pekAsood04tZOvIeh bZF4R68zYVotp4V+iyZ9qgJfcN3ZbvFypQcbNthNG+5eOsz0fhByrXWPpPrVJSYkYYtH BjAJep/NrKVvlXCcCwGG03c4jGd/Ah0z2/oX7TYdSMRjMkSLhHroycOvbtsbydhfDv+H NIwU+DnA1nJID+e1jWBLvUX+YMaHSxKDR15C+FSAoU9mfUwJ/d4VY+fpoXpQiKEO1Ofi 3j6Et8IogJuHjhdbdLgBakT9dpbIXwlzBXWVhGEKnUrKKNsIozTFD5/JAsFs/TYtmhVM lDTg== MIME-Version: 1.0 X-Received: by 10.202.64.9 with SMTP id n9mr5634803oia.20.1427257965340; Tue, 24 Mar 2015 21:32:45 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Tue, 24 Mar 2015 21:32:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2015 23:32:45 -0500 Message-ID: From: Martin Thomson To: Sergio Demian Lerner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 04:32:47 -0000 Perhaps you can do a better job of explaining precisely what information you want to provide the auditor. It might be that I'm tired, but tlsnotary.org does a terrible job of actually explaining what it is for. On 24 March 2015 at 22:09, Sergio Demian Lerner wrote: > Or in AEAD terminology, every packet payload additional_data would include > the authentication tag of the previous packet. That would be incompatible with DTLS. From nobody Tue Mar 24 22:51: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 07C971ACDBF for ; Tue, 24 Mar 2015 22:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.557 X-Spam-Level: * X-Spam-Status: No, score=1.557 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zmWQM2_8sFU for ; Tue, 24 Mar 2015 22:50:57 -0700 (PDT) Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D551ACDBE for ; Tue, 24 Mar 2015 22:50:57 -0700 (PDT) Received: from [192.168.1.102] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 2A9F5F210A; Tue, 24 Mar 2015 22:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1427262433; bh=piZ9goyTRW0Tm1nkSpf0CdY7JPPHPW9Qox5nq5Fqh/E=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HrLyvY2q0JHW0av+HdoXQ/GjfCzsQWqzV+CPX1wxtzsRsDeQXL3FWcX6TdBtpQOtA Cu6BmgSOAH7S2PD3OUBq/a4zi3oPX4WQ7dbRB/XsNjzne/lscJrdIZmniquiZhKFw6 TSx0SOTraYDXEFO8pqEkn50CRUpQf18HOtApZ1ZE= Message-ID: <55124CC3.80708@shiftleft.org> Date: Tue, 24 Mar 2015 22:50:59 -0700 From: Mike Hamburg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Demian Lerner , tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040208020005020408070505" Archived-At: Subject: Re: [TLS] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 05:51:00 -0000 This is a multi-part message in MIME format. --------------040208020005020408070505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Sergio, It is worth noting that MAC functions are not generally strong enough here. For one thing, the MAC is meaningless to a party who doesn't know the key. But even if you reveal the key afterwards, unless you're using a sufficiently long HMAC mode, a party who knows the key can probably find a message with the same MAC value. Cheers, -- Mike On 03/24/2015 08:09 PM, Sergio Demian Lerner wrote: > Hi, > This is my first post to this mailing list and I if I break some > prestablished rule, I apologize in advance. > > One of our clients requires the notarization of TLS sessions. One > interesting application I found is the TLSNotary project, but it only > partially solves this problem: is only allows auditing a single stream > direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers > considerably the protocol security. Of course he wants transparent > notarization for eavy website, not a higher-level protocol provided by > a website on purpose, and this is completely logical and coherent with > the attributes of a notary. > > I would be interesting if TLS 1.3 could allow optional and easy > notarization of the streams. TLS 1.3 has eliminated renegotiation, > which may be a bulding block for notarization, so I hope in > incorporates another way of providing that functionality. > > For example: if every MAC computed included the the MAC digest of each > previous message sent in that stream, then a single signature of the > last MAC would be enought to validate one of the streams. Or in AEAD > terminology, every packet payload additional_data would include the > authentication tag of the previous packet. > > If key renegocitation is allowed, then a renegotiation done by a third > party after a protocol interaction would be enought to notariaze all > previous interactions. > > To get a join notarization of both streams, TLS in notarization could > add a new message GetMAC that should be responded with the message > SendMAC, containing the sequence number and MAC of the the last packet > decrypted in the other stream (client->server). Since the MAC on one > stream would contain the previous packet MAC digest, then the MAC sent > with sendMAC would provide a MAC validating both streams > (client->server and servcer->client) > > A full communication would be > Client Server > > ClientHello --------> > (client specifies a NOTARY extension somehow) ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > Now the client gives the notary the control of the streams. > The server does a renegotiation to obtain a signature of the > previuously sent data. > > Notary tunneled over Client Server > > ClientHello --------> > ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > getMAC --------> > <-------- sendMAC > > This "notarization" can only convince the notary of the encrypted > information exchange, but cannot convince a third party. Also it gives > the notary some control over the streams. So better than this would be > that instead of getMAC/sendMAC there can be two messages > getSignature/SendSignature that send a digitally signed MAC using a > server's pubkey, instead of only the MAC. > > Another option is that in notarization mode, each MAC sent would > include the nseq and the MAC of the last packets received/sent of both > streams. Then an exact reproduction of the message interaction would > be available for notarization, but the seq_num of the opposed stream > would need to be transmitted in the header or encrypted in the payload > (it cannot be part of the additional_data because it is not known to > the client, because of the delay of the network) > > In AEAD terminology the first idea would be done by modifying the > additional_data: > additional_data = seq_num +* prev_authentication_tag* + > TLSPlaintext.type + > TLSPlaintext.version > while the second would be: > > additional_data = seq_num +*prev_authentication_tag + > opposite_stream_prev_authentication_tag* + > TLSPlaintext.type + > TLSPlaintext.version > Again, this would be an optional mode, orthogonal with ciphersuite > chosen, extensions, etc. > > I hope you find this extension as usefull as we do. Last, we have > several use cases for key renegotiation, and it's a pity it will be > excluded from TLS 1.3. I will present my arguments in another e-mail. > > Best regards, > > -- > Sergio D. Lerner > Cryptocurrency Security Auditor > Coinspect.com > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------040208020005020408070505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Sergio,

It is worth noting that MAC functions are not generally strong enough here.  For one thing, the MAC is meaningless to a party who doesn't know the key.  But even if you reveal the key afterwards, unless you're using a sufficiently long HMAC mode, a party who knows the key can probably find a message with the same MAC value.

Cheers,
-- Mike

On 03/24/2015 08:09 PM, Sergio Demian Lerner wrote:
Hi,
This is my first post to this mailing list and I if I break some prestablished rule, I apologize in advance.

One of our clients requires the notarization of TLS sessions. One interesting application I found is the TLSNotary project, but it only partially solves this problem: is only allows auditing a single stream direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers considerably the protocol security. Of course he wants transparent notarization for eavy website, not a higher-level protocol provided by a website on purpose, and this is completely logical and coherent with the attributes of a notary.  

I would be interesting if TLS 1.3 could allow optional and easy notarization of the streams. TLS 1.3 has eliminated renegotiation, which may be a bulding block for notarization, so I hope in incorporates another way of providing that functionality.
 
For example: if every MAC computed included the the MAC digest of each previous message sent in that stream, then a single signature of the last MAC would be enought to validate one of the streams. Or in AEAD  terminology, every packet payload additional_data would include the authentication tag of the previous packet. 

If key renegocitation is allowed, then a renegotiation done by a third party after a protocol interaction would be enought to notariaze all previous interactions.

To get a join notarization of both streams, TLS in notarization could add a new message GetMAC that should be responded with the message SendMAC, containing the sequence number and MAC of the the last packet decrypted in the other stream (client->server). Since the MAC on one stream would contain the previous packet MAC digest, then the MAC sent with sendMAC would provide a MAC validating both streams (client->server and servcer->client)

A full communication would be 
      Client                                               Server

      ClientHello                  -------->
      (client specifies a NOTARY extension somehow)        ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      Now the client gives the notary the control of the streams.

      The server does a renegotiation to obtain a signature of the 

      previuously sent data.


      Notary tunneled over Client                     Server

      ClientHello                  -------->
                                                      ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      getMAC                       -------->

                                   <--------     sendMAC

This "notarization" can only convince the notary of the encrypted information exchange, but cannot convince a third party. Also it gives the notary some control over the streams. So better than this would be that instead of getMAC/sendMAC there can be two messages getSignature/SendSignature that send a digitally signed MAC using a server's pubkey, instead of only the MAC.

Another option is that in notarization mode, each MAC sent would include the nseq and the MAC of the last packets received/sent of both streams. Then an exact reproduction of the message interaction would be available for notarization, but the seq_num of the opposed stream would need to be transmitted in the header or encrypted in the payload (it cannot be part of the additional_data because it is not known to the client, because of the delay of the network)

In AEAD terminology the first idea would be done by modifying the additional_data:
 additional_data = seq_num + prev_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version

while the second would be:

 
 additional_data = seq_num + prev_authentication_tag +
                    opposite_stream_prev_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version
Again, this would be an optional mode, orthogonal with ciphersuite chosen, extensions, etc.

I hope you find this extension as usefull as we do.  Last, we have several use cases for key renegotiation, and it's a pity it will be excluded from TLS 1.3. I will present my arguments in another e-mail.

Best regards,

--
Sergio D. Lerner
Cryptocurrency Security Auditor
Coinspect.com 


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

--------------040208020005020408070505-- From nobody Wed Mar 25 07:06: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 454361A1AAD for ; Wed, 25 Mar 2015 07:06: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 wwRSqEPeE3JO for ; Wed, 25 Mar 2015 07:06:22 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 D214E1AD0CA for ; Wed, 25 Mar 2015 07:06:21 -0700 (PDT) Received: by ykcn8 with SMTP id n8so12818575ykc.3 for ; Wed, 25 Mar 2015 07:06: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=0kdA64CGLkakcD76tw2SRkvMVxuwzmhxE/OS0fWNS1w=; b=VcYxj+SZofVB/STTP6qbLvpNqNPV7ibNdl8e4VAvrrfygY/Zzy8qHt6iOonBQp5ltA MkUY2gYjI01DQy+IwyTuSeXVc4V8mDmqxwRtd71mTWWtmiivP9yC4hy5VCCMYH+FRnHE Fy6+pZBX/Qt/ZPiMFmuHXYFlXJs5FOS1XtX9ijoT9RlDcv4+RGlSsYwpjztcWS+2QpK5 ANNMm7uHKp6b4fnpB6bugbquTLBZ99u4GfxNaT9OOM05FR7y7iFLjm/NMbaSzkUV3e7w a6Gtz1MfvAGMie0KE/0WTGQZYUy+cKxRlVTx33y51dKWUIQ/o3uUj2ePGKuVS/xvNeJq L4ww== MIME-Version: 1.0 X-Received: by 10.236.18.162 with SMTP id l22mr4653899yhl.172.1427292381060; Wed, 25 Mar 2015 07:06:21 -0700 (PDT) Received: by 10.170.58.201 with HTTP; Wed, 25 Mar 2015 07:06:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 07:06:20 -0700 Message-ID: From: Watson Ladd To: Sergio Demian Lerner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 14:06:25 -0000 On Tue, Mar 24, 2015 at 8:09 PM, Sergio Demian Lerner wrote: > Hi, > This is my first post to this mailing list and I if I break some > prestablished rule, I apologize in advance. > > One of our clients requires the notarization of TLS sessions. One > interesting application I found is the TLSNotary project, but it only > partially solves this problem: is only allows auditing a single stream > direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers > considerably the protocol security. Of course he wants transparent > notarization for eavy website, not a higher-level protocol provided by a > website on purpose, and this is completely logical and coherent with the > attributes of a notary. > > I would be interesting if TLS 1.3 could allow optional and easy notarization > of the streams. TLS 1.3 has eliminated renegotiation, which may be a bulding > block for notarization, so I hope in incorporates another way of providing > that functionality. > > For example: if every MAC computed included the the MAC digest of each > previous message sent in that stream, then a single signature of the last > MAC would be enought to validate one of the streams. Or in AEAD > terminology, every packet payload additional_data would include the > authentication tag of the previous packet. What exactly is being asked for here? A signature on encrypted data is not the same as a signature on unencrypted data, so I don't understand what this notarisation is providing. I also don't understand what the requirements are: does notarization have to work without modifying the server, or the client, or both, or we can modify anything? > > If key renegocitation is allowed, then a renegotiation done by a third party > after a protocol interaction would be enought to notariaze all previous > interactions. Same question as before. > > To get a join notarization of both streams, TLS in notarization could add a > new message GetMAC that should be responded with the message SendMAC, > containing the sequence number and MAC of the the last packet decrypted in > the other stream (client->server). Since the MAC on one stream would contain > the previous packet MAC digest, then the MAC sent with sendMAC would provide > a MAC validating both streams (client->server and servcer->client) > > A full communication would be > > Client Server > > ClientHello --------> > (client specifies a NOTARY extension somehow) ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > Now the client gives the notary the control of the streams. > > The server does a renegotiation to obtain a signature of the > > previuously sent data. > > Notary tunneled over Client Server > > ClientHello --------> > ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > getMAC --------> > > <-------- sendMAC > > > This "notarization" can only convince the notary of the encrypted > information exchange, but cannot convince a third party. Also it gives the > notary some control over the streams. So better than this would be that > instead of getMAC/sendMAC there can be two messages > getSignature/SendSignature that send a digitally signed MAC using a server's > pubkey, instead of only the MAC. > > Another option is that in notarization mode, each MAC sent would include the > nseq and the MAC of the last packets received/sent of both streams. Then an > exact reproduction of the message interaction would be available for > notarization, but the seq_num of the opposed stream would need to be > transmitted in the header or encrypted in the payload (it cannot be part of > the additional_data because it is not known to the client, because of the > delay of the network) > > In AEAD terminology the first idea would be done by modifying the > additional_data: > > additional_data = seq_num + prev_authentication_tag + > TLSPlaintext.type + > TLSPlaintext.version > > while the second would be: > > > additional_data = seq_num + prev_authentication_tag + > opposite_stream_prev_authentication_tag + > TLSPlaintext.type + > TLSPlaintext.version > > Again, this would be an optional mode, orthogonal with ciphersuite chosen, > extensions, etc. > > I hope you find this extension as usefull as we do. Last, we have several > use cases for key renegotiation, and it's a pity it will be excluded from > TLS 1.3. I will present my arguments in another e-mail. I don't understand what problem notarization is supposed to solve at the TLS layer. If you want to make an exchange irrevocable, have both people sign it. We also removed renegotiation because no one understood what semantics it was supposed to have. Sincerely, Watson Ladd > > Best regards, > > -- > Sergio D. Lerner > Cryptocurrency Security Auditor > Coinspect.com > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Mar 25 08:02: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 4047A1B29CA for ; Wed, 25 Mar 2015 08:02:37 -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 E-2PIPaodIzA for ; Wed, 25 Mar 2015 08:02:33 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 B0FC31A86E4 for ; Wed, 25 Mar 2015 08:02:32 -0700 (PDT) Received: by wgdm6 with SMTP id m6so30959747wgd.2 for ; Wed, 25 Mar 2015 08:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MN3WNqPd7Qt2fG7BWQvunNlcm60w/c7FDIUfo5pjJh8=; b=VJhIzni9erVJDdWka1/JXonWh0sfoR7VTneceoCKTq/46nvG6aCQQIjbiutQae/4JZ bngMPGRj0mvQmvaCn17WfOoJI8khnGjtSDpv5qsUwUsU3PLE0Z1rGG8LAenwHa38EFqd ThGwJFqDd91Z/NAA0di1KaSCB8TO6OJHFpsxQtXwAfmlFOxwHvGHxHFSeovkoBihA+BR KZ1oIPuRkvvStlYNujOSHxQwb7TdLGugpnOyRa6KYo6saw+79oak5qzbcHqjqG0lftlh 2trns8oveRhVG6GiowHcO+nQXkesYZSdCOzIUhDw8G1XnlagpWdPoaFtRFulswwqM9u8 kZoQ== X-Gm-Message-State: ALoCoQmo7nGafetmz/2nThjLZ7Obt46fRu3Og639cBEIytaZOggJ3y2V2aqr1YSAYmo6lTdkbZCl MIME-Version: 1.0 X-Received: by 10.194.63.172 with SMTP id h12mr18725922wjs.48.1427295751022; Wed, 25 Mar 2015 08:02:31 -0700 (PDT) Sender: andrey@brainhub.org Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:02:30 -0700 (PDT) X-Originating-IP: [31.133.162.114] Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:02:30 -0700 (PDT) In-Reply-To: <20150324121632.GA28552@LK-Perkele-VII> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> Date: Wed, 25 Mar 2015 08:02:30 -0700 X-Google-Sender-Auth: bzXUn5PawlDqRsuat0BZmP6fT3c Message-ID: From: Andrey Jivsov To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=047d7ba9780a3ac53505121e3033 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:02:37 -0000 --047d7ba9780a3ac53505121e3033 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A problem with this is additional options. There is no problem with HKDF that I see other than it relaxes assumptions on hash functions, but we would not be using such weak hash functions in TLS. HKDF is probably viewed as an insurance. Please note that the benefits will be bound by the "ad-hoc" methods to process entropy into private keys. One idea for meaningful reduction of complexity in TLS is if we could switch to cipher-based KDF. We countinue to use hash for digital signatures, controlled by the signature extension. An AEAD cipher is required and has the MAC method internal to them. Therefore, this would drop hash functions from the ciphersuites. On Mar 24, 2015 7:16 AM, "Ilari Liusvaara" wrote: > On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote: > > > > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov > wrote: > > > > > > Please note that at least some of these can be FIPS 140 tested (in > particular, TLS PRF). Suite B expects the use of these approved KDFs. > > > > > > While NIST is perhaps too prolific with these, I feel that we should > look into standard KDFs. There are test vectors, verifications systems, > existing implementations=E2=80=A6 > > > > If such a KDF is needed for Suite-B, then it makes sense for Suite-B > ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM= . > > > > Why not include a different PRF in those suites that have > non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever > signature scheme CFRG are going to recommend? > > Or even special Suite B ciphersuites. I think there are only 2 of > those. > > - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256 > - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384 > > The basic idea being: They who care can implement that. > > > -Ilari > --047d7ba9780a3ac53505121e3033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A problem with this is additional options.

There is no problem with HKDF that I see other than it relax= es assumptions on hash functions, but we would not be using such weak hash = functions in TLS. HKDF is probably viewed as an insurance. Please note that= the benefits will be bound by the "ad-hoc" methods to process en= tropy into private keys.

One idea for meaningful reduction of complexity in TLS is if= we could switch to cipher-based KDF. We countinue to use hash for digital = signatures, controlled by the signature extension. An AEAD cipher is requir= ed and has the MAC method internal to them. Therefore, this would drop hash= functions from the ciphersuites.

On Mar 24, 2015 7:16 AM, "Ilari Liusvaara&q= uot; <ilari.liusvaara@eli= sanet.fi> wrote:
On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
>
> > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org> wrote:
> >
> > Please note that at least some of these can be FIPS 140 tested (i= n particular, TLS PRF). Suite B expects the use of these approved KDFs.
> >
> > While NIST is perhaps too prolific with these, I feel that we sho= uld look into standard KDFs. There are test vectors, verifications systems,= existing implementations=E2=80=A6
>
> If such a KDF is needed for Suite-B, then it makes sense for Suite-B c= iphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM. >
> Why not include a different PRF in those suites that have non-NIST-app= roved algorithms such as ChaCha20, Curve25519, and whatever signature schem= e CFRG are going to recommend?

Or even special Suite B ciphersuites. I think there are only 2 of
those.

- ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
- ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384

The basic idea being: They who care can implement that.


-Ilari
--047d7ba9780a3ac53505121e3033-- From nobody Wed Mar 25 08:21: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 ACA621A87BF for ; Wed, 25 Mar 2015 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 ll2TfftnLgQl for ; Wed, 25 Mar 2015 08:21:27 -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 4BD5E1A87BC for ; Wed, 25 Mar 2015 08:21:27 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so44088311wib.1 for ; Wed, 25 Mar 2015 08:21:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fl7UO5QKjzNG7W8Um7r3KZ2Q2jFR3aRP49nGqHBF2Aw=; b=d5G9M8+jabzOXLUGMhbpXnZIOOZbQ1K69ua505tGjFqgHflxVuW0oGEPaVpKGnGFVo thB0BiyYxeTjZ81wxYDC4fUsn+818wWkqLkIZXgAyFNqQqYYKgpEw9NJlBHjbGrZse4J pOYh//qJGRFfVFzhYoPeIPwgDrv91oLsgnxzhIW6bho9LBgY4tVv5G9NjwvvP04I44fQ zoRxvDpfLR9mHXnqtQ8MolR5xfSoenNiZWhwJx9vDGC95xbnCqJw8O3yU9icvaLsdl// jOAB7i2AHbyAqNyUKKLRMP6kcPT76y71Xtu1d3C6tl3HxzADgMUYBcdjjY0VfUPwYjT1 dX/Q== X-Gm-Message-State: ALoCoQn3jS9nJuAMFj7TsTH3WvhrhqG0oMMjZ5eLyn/Xydn5YWJwibhohYpaj0NjrQ7j0hk0Agaj MIME-Version: 1.0 X-Received: by 10.180.97.106 with SMTP id dz10mr38547564wib.33.1427296885864; Wed, 25 Mar 2015 08:21:25 -0700 (PDT) Sender: andrey@brainhub.org Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:21:25 -0700 (PDT) X-Originating-IP: [31.133.162.114] Received: by 10.27.14.66 with HTTP; Wed, 25 Mar 2015 08:21:25 -0700 (PDT) In-Reply-To: References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> Date: Wed, 25 Mar 2015 08:21:25 -0700 X-Google-Sender-Auth: adTxTHngt5hv9T-2CD1jrncqGa0 Message-ID: From: Andrey Jivsov To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d0442712edf0fbd05121e7300 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:21:28 -0000 --f46d0442712edf0fbd05121e7300 Content-Type: text/plain; charset=UTF-8 On Mar 25, 2015 10:02 AM, "Andrey Jivsov" wrote: > > > One idea for meaningful reduction of complexity in TLS is if we could switch to cipher-based KDF. We countinue to use hash for digital signatures, controlled by the signature extension. An AEAD cipher is required and has the MAC method internal to them. Therefore, this would drop hash functions from the ciphersuites. > ... but some people like AEAD stream ciphers. --f46d0442712edf0fbd05121e7300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 25, 2015 10:02 AM, "Andrey Jivsov" <crypto@brainhub.org> wrote:
>

>
> One idea for meaningful reduction of complexity in TLS is if we could = switch to cipher-based KDF. We countinue to use hash for digital signatures= , controlled by the signature extension. An AEAD cipher is required and has= the MAC method internal to them. Therefore, this would drop hash functions= from the ciphersuites.
>

... but some people like AEAD stream ciphers.

--f46d0442712edf0fbd05121e7300-- From nobody Wed Mar 25 08:27: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 3492C1A87F1 for ; Wed, 25 Mar 2015 08:27:23 -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 R3v-n1f5o3gR for ; Wed, 25 Mar 2015 08:27:20 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 3722A1A87BB for ; Wed, 25 Mar 2015 08:27:20 -0700 (PDT) Received: by labe2 with SMTP id e2so22752246lab.3 for ; Wed, 25 Mar 2015 08:27:18 -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:from:date:message-id :subject:to:cc:content-type; bh=/a/d5Ky7uUFM34jTGx5sy2Wj7bLjPpAPsJfaAiTbPs4=; b=dqFKjwX9/7CRfO5tEseLKyfJptU/30k4gwA8ongTlqR6bdxDdBnHLZkWHHqdhWR87b /epPMbxSV2VAbs1JqNQTYSRbAzNB/wbAsj96hYbzcfZCUygAoMBTdYhKjcGsvb0ONyKk Koxx5HM6NYR8IzGFWikIAjCbNWbb/tc2q2vHh5iGs4NKq1UYi2MKe1Oj9eJYz5d4HOaC wpNpsfibQfNpYvhutL99RVZrzmVsa8CnAh75cHxJWQXtEAmR9Ketwevr1IUaEY2vEClw SLaxJ0dh1MZsDKUj8+FKZOLW5j+aJ6oPU3fw89YY+ZHp8i7rxR+Pw/AX9zevbzrHiai4 K7Fw== X-Received: by 10.112.170.100 with SMTP id al4mr9130224lbc.42.1427297238712; Wed, 25 Mar 2015 08:27:18 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.9 with HTTP; Wed, 25 Mar 2015 08:21:38 -0700 (PDT) In-Reply-To: References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> From: Hugo Krawczyk Date: Wed, 25 Mar 2015 11:21:38 -0400 X-Google-Sender-Auth: svB15NeFFe_QRRJCrFX-IyWTlec Message-ID: To: Andrey Jivsov Content-Type: multipart/alternative; boundary=001a11c23686e7085505121e88fe Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:27:23 -0000 --001a11c23686e7085505121e88fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 11:02 AM, Andrey Jivsov wrote= : > A problem with this is additional options. > =E2=80=8BWhat are the additional options? =E2=80=8B =E2=80=8BYou use the defined hash function. > There is no problem with HKDF that I see other than it relaxes assumption= s > on hash functions, > =E2=80=8BRelaxing assumptions is not a problem but rather a good thing: It = means that you need to assume less from the hash function, e.g. not having a scheme broken if collisions are found on that function. In some cases we still need to model the hash function as a random oracle but we minimize these cases and only need to assume it for the compression function not the iterated one (the iterated function contradicts the random oracle model just by virtue of extension attacks). =E2=80=8B > but we would not be using such weak hash functions in TLS. > =E2=80=8BI am not sure what you mean by this - the problem is that we never= know how weak a hash function is until we know... (i.e someone breaks it). =E2=80=8B > HKDF is probably viewed as an insurance. Please note that the benefits > will be bound by the "ad-hoc" methods to process entropy into private key= s. > =E2=80=8BThat's true, but these ad-hoc methods have a better analytical bas= is than just using non-uniform keys to key directly a PRF. =E2=80=8B > One idea for meaningful reduction of complexity in TLS is if we could > switch to cipher-based KDF. > =E2=80=8BThat's for the WG to decide but the results we have for the extrac= tion properties of block-cipher based PRFs are much weaker. =E2=80=8B > We countinue to use hash for digital signatures, controlled by the > signature extension. > An AEAD cipher is required and has the MAC method internal to them. > Therefore, this would drop hash functions from the ciphersuites. > =E2=80=8B=E2=80=8B=E2=80=8BYou need hash functions for generating the sessi= on hash, even if you don't use a digital signature at all. Hugo =E2=80=8B > On Mar 24, 2015 7:16 AM, "Ilari Liusvaara" > wrote: > >> On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote: >> > >> > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov >> wrote: >> > > >> > > Please note that at least some of these can be FIPS 140 tested (in >> particular, TLS PRF). Suite B expects the use of these approved KDFs. >> > > >> > > While NIST is perhaps too prolific with these, I feel that we should >> look into standard KDFs. There are test vectors, verifications systems, >> existing implementations=E2=80=A6 >> > >> > If such a KDF is needed for Suite-B, then it makes sense for Suite-B >> ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GC= M. >> > >> > Why not include a different PRF in those suites that have >> non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever >> signature scheme CFRG are going to recommend? >> >> Or even special Suite B ciphersuites. I think there are only 2 of >> those. >> >> - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256 >> - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384 >> >> The basic idea being: They who care can implement that. >> >> >> -Ilari >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c23686e7085505121e88fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 25, 2015 at 11:02 AM, Andrey Jivsov <cr= ypto@brainhub.org> wrote:

A problem with this is additional options.=


=E2=80=8BWhat are the a= dditional options? =E2=80=8B
=C2=A0
=E2=80= =8BYou use the defined hash function.

There is no problem with HKDF that I see other than it relax= es assumptions on hash functions,

=E2=80=8BRelaxing assumptions is not a problem but rather a good thin= g: It means that you need to assume less from the hash function, e.g. not h= aving a scheme broken if collisions are found on that function. In some cas= es we still need to model the hash function as a random oracle but we minim= ize these cases and only need to assume it for the compression function not= the iterated one (the iterated function contradicts the random oracle mode= l just by virtue of extension attacks).
=E2=80=8B
=C2=A0

but we would n= ot be using such weak hash functions in TLS.

=E2=80=8BI am not sure what you mean by this - the proble= m is that we never know how weak a hash function is until we know... (i.e s= omeone breaks it).
=E2=80=8B
=C2=A0

HKDF is probably viewed as an insura= nce. Please note that the benefits will be bound by the "ad-hoc" = methods to process entropy into private keys.


=E2=80=8BThat's true, but these ad-hoc methods ha= ve a better analytical basis than just using non-uniform keys to key direct= ly a PRF.
=E2=80=8B
=C2=A0

One idea for meaningful reduction of complexity in TLS is if= we could switch to cipher-based KDF.

=E2=80=8BThat's for the WG to decide but the results we have= for the extraction properties of block-cipher based PRFs are much weaker.<= br>=E2=80=8B
=C2=A0

We countinue to use hash for digital signatures, contro= lled by the signature extension.

An AEAD cipher is required and = has the MAC method internal to them. Therefore, this would drop hash functi= ons from the ciphersuites.

= =E2=80=8B=E2=80=8B=E2=80=8BYou need hash functions for generating the sessi= on hash, even if you don't use a digital signature at all.

Hugo
=E2=80=8B
=C2=A0
On Mar 24, 2015 7:16 AM, "Ilari Liusvaara&q= uot; <i= lari.liusvaara@elisanet.fi> wrote:
On Tue, Mar 24, 2015 at 06:39:43AM= -0500, Yoav Nir wrote:
>
> > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <crypto@brainhub.org> wrote: > >
> > Please note that at least some of these can be FIPS 140 tested (i= n particular, TLS PRF). Suite B expects the use of these approved KDFs.
> >
> > While NIST is perhaps too prolific with these, I feel that we sho= uld look into standard KDFs. There are test vectors, verifications systems,= existing implementations=E2=80=A6
>
> If such a KDF is needed for Suite-B, then it makes sense for Suite-B c= iphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM. >
> Why not include a different PRF in those suites that have non-NIST-app= roved algorithms such as ChaCha20, Curve25519, and whatever signature schem= e CFRG are going to recommend?

Or even special Suite B ciphersuites. I think there are only 2 of
those.

- ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
- ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384

The basic idea being: They who care can implement that.


-Ilari

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


--001a11c23686e7085505121e88fe-- From nobody Wed Mar 25 08:36: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 8EE7B1B2A62 for ; Wed, 25 Mar 2015 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tvjzN_t1gI1 for ; Wed, 25 Mar 2015 08:36:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 3AC011B2A59 for ; Wed, 25 Mar 2015 08:36:26 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2PFaJCJ017003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Mar 2015 11:36:19 -0400 Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2PFaHsR018976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2015 11:36:18 -0400 Message-ID: <1427297776.4885.47.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hugo Krawczyk Date: Wed, 25 Mar 2015 16:36:16 +0100 In-Reply-To: References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:36:30 -0000 On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote: > One idea for meaningful reduction of complexity in TLS is if > we could switch to cipher-based KDF. > ​That's for the WG to decide but the results we have for the > extraction properties of block-cipher based PRFs are much weaker. I'm not sure whether the WG should even decide on replacing the KDF or the main protocols used. That was certainly a non-goal for TLS 1.3 and is a cryptographic decision which is not the expertise of this group. For such decisions, and even simpler (see Salsa20, ChaCha cipher addition) this working group delegated these decisions to CFRG, and I believe this should also be done now if we go the path of replacing core TLS structure. regards, Nikos From nobody Wed Mar 25 10:15: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 D96411A904E for ; Wed, 25 Mar 2015 10:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XYHWdcZarNj for ; Wed, 25 Mar 2015 10:15:40 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57EA1A9043 for ; Wed, 25 Mar 2015 10:15:34 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 2618281820; Wed, 25 Mar 2015 19:15:31 +0200 (EET) Date: Wed, 25 Mar 2015 19:15:31 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150325171531.GA26949@LK-Perkele-VII> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 17:15:43 -0000 On Wed, Mar 25, 2015 at 11:21:38AM -0400, Hugo Krawczyk wrote: > On Wed, Mar 25, 2015 at 11:02 AM, Andrey Jivsov wrote: > > > A problem with this is additional options. > > > > ​What are the additional options? ​ > > ​You use the defined hash function. > > > There is no problem with HKDF that I see other than it relaxes assumptions > > on hash functions, > > > ​Relaxing assumptions is not a problem but rather a good thing: It means > that you need to assume less from the hash function, e.g. not having a > scheme broken if collisions are found on that function. TLS 1.3 already assumes prf-hash is collision-resistant. Changing this is incredibly hard, requiring extreme effort. You would need incredibly broad security proofs. > > HKDF is probably viewed as an insurance. Please note that the benefits > > will be bound by the "ad-hoc" methods to process entropy into private keys. > > ​That's true, but these ad-hoc methods have a better analytical basis than > just using non-uniform keys to key directly a PRF. I'm not seeing how you can have any sort of adversarial input fed to TLS PRF without having much more serious problems. Prf-hash on the other hand needs to take full burnt of adversarial input, with no strengthening at all. ​ > > One idea for meaningful reduction of complexity in TLS is if we could > > switch to cipher-based KDF. > > > ​That's for the WG to decide but the results we have for the extraction > properties of block-cipher based PRFs are much weaker. Because you need a CR hash function anyway, you can't reduce complexity that way. -Ilari From nobody Wed Mar 25 11:47: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 3D5E71AC430 for ; Wed, 25 Mar 2015 11:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjY2t7OYseTL for ; Wed, 25 Mar 2015 11:47:27 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.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 2A0861A9234 for ; Wed, 25 Mar 2015 11:47:27 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so27041251obc.2 for ; Wed, 25 Mar 2015 11:47:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oRG0zXVtOc9josY8SA9xOJ85OqvNTPH+ofOYp/fuaCI=; b=kynXQZOj4SchI1cZa87r3+rm2kqGyQfxvOYIqYSJjB/tMb3Pc0ou/Gdlg4RAvxm3OS DGIxd6Gk0v151aaEebpgZeCAHaGEGQjbPvzEkjSl+VUfzPp2URxErHAG6aovTJkGwkw+ XEau8MUY1TaRurjqjgdUpOiE4nNMszKhynDV2xZ2QFJIVLfpAK7kdCDaKoojDJpVBMoY /KFX9FV/MqYQIlDSTPOcfcYic4Z3vm8OJTjtXTZsOtDJNSinsvIk+0yF3DGcE0CS5ory SyN7PcfBTsoDsJTxR8OG0Tv0RtMgZcfrNy9ru7dTekQ5yJPxM7IjzPaOr03bryXhTP62 1PDw== X-Gm-Message-State: ALoCoQl6XM9z6u8ee/AyTxhjOp+1EevIRTihsKFx+r8GwcJmIkOPGKK2qseSgyt18dpdBcyozigW MIME-Version: 1.0 X-Received: by 10.60.35.102 with SMTP id g6mr8852218oej.7.1427309246603; Wed, 25 Mar 2015 11:47:26 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Wed, 25 Mar 2015 11:47:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 08:47:26 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 18:47:28 -0000 Eric Rescorla wrote: > As I mentioned in a previous message [0] during the interim we discussed > moving from the TLS PRF to HKDF [RFC5869]. > > The general sentiment was: > > - Move to HKDF > - Specify both SHA-256 and SHA-384 (the latter being required for > Suite B) Assuming that the choice of either SHA-256 or SHA-384 is fixed per cipher suite, as is the case with TLS 1.2, switching to HKDF seems like a good idea to me. > This is also the time when we would want to look at adjusting > the key expansion to separate keys and IVs (assuming we still > have IVs). If the IVs are secret (only shared between the two peers) then I don't see the need to change how they are calculated from the keyblock. Cheers, Brian From nobody Wed Mar 25 12:12: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 F3BFA1A9055 for ; Wed, 25 Mar 2015 12:12:55 -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 yE4lmYcrNiyI for ; Wed, 25 Mar 2015 12:12:54 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 41E621A89A3 for ; Wed, 25 Mar 2015 12:12:54 -0700 (PDT) Received: by wixw10 with SMTP id w10so52689634wix.0 for ; Wed, 25 Mar 2015 12:12:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A/bdyjT8kqWbuasm/MW/QFzSRLMXBQL0TpmlwZ6EOak=; b=AKCmcHhNhdakvZOCeQqnMUf1H+tjOMpB8DUfz+fUq3Hflkmgo3Ka33evXTKMkuopSi OxY4+b6McLx/406DH01pzPuVmxsbcYL7GJfcV/em0+w4sH2KYVMm0rKbp6rbMMnTLzJa 9tLO1qcnFkt77zGX4wCFndXVRTpA1LiBsBwDDVu0UpBhGcj9vMKgcI/V4XQwYZ8Uv6Fg XBQNsniNj+5icrJ4/pewn33ZRmCEcsQjH/NBrYhe/PGmh1cQtqLoRZRXEsMWueTfeN9o 83+IaCXKlF3Xz93Xn7R9ZbCWFPHIM2+C1cvYusqTSFJd2txMu40JUwGA6VJFL860cAST bN4w== X-Gm-Message-State: ALoCoQmKQ7kWbOxNcNyqLYNGcWGuLEKaVRci9Oa8TC5PLJ0id+bU1m7nYP93WwZwmxN5RrPF+u+m X-Received: by 10.180.84.99 with SMTP id x3mr22276760wiy.35.1427310773013; Wed, 25 Mar 2015 12:12:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Wed, 25 Mar 2015 12:12:12 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 25 Mar 2015 14:12:12 -0500 Message-ID: To: Brian Smith Content-Type: multipart/alternative; boundary=f46d044403a89c20a4051221afba Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:12:56 -0000 --f46d044403a89c20a4051221afba Content-Type: text/plain; charset=UTF-8 On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith wrote: > Eric Rescorla wrote: > > As I mentioned in a previous message [0] during the interim we discussed > > moving from the TLS PRF to HKDF [RFC5869]. > > > > The general sentiment was: > > > > - Move to HKDF > > - Specify both SHA-256 and SHA-384 (the latter being required for > > Suite B) > > Assuming that the choice of either SHA-256 or SHA-384 is fixed per > cipher suite, as is the case with TLS 1.2, switching to HKDF seems > like a good idea to me. > > > This is also the time when we would want to look at adjusting > > the key expansion to separate keys and IVs (assuming we still > > have IVs). > > If the IVs are secret (only shared between the two peers) then I don't > see the need to change how they are calculated from the keyblock. > The issue is that in many cases the IV will be handled outside the crypto module, and the keys should stay inside the crypto module. The traditional slice and dice makes that hard. -Ekr --f46d044403a89c20a4051221afba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith <brian@briansmith.org<= /a>> wrote:
Er= ic Rescorla <ekr@rtfm.com> wrote:=
> As I mentioned in a previous message [0] during the interim we discuss= ed
> moving from the TLS PRF to HKDF [RFC5869].
>
> The general sentiment was:
>
> - Move to HKDF
> - Specify both SHA-256 and SHA-384 (the latter being required for
>=C2=A0 =C2=A0Suite B)

Assuming that the choice of either SHA-256 or SHA-384 is fixed per cipher suite, as is the case with TLS 1.2, switching to HKDF seems
like a good idea to me.

> This is also the time when we would want to look at adjusting
> the key expansion to separate keys and IVs (assuming we still
> have IVs).

If the IVs are secret (only shared between the two peers) then I don= 't
see the need to change how they are calculated from the keyblock.

The issue is that in many cases the IV will be h= andled outside the crypto
module, and the keys should stay inside= the crypto module. The traditional
slice and dice makes that har= d.

-Ekr

--f46d044403a89c20a4051221afba-- From nobody Wed Mar 25 19:08: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 1A2A21A1C02 for ; Wed, 25 Mar 2015 19:08:29 -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 E4NHzXSCIhjl for ; Wed, 25 Mar 2015 19:08:27 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 DABC11A1DE1 for ; Wed, 25 Mar 2015 19:08:26 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so30930727lbc.2 for ; Wed, 25 Mar 2015 19:08:25 -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:from:date:message-id :subject:to:cc:content-type; bh=Z/SRhoW3QsxQFUOpYsk/moxFKhN1qTyHPqxEReDfdEs=; b=MkCnpOqjkM0dJrlukmsaqAr6KeA//DQubnjoTUMlFaH72CY58NfThOV8DY5kMAN4vv XGl/9rHKvjMGc7Cpj5COdfMHOT5GpJRRrCqPO1pfAWEJ+D9tXvh34OpwJrsqccn/EtOC km5Rmjt2eqdrsZr+uFcHVcbh/sfsnyS/zebgA6Ne2DDhTamGQxOZNZGzI65GJhhehJo2 swtWTDKgTqXnGi3EcY19Imh+kKvgz8oY0yVQL6aCUD7I2l0poo8xrBwgFcC7mOANjokK L2LfHg4fRw7aXfmaBv0fd5Ru/Q+MPMTHHdLt+zKVG2BB6xRx+h80dSCZiIJMz5zmFzfO FDwQ== X-Received: by 10.152.87.144 with SMTP id ay16mr11422618lab.10.1427335705402; Wed, 25 Mar 2015 19:08:25 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.9 with HTTP; Wed, 25 Mar 2015 19:07:55 -0700 (PDT) In-Reply-To: <1427297776.4885.47.camel@redhat.com> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> <1427297776.4885.47.camel@redhat.com> From: Hugo Krawczyk Date: Wed, 25 Mar 2015 21:07:55 -0500 X-Google-Sender-Auth: 9VCmSCSC32R_1v2YcPbVy5ifVVM Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a11c235e6b224060512277d0e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 02:08:29 -0000 --001a11c235e6b224060512277d0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 25, 2015 at 11:36 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote: > > > > One idea for meaningful reduction of complexity in TLS is if > > we could switch to cipher-based KDF. > > =E2=80=8BThat's for the WG to decide but the results we have for the > > extraction properties of block-cipher based PRFs are much weaker. > > I'm not sure whether the WG should even decide on replacing the KDF or > the main protocols used. That was certainly a non-goal for TLS 1.3 and > =E2=80=8B There is an explicit goal of supporting forward secrecy and 0-RTT. Both require changes to the protocol, in particular the latter requires introducing server's (semi) static DH keys and an authentication mode that cannot be solely based on signatures hence necessarily departing from previous TLS versions. You could add support for the above elements as a patch/addition to the protocol but even then you would need a review of the new cryptographic elements and their interaction with the old ones (which may be trickier to analyze than a well-formed uniform protocol). Hugo =E2=80=8B > is a cryptographic decision which is not the expertise of this group. > For such decisions, and even simpler (see Salsa20, ChaCha cipher > addition) this working group delegated these decisions to CFRG, and I > believe this should also be done now if we go the path of replacing > core TLS structure. > > regards, > Nikos > > > --001a11c235e6b224060512277d0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 25, 2015 at 11:36 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
<= span>On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote:


>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One idea for meaningful reduction of = complexity in TLS is if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we could switch to cipher-based KDF.<= br> > =E2=80=8BThat's for the WG to decide but the results we have for t= he
> extraction properties of block-cipher based PRFs are much weaker.

I'm not sure whether the WG should even decide on replacing the = KDF or
the main protocols used. That was certainly a non-goal for TLS 1.3 and
<= /blockquote>

=E2=80=8B
There is= an explicit goal of supporting forward secrecy and 0-RTT.
Both require changes to the protocol, in particular the latter requires=20 introducing server's (semi) static DH keys and an authentication mode= =20 that cannot be solely based on signatures hence necessarily departing=20 from previous TLS versions. You could add support for the above elements as a patch/addition to the protocol but even then you would need a=20 review of the new cryptographic elements and their interaction with the=20 old ones (which may be trickier to analyze than a well-formed uniform=20 protocol).

Hugo
=E2=80=8B
= =C2=A0
is a cryptographic decision which is not the expertise of this group.
For such decisions, and even simpler (see Salsa20, ChaCha cipher
addition) this working group delegated these decisions to CFRG, and I
believe this should also be done now if we go the path of replacing
core TLS structure.

regards,
Nikos



--001a11c235e6b224060512277d0e-- From nobody Wed Mar 25 19:36: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 5D7701A6F1D for ; Wed, 25 Mar 2015 19:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoRglbbwCQzz for ; Wed, 25 Mar 2015 19:36:02 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (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 B9C8F1A6F0E for ; Wed, 25 Mar 2015 19:36:02 -0700 (PDT) Received: by oier21 with SMTP id r21so38377762oie.1 for ; Wed, 25 Mar 2015 19:36:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XlaIIzyPbvYtHcV1tGkM/DV65uoVQen2LHbvqXB63+k=; b=NypYytK82R5RDJSi48tiUw3U6/gZrQegzvZe3sq3ruWMXkaA8KdCEV4pJWf5meG6ve C9AWmJElJM4Y/UrJm5UV9tRJHI8UcDCb83lYZyNwbzKPQC8vzMSItUxWh5goObDEjH7Q sv2GwA5lOsqI4LrpviKnLUNuILhf2i8hbM7o6IXGRM3HybhruxiR62e259bd/EUdhMaY W3NWlGKBn1tZo9Wi+HebCc3OuZgBlkK3ifMJ8B1gdJ01hJAT273eGvE+WYrylsgjGsn0 nJPngNGa1sVwILwTv2v9AgeExEfQsyI416xtvfD2nFmLECErBz3v0FBzhb//cyxExRFP PARw== X-Gm-Message-State: ALoCoQmc4+urGyw2NNciWz990KxZ4/Qq8eghzvUy5YkwJTSzwhxWBm2UskXz1sX6xMGcDtlthNfA MIME-Version: 1.0 X-Received: by 10.202.178.134 with SMTP id b128mr9539760oif.80.1427337362119; Wed, 25 Mar 2015 19:36:02 -0700 (PDT) Received: by 10.76.144.105 with HTTP; Wed, 25 Mar 2015 19:36:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Mar 2015 16:36:02 -1000 Message-ID: From: Brian Smith To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 02:36:04 -0000 Eric Rescorla wrote: > On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith wrote: >> If the IVs are secret (only shared between the two peers) then I don't >> see the need to change how they are calculated from the keyblock. > > The issue is that in many cases the IV will be handled outside the crypto > module, and the keys should stay inside the crypto module. The traditional > slice and dice makes that hard. When the implementation cares about this, won't it also care that the nonce/IV is completely managed within the crypto module too? Otherwise, for certain things like AES-GCM, the application could attack the crypto module reusing a nonce in order to learn the key. Using the design I suggested in [1] allows the crypto module to completely manage the nonce/IV in a way that makes such abuse impossible. In fact, with that design, the crypto module doesn't even need to tell the application what the nonces/IVs are. And that can happen without changing how the nonces are derived from the keyblock. Conversely, if the crypto module *doesn't* work like that, then it isn't clear to me that it is actually offering a useful amount of protection of the key material. It doesn't seem useful to make things more complicated in order to support that kind of design, which seems broken. Cheers, Brian [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html From nobody Thu Mar 26 00:16: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 DCE841ACDD3 for ; Thu, 26 Mar 2015 00:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fu_GU7JyY5zM for ; Thu, 26 Mar 2015 00:16:06 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8C91A7002 for ; Thu, 26 Mar 2015 00:16:05 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 6AD6481856; Thu, 26 Mar 2015 09:15:59 +0200 (EET) Date: Thu, 26 Mar 2015 09:15:59 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150326071559.GA6108@LK-Perkele-VII> References: <7FA320AE-B9C2-412D-B84B-DB4CAB05B325@gmail.com> <5510FDC8.1060702@brainhub.org> <358E3F82-0777-42A1-AA75-F31AA3C2103B@gmail.com> <20150324121632.GA28552@LK-Perkele-VII> <1427297776.4885.47.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 07:16:09 -0000 On Wed, Mar 25, 2015 at 09:07:55PM -0500, Hugo Krawczyk wrote: > On Wed, Mar 25, 2015 at 11:36 AM, Nikos Mavrogiannopoulos > wrote: > > > On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote: > > > > > > > One idea for meaningful reduction of complexity in TLS is if > > > we could switch to cipher-based KDF. > > > ​That's for the WG to decide but the results we have for the > > > extraction properties of block-cipher based PRFs are much weaker. > > > > I'm not sure whether the WG should even decide on replacing the KDF or > > the main protocols used. That was certainly a non-goal for TLS 1.3 and > > > > ​ > There is an explicit goal of supporting forward secrecy and 0-RTT. > Both require changes to the protocol, in particular the latter requires > introducing server's (semi) static DH keys and an authentication mode that > cannot be solely based on signatures hence necessarily departing from > previous TLS versions. You could add support for the above elements as a > patch/addition to the protocol but even then you would need a review of the > new cryptographic elements and their interaction with the old ones (which > may be trickier to analyze than a well-formed uniform protocol). Well, these changes to "unify" the key exchange completely change how to the key exchange works, and need to completely redo any security analysis. This is nasty for multiple reasons: a) The scope of analysis is very broad (there have been a number of "TLS proven secure" papers that don't prove TLS secure, due to insufficient scope) b) The changes to proposed look to make it much harder to analyze, even if 0RTT is assumed unsupported c) When 0RTT is added, I don't see how the changes make the interaction any easier to analyze. -Ilari From nobody Thu Mar 26 00:24:45 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 539BC1B2C0C for ; Thu, 26 Mar 2015 00:24: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, 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 PtR9-iTgZztN for ; Thu, 26 Mar 2015 00:24:43 -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 C57E51A7002 for ; Thu, 26 Mar 2015 00:24:42 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 928F99006D; Thu, 26 Mar 2015 09:24:40 +0200 (EET) Date: Thu, 26 Mar 2015 09:24:40 +0200 From: Ilari Liusvaara To: Brian Smith Message-ID: <20150326072440.GB6108@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] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 07:24:44 -0000 On Wed, Mar 25, 2015 at 04:36:02PM -1000, Brian Smith wrote: > Eric Rescorla wrote: > > On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith wrote: > >> If the IVs are secret (only shared between the two peers) then I don't > >> see the need to change how they are calculated from the keyblock. > > > > The issue is that in many cases the IV will be handled outside the crypto > > module, and the keys should stay inside the crypto module. The traditional > > slice and dice makes that hard. > > Conversely, if the crypto module *doesn't* work like that, then it > isn't clear to me that it is actually offering a useful amount of > protection of the key material. It doesn't seem useful to make things > more complicated in order to support that kind of design, which seems > broken. Turns out you can't even implement TLS fully in design that does not know about TLS, nor does it seem one can even change TLS so that would be possible (at least without introducing gaping security holes). -Ilari From nobody Thu Mar 26 00:30: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 A3FF01A7002 for ; Thu, 26 Mar 2015 00:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3zX9mktL1XW for ; Thu, 26 Mar 2015 00:30:46 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 1BF361A8837 for ; Thu, 26 Mar 2015 00:30:46 -0700 (PDT) Received: by qgh3 with SMTP id 3so69830840qgh.2 for ; Thu, 26 Mar 2015 00:30:45 -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:mime-version:content-type :content-transfer-encoding:message-id; bh=TSn3LnuzUQkbdHDj3YE66l2KYSowedNVy9C8A1v5EqM=; b=0HzLLd9u5bx6pSszgZmezyY9h7K+r/fJEklF1pEO6xSijTRxlcoZuBNTYy2LNK8YyR gVxxfkXWFMGDc+wneXKu9REsQ0H3yHXQ2ImtwU98dINIInRThYEX9SDgRydXbjtbWUBt ldwf0y+yCcJtzpFzLhTj4UeUwGW2mIYZKe5SzBhyVNxnNh2sgvB3eoC4MIQxvUDKtwVr Sphh8UsTUy8XvEmArPvHsx+dUxSQNrlpBnQg6Ik5Q/ZeKMdKjItLLg0brgDGL3sz9oAd f/nuN4pMR85e82TvnI/09wzMvCvas+ZyHSoSGFM8fhUKo5gPVQWRRI5etYe/sW27iHGt 3Nfw== X-Received: by 10.229.118.5 with SMTP id t5mr16932087qcq.19.1427355045443; Thu, 26 Mar 2015 00:30:45 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g34sm3072196qgd.0.2015.03.26.00.30.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 00:30:44 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Brian Smith Date: Thu, 26 Mar 2015 03:30:42 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201503260330.43588.davemgarrett@gmail.com> Archived-At: Subject: [TLS] New TLS version negotiation mechanism, take 2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 07:30:47 -0000 Based on feedback in the previous discussion, I think I've cobbled together a framework that might be good to use. * A new extension that contains a single ProtocolVersion, with its value named max_version * Rename ClientHello.client_version to min_version * Rename ServerHello.server_version to negotiated_version * Convert ProtocolVersion to a 16-bit enum, with equivalent values to existing struct format * The values are as follows: 1) record layer version frozen to TLS_version_1_0(0x0301) (PR #107) 2) ClientHello.min_version set to TLS_version_1_2(0x0303) (for clients supporting TLS 1.2, this is a constant; clients not supporting TLS 1.x set this to their higher min version) 3) Both endpoints set their max_version (in ext) to their max supported version (all clients send; all servers reply if clients send; these values are constant based on config) 4) ServerHello.negotiated_version is picked in a manner similar to now, but from the endpoints' max_version fields. If the new extension is not supported, it transparently falls back to TLS 1.2, and old servers will fall back to TLS 1.0/1.1 if needed. Servers now have a min_version from client to not offer to fall back too far at all. Version IDs 0x0304 through 0x03FF can be assigned as IDs for upcoming draft versions. The final version will be assigned 0x0400. As there's no longer an attempt to do something vaguely akin to major.minor, the values are arbitrary and can be assigned for draft/experimental versions as needed. Negotiation logic specifies that servers picking a lower version must pick a stable version if the client did not explicitly offer a supported experimental version. This seems to get pretty much what we want here: + TLS 1.3+ version intolerance is not an issue, unless the client refuses to negotiate TLS 1.x, in which case it doesn't matter. (it won't work regardless of the server responding ideally or not) + Only one extension with one fixed length value + Both stable and draft/experimental versions can use the same negotiation mechanism (and get tested) + It's more or less as simple as can be, given that we're hacking in a new mechanism on top of the old. Yeah, lots of version fields, but almost all are constants. + All the various version fields are now named so as to indicate what they're actually for Ditching the version field from the encrypted records is a very good idea to go along with this, as it's useless and yet another version field to confuse things. I've created a branch with a very WIP set of changes. I have not updated the backwards compatibility section for this new system fully yet. (just a bunch of TODOs listed there) The other appendix bits are not added either, and there's a few other spots that need some extra explanation. This is just to get the main idea of this proposal for discussion. This is based on PR #107: https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:NVN Dave From nobody Thu Mar 26 02:31: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 C75581ACE26 for ; Thu, 26 Mar 2015 02:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VVdv0MP5uIOL for ; Thu, 26 Mar 2015 02:31:43 -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 66AEF1ACE29 for ; Thu, 26 Mar 2015 02:31:42 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id A5DF84499A; Thu, 26 Mar 2015 10:31:39 +0100 (CET) X-purgate-ID: 152705::1427362299-0000765A-4674720A/0/0 X-purgate-size: 2739 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 7E64D446DA; Thu, 26 Mar 2015 10:31:39 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 749441B245; Thu, 26 Mar 2015 10:31:39 +0100 (CET) In-Reply-To: <493A881F-9A1A-4AF7-A55F-85AC98D60F90@vigilsec.com> To: Russ Housley Date: Thu, 26 Mar 2015 10:31:39 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150326093139.749441B245@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: IETF TLS Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 09:31:46 -0000 Russ Housley wrote: > > On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen wrote: > On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla wrote: >> During the interim we discussed discussion about adopting PSS for >> RSA signatures in TLS 1.3. >> >> Clearly, we will not be able to just adopt PSS because certificates >> will continue to be signed with PKCS#1 1.5. > > I would like to see TLS 1.3 allow certificates signed using PSS (RFC > 4055 and 3447) and provide a way to signal the server that such > certificates are supported. Originally, using certificates signed with PSS "just works" with SSLv3 and TLS, provided that the PKI-implementation called by the TLS stack implements it. (openssl-0.9.8 does not, Windows XP & 2003 do not). A problem was newly created in 2008 specifically for TLSv1.2 by the botched semantics of the TLSv1.2 signature_algorithms TLS extension, which conflates the algorithms used for "digitally_signed" within the TLS protocol and the algorithms used by CAs to issue certs. Most TLSv1.2 implementors seem to have delibertately (or accidentally) ignored the botched semantics of the TLSv1.2 signature_algorithm extension with respect to the signatures on certificates, however. > > I have wanted to see migration of signatures on certificates from > PKCS#1 v1.5 to PSS for many years. I think this is a nice step for > that to happen. The major problem with RSA-PSS is not the PKCS#1 v2.1 RSA-PSS signature transform, but the policy crap described in rfc4055. To reliably support RSA-PSS in TLS, we would have to first fix the TLSv1.2 signature_algorithms extension by replacing it with one that uses resonable semantics and clearly seperates the digitally-signed transform within the TLS protocol from the signatures on X.509 certificates, otherwise the installed base would have to limit itself to at most TLSv1.1. > > That said, I'd like to see this done in a way that also encourages the > transition to ECDSA for the signatures on the certificates. ECDSA is a well-known flawed signature scheme, and from the attacks that have been published, there currently seems to exists no implementation that will not leak the private key through online signatures. And for verification of offline signatures, RSA is much faster. Considering that NSA has been pushing ECDSA with NSA curves intensively long before the Snowden leaks, it would be silly to assume that their curves are not backdoored. We currently won't loose anything (of value) by obsoleting the ECDSA signature scheme and deprecating the NSA curves, by moving to safe curves and a less dangerous signature scheme than ECDSA. -Martin From nobody Thu Mar 26 03:49: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 559EF1B2C6A for ; Thu, 26 Mar 2015 03:49:48 -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 lXRCIBBtC-IW for ; Thu, 26 Mar 2015 03:49:45 -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 5C8321B2C66 for ; Thu, 26 Mar 2015 03:49:43 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 5ED7C699F8; Thu, 26 Mar 2015 12:49:40 +0200 (EET) Date: Thu, 26 Mar 2015 12:49:40 +0200 From: Ilari Liusvaara To: Martin Rex Message-ID: <20150326104940.GA7254@LK-Perkele-VII> References: <493A881F-9A1A-4AF7-A55F-85AC98D60F90@vigilsec.com> <20150326093139.749441B245@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150326093139.749441B245@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: IETF TLS Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 10:49:48 -0000 On Thu, Mar 26, 2015 at 10:31:39AM +0100, Martin Rex wrote: > Russ Housley wrote: > > > > On Sun, Mar 22, 2015 at 10:38 PM, Peter Bowen wrote: > > On Sun, Mar 22, 2015 at 3:09 PM, Eric Rescorla wrote: > >> During the interim we discussed discussion about adopting PSS for > >> RSA signatures in TLS 1.3. > >> > >> Clearly, we will not be able to just adopt PSS because certificates > >> will continue to be signed with PKCS#1 1.5. > > > > I would like to see TLS 1.3 allow certificates signed using PSS (RFC > > 4055 and 3447) and provide a way to signal the server that such > > certificates are supported. > > Originally, using certificates signed with PSS "just works" with SSLv3 > and TLS, provided that the PKI-implementation called by the TLS stack > implements it. (openssl-0.9.8 does not, Windows XP & 2003 do not). > > A problem was newly created in 2008 specifically for TLSv1.2 by the > botched semantics of the TLSv1.2 signature_algorithms TLS extension, > which conflates the algorithms used for "digitally_signed" within the > TLS protocol and the algorithms used by CAs to issue certs. You mean "MUST be the same" semantics, deliberately banning PSS (I think I saw that in some place) or one can't assume that what can be validated as digitally_signed can be validated as cert signature? BTW: I saw one TLS stack (AFAIK, it was TLS 1.2 capable) that had no problem using RSA key for the server certificate and DSA key for the client certificate (or vice versa)... Dunno how complant that is. > > I have wanted to see migration of signatures on certificates from > > PKCS#1 v1.5 to PSS for many years. I think this is a nice step for > > that to happen. > > The major problem with RSA-PSS is not the PKCS#1 v2.1 RSA-PSS signature > transform, but the policy crap described in rfc4055. Well, it is PKIX... > To reliably support RSA-PSS in TLS, we would have to first fix the TLSv1.2 > signature_algorithms extension by replacing it with one that uses > resonable semantics and clearly seperates the digitally-signed transform > within the TLS protocol from the signatures on X.509 certificates, > otherwise the installed base would have to limit itself to at most TLSv1.1. So one can't assume the client supports the same algos for both? > > > > That said, I'd like to see this done in a way that also encourages the > > transition to ECDSA for the signatures on the certificates. > > ECDSA is a well-known flawed signature scheme, and from the attacks > that have been published, there currently seems to exists no implementation > that will not leak the private key through online signatures. And for > verification of offline signatures, RSA is much faster. Well, on low security levels it is much faster. On high level it becomes slower (unless ECC gets broken). ECDSA is very difficult to implement just without having timing attacks out the wazoo[1]. And looking at internal strucure of P-256, that makes it even more difficult (Weierstrass, bad order, etc...). > Considering that NSA has been pushing ECDSA with NSA curves intensively > long before the Snowden leaks, it would be silly to assume that their > curves are not backdoored. Also, (EC)DSA was inferrior to state-of-the-art already when it was proposed. And the reasons why are AFAIK classified. > We currently won't loose anything (of value) by obsoleting the ECDSA > signature scheme and deprecating the NSA curves, by moving to safe curves > and a less dangerous signature scheme than ECDSA. Well, some do have to use it... But most don't. [1] I _think_ I have done so once. It was quite slow and pulled off invented-less-than-10-years-ago tricks with ECC that won't work with NIST/NSA curves. And I was specially taking timing attacks into consideration. Somebody who doesn't know about this stuff won't even stand a chance. -Ilari From nobody Thu Mar 26 07:18: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 494161ACECE for ; Thu, 26 Mar 2015 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hNhCXFeOO507 for ; Thu, 26 Mar 2015 07:18:38 -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 81BA81ACECF for ; Thu, 26 Mar 2015 07:18:33 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 1C2236FEC86E3 for ; Thu, 26 Mar 2015 14:18:28 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2QEITsO022120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 15:18:30 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 15:18:29 +0100 From: "GUBALLA, JENS (JENS)" To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-guballa-tls-terminology-01.txt Thread-Index: AdBnz7qsCmx9u40pRkimi37xlG2omQ== Date: Thu, 26 Mar 2015 14:18:29 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A341194@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0097_01D067D8.1C754A30" MIME-Version: 1.0 Archived-At: Subject: [TLS] New Version Notification for draft-guballa-tls-terminology-01.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, 26 Mar 2015 14:18:44 -0000 ------=_NextPart_000_0097_01D067D8.1C754A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A new version of draft-guballa-tls-terminology is available. Name: draft-guballa-tls-terminology Revision: 01 Title: Terminology related to TLS and DTLS Document date: 2015-03-26 Group: Individual Submission Pages: 32 URL: http://www.ietf.org/internet-drafts/draft-guballa-tls-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-guballa-tls-terminology/ Htmlized: http://tools.ietf.org/html/draft-guballa-tls-terminology-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-guballa-tls-terminology-01 Abstract: Purpose of this RFC is to provide a central place of all key terms as used by the various RFCs on protocols TLS and DTLS. Regards, Jens ------=_NextPart_000_0097_01D067D8.1C754A30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWSTCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIGfTCCBWWgAwIBAgIKRWwXQQAAAACdHDANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTMwOTE3MTQ1MjM4WhcNMTUwOTE3 MTQ1MjM4WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrjfAo1dzqvHuB AwJhoRVC3mbaCowaDmd9WFkrzoOfDaqDlkEmHeDq46udrYiIHkF6OE61T54M225lLXjD9CylO6jK b+WsZ/84tTzYCy36qeg8JUD7vTeMJG581LiXw8XMBaMBkBqKg/sR0ZkCqCSsi8aCrhQys8+6Tr4O pJFz5QIDAQABo4IDszCCA68wCwYDVR0PBAQDAgeAMD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcV CIW9xVmD47E5h6WBKoa/w0KFlJgZgQuE0LRahcPhRAIBZAIBDDAdBgNVHQ4EFgQUiJYaL8Km8mUp QxwCyGv/p+vMVQAwHwYDVR0jBBgwFoAU2exrvZZYIvfYpnfN/k2B77qXvRIwggFcBgNVHR8EggFT MIIBTzCCAUugggFHoIIBQ4aB2WxkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUyMEludGVybmFs JTIwU3ViJTIwQ0EsQ049dXNuYXZzcGtpMDNwLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNv bT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0 aW9uUG9pbnSGK2h0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmyGOGh0 dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JsMIIB YAYIKwYBBQUHAQEEggFSMIIBTjCBzAYIKwYBBQUHMAKGgb9sZGFwOi8vL0NOPUFsY2F0ZWwlMjBM dWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2 aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWx1YWQsREM9bHVjZW50LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTA3 BggrBgEFBQcwAoYraHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBE BggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BL SS9zdWJDQS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEF BQcDBDAqBgNVHREEIzAhgR9qZW5zLmd1YmFsbGFAYWxjYXRlbC1sdWNlbnQuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQCj2G+kebCkeR0vqSqzEqskEkd5IGr32c/FF4VsMFatUJsh03GCg93zpN0MBxWI /zoKbn+Y/5FWcBzgjNKhG3FI9ZGj4EhDsoGgYBIEeP0JLwPJXg0e3P/+meH94acUIH/7EfzKoJpz yvuAGXZ7mTS5WPoI+/EYN8+iK0N/h/sWrBbIFUnOgbTJqNJyqt9/VyNSS57g5OeaxzqHLHyRimT4 1OY5jKRc2n83Tm6rkMmAd54N4ImXE7oUt8QcCkGvfiD1X5KLHDwUHRTW9P9vASHtCzgWoUIHPSig 8ky5BH3OdJ6BKN8zqNRX81RLZpqmvHEqSWejhYXKy0nxDeixLaEXMIIHLjCCBhagAwIBAgIKRWzH hgAAAACdHTANBgkqhkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT 8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVj ZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTMwOTE3MTQ1 MzIzWhcNMTUwOTE3MTQ1MzIzWjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9q ZW5zLmd1YmFsbGFAYWxjYXRlbC1sdWNlbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDItuRpLIiez2JpW/GzSRS+hC0F0hFQ2X+BpGP+rINA9Y+unUUsAY1/B+xBX+qFaJ8XxmG3BRme R/V4cI4ixge0IaSkilImt3GiAMrPH5dfQhFkwv4fkOSdIa0vrAhQXbhDH9zk/phurPInp/bTYtBg uT5/Jd2ie3YHRAJuiDFJAwIDAQABo4IEZDCCBGAwCwYDVR0PBAQDAgUgMD4GCSsGAQQBgjcVBwQx MC8GJysGAQQBgjcVCIW9xVmD47E5h6WBKoa/w0KFlJgZgQuCupMPhOrffgIBZAIBDTCBlAYJKoZI hvcNAQkPBIGGMIGDMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYI KoZIhvcNAwcwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEARYwCwYJYIZIAWUD BAEZMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwHQYDVR0OBBYEFJheKnT4HqkKlFoz5GqZ0AkX lAXVMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXAYDVR0fBIIBUzCCAU8wggFL oIIBR6CCAUOGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hitodHRwOi8vd3d3LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0EuY3JshjhodHRwOi8vc2Vy dmljZXMuc3VwcG9ydC5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybDCCAWAGCCsGAQUF BwEBBIIBUjCCAU4wgcwGCCsGAQUFBzAChoG/bGRhcDovLy9DTj1BbGNhdGVsJTIwTHVjZW50JTIw SW50ZXJuYWwlMjBTdWIlMjBDQSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y0FDZXJ0 aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwNwYIKwYBBQUH MAKGK2h0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwRAYIKwYBBQUH MAKGOGh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvc3ViQ0Eu Y3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQBgjcVCgQcMBowCgYI KwYBBQUHAwQwDAYKKwYBBAGCNwoDBDAqBgNVHREEIzAhgR9qZW5zLmd1YmFsbGFAYWxjYXRlbC1s dWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDYFkloLQX9D6GLlsqWsAKnOLYIpanp0MxnxZdX 5Q1yePq+XEnwBmBNnv1Tgo5tgrZlva4QPX2INU7eNkfuyKy384TJLrNPrv05LcdvgkLaNcA093ud zsOsCfP8WnJGS0FF8PKI/ihLH3HdgtiyXVflvwWywmE+jGmG/8i82chowoRgiEI8pqwtBX5NWXqr /S7d8RwgWf3SIE2iUeGedQhnECuN0xpGC4P0TfqoB8xmWdtUev/jj63w+mGGTwfH3ESYS3jcqeek OQQGtlLmV4hcmJPnTXC4i7Ou2jDV3Xbg5zhz0ZeUQsLTRLcDy+k6ANFtBlr3Y8NPC9MJIMUSc9G9 MYIDqDCCA6QCAQEwgZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZs dWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUG A1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBAgpFbBdBAAAAAJ0cMAkGBSsOAwIa BQCgggJpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjE0 MTgyOFowIwYJKoZIhvcNAQkEMRYEFH4eZlvRLGINMw3VdBW76yHjMgI+MIGlBgkrBgEEAYI3EAQx gZcwgZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxj YXRlbCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBAgpFbMeGAAAAAJ0dMIGnBgsqhkiG9w0BCRACCzGB l6CBlDCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIG CgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0ECCkVsx4YAAAAAnR0wgbcGCSqGSIb3DQEJDzGBqTCB pjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZIhvcNAgUwDQYJ KoZIhvcNAQEBBQAEgYBNj4/Z7vWCBpjRleUwpfHtiv+L2WBF3fFbPGzMbBQNNrgHPRG/e+GwraXW jm3NfpV7jIEe842igOVgbZ3cX7Wc7/m7cpHKlt3nMA8ZBeYUnW4c+VrAChJbEmTntD+ATEfIL3HL owLIfm6HMArJ87bGxDEe2lTBOgMxFISMmgDFDQAAAAAAAA== ------=_NextPart_000_0097_01D067D8.1C754A30-- From nobody Thu Mar 26 07:53: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 128961ACEF6 for ; Thu, 26 Mar 2015 07:53:10 -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 lSGG_Pb-8ZDP for ; Thu, 26 Mar 2015 07:53:00 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 D05001A03B3 for ; Thu, 26 Mar 2015 07:51:33 -0700 (PDT) Received: by wgra20 with SMTP id a20so66853521wgr.3 for ; Thu, 26 Mar 2015 07:51:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yjx6906FHZa8Rd4mns8s4cP1kSrvWKZiBTFPx3LCtPI=; b=W2pglY8cyttZGhRpwmuu3FLYwUNmi1li4l2tFT3GyXoK7DL0nHgdC8BqZVwDP4XzHA MvzGuwxXr0ql+5PpwL9egyz9rtwrMxpfx7kdrbYEws0tX0baKTOxG9zf+823rpdR2RlS pyOfgJalxBgujm9AlM502FDYhMh651ciaTyE8obWSEv5K1G4Vr7PL0TF+kB2K7WkbJ6z nPUvVqemSyWEeWzT98zLrQZ6BbNPtVoFmq/YgwgXQDdo7LtAu1iTs+TyW4p53eA1Fmen WaPbksMBQeb1+QPshBPRXn2AFs5adibJ9w84iM/eHnAZWuacpEfOiIPhE0gr6waPpcEb Km+g== X-Gm-Message-State: ALoCoQmEn7mP/1B5EtEpfsEAUlWQ2ErVL5BeVRads7wYg5L40C0C8L4/vgqOImqhKfXVxyI666hj X-Received: by 10.194.176.162 with SMTP id cj2mr28370066wjc.93.1427381492400; Thu, 26 Mar 2015 07:51:32 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:f157:b8d9:3dde:b6b4? ([2001:67c:370:176:f157:b8d9:3dde:b6b4]) by mx.google.com with ESMTPSA id nd15sm9314350wic.8.2015.03.26.07.51.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 07:51:31 -0700 (PDT) Message-ID: <55141CFD.8010904@nthpermutation.com> Date: Thu, 26 Mar 2015 10:51:41 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:53:10 -0000 On 3/25/2015 10:36 PM, Brian Smith wrote: > Eric Rescorla wrote: >> On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith wrote: >>> If the IVs are secret (only shared between the two peers) then I don't >>> see the need to change how they are calculated from the keyblock. >> The issue is that in many cases the IV will be handled outside the crypto >> module, and the keys should stay inside the crypto module. The traditional >> slice and dice makes that hard. > When the implementation cares about this, won't it also care that the > nonce/IV is completely managed within the crypto module too? > Otherwise, for certain things like AES-GCM, the application could > attack the crypto module reusing a nonce in order to learn the key. Not exactly. On the encrypt side, there's a desire that the IV/Nonce be produced and controlled by the crypto module, but doing that is actually pretty hard given the large number of different ways of forming said nonce proposed by different protocols and usages (e.g. compare what TLS is doing to what Zigbee or other IOT protocols are doing). On the decrypt side, you *must* provide the input IV/Nonce as an input - it can't be generated internally for the reasons mentioned above and there are also issues with lost or ignored (untimely) messages (general crypto issue, not typically a TLS one) > Using the design I suggested in [1] allows the crypto module to > completely manage the nonce/IV in a way that makes such abuse > impossible. In fact, with that design, the crypto module doesn't even > need to tell the application what the nonces/IVs are. And that can > happen without changing how the nonces are derived from the keyblock. But doing that requires that the module have yet another TLS specific method. The general contract (going back to probably the first version of PKCS11 and others) for encrypt/decrypt APIs is a per-message IV. AEAD modes such as CCM and GCM are trying to modify that contract to make the encrypt dependent on a per-session value concatenated with a per-message value (with a counter for the per-block part). I'm no longer working with the PKCS11 folks at Oasis, but a year ago what we were looking at was some form of PKCS11 mechanism that might be called an IV generator. The set of those mechanisms was not small. > > Conversely, if the crypto module *doesn't* work like that, then it > isn't clear to me that it is actually offering a useful amount of > protection of the key material. It doesn't seem useful to make things > more complicated in order to support that kind of design, which seems > broken. My personal goal is to be able to build a crypto module that has NO TLS specific tweaks - where I can provide as inputs (safely in that doing this doesn't adversely affect security) that allow the module do TLS, but where doing that or allowing that doesn't prevent the module from doing say IPSEC, Zigbee, etc also securely. Moving to a "standard" KDF is a good start. Removing the first message IV/per-session Nonce generation from the master key expansion is even more helpful. Mike > > Cheers, > Brian > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Mar 26 07:57: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 CE9F81A0373 for ; Thu, 26 Mar 2015 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip1K3hvPjyaG for ; Thu, 26 Mar 2015 07:57:21 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (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 342191AD06E for ; Thu, 26 Mar 2015 07:55:41 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so66573951wgb.0 for ; Thu, 26 Mar 2015 07:55:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4mePFCWCfwyu9ZLEytSoaUQStO2BYwduDcQ2WoKNOzM=; b=iLtQDOLLrPqAj/F4T9sI0hSTPQgdFcUaBr2KR1/eEHjIOx4wZUikx5mRsBqtGCAvHo iPFeaRKbDjlSY4tsR1nW8Tqhxv7VPAMMovq6PtyC0hu4AuiOHTpISUYTkpM55YqmNKiJ +OKnCjP1STbzrxcn2YE5EA/++YaPidndEi7P85VPVCf852MDhmfORh50v4oFKgmtob19 /fFxmNeZ+TtgXwx/F9tkuBVxGaCZ+V4/Tpm/xawqeY2TFQ95mRmOM9r/S/BWx4VSKrM2 9+s6PE4xExmvq9ygeYysfutZmIHkxX6RSiEOY1TrDS4wa3gkXa7TJtnXi9sAWrnAS5uV i39A== X-Gm-Message-State: ALoCoQkKS61BR0GFovEEw1PhP4qqW+Hu1KVbE9Pwi5veA5ewCshGAiZGAmLPKAuVUfeAHiRui5VG X-Received: by 10.180.83.195 with SMTP id s3mr49297617wiy.54.1427381739509; Thu, 26 Mar 2015 07:55:39 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:f157:b8d9:3dde:b6b4? ([2001:67c:370:176:f157:b8d9:3dde:b6b4]) by mx.google.com with ESMTPSA id g2sm3085765wib.1.2015.03.26.07.55.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 07:55:38 -0700 (PDT) Message-ID: <55141DF4.2070906@nthpermutation.com> Date: Thu, 26 Mar 2015 10:55:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: tls@ietf.org References: <20150326072440.GB6108@LK-Perkele-VII> In-Reply-To: <20150326072440.GB6108@LK-Perkele-VII> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:57:23 -0000 On 3/26/2015 3:24 AM, Ilari Liusvaara wrote: > Turns out you can't even implement TLS fully in design that does not > know about TLS, This is true for TLS1.2 and before, mainly because of the master secret expansion and the PRF. Everything else is bog standard crypto. > nor does it seem one can even change TLS so that > would be possible (at least without introducing gaping security holes). I don't know that I believe that. TLS is a protocol wrapped around a set of cryptographic constructs. There are ways to use standard constructs in TLS to build a secure protocol. It will require some surgery on TLS1.2, but I think that's well underway. Mike From nobody Thu Mar 26 08:41: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 584481AD2C4 for ; Thu, 26 Mar 2015 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9445VfCB668 for ; Thu, 26 Mar 2015 08:40:57 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0596D1A00ED for ; Thu, 26 Mar 2015 08:40:57 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 94B2E9A4012; Thu, 26 Mar 2015 11:40:46 -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 FoIpYEoh-y3A; Thu, 26 Mar 2015 11:40:25 -0400 (EDT) Received: from [5.5.33.25] (vpn.snozzages.com [204.42.252.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 2AC329A4014; Thu, 26 Mar 2015 11:40:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20150326093139.749441B245@ld9781.wdf.sap.corp> Date: Thu, 26 Mar 2015 11:40:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150326093139.749441B245@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF TLS Subject: Re: [TLS] PSS for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 15:40:58 -0000 Martin: >> I have wanted to see migration of signatures on certificates from >> PKCS#1 v1.5 to PSS for many years. I think this is a nice step for >> that to happen. >=20 > The major problem with RSA-PSS is not the PKCS#1 v2.1 RSA-PSS = signature > transform, but the policy crap described in rfc4055. I do not know what you are referencing. There are ways to limit a = particular key to PSS if desired. Russ From nobody Thu Mar 26 09:33: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 CB21D1A87E2 for ; Thu, 26 Mar 2015 09:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aOR5kHYW04zR for ; Thu, 26 Mar 2015 09:33:26 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1F19C1A8949 for ; Thu, 26 Mar 2015 09:33:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6B8AC47798 for ; Thu, 26 Mar 2015 16:33:16 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5FEDF47795 for ; Thu, 26 Mar 2015 16:33:16 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 5BF478003C for ; Thu, 26 Mar 2015 16:33:16 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 26 Mar 2015 12:31:24 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Thu, 26 Mar 2015 12:31:23 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: Draft minutes from IETF 92 Thread-Index: AdBnzMwJmCFbGvO3RB6aOB5sq2b72w== Date: Thu, 26 Mar 2015 16:31:22 +0000 Message-ID: <4c1c3b9cad294bd49d6a5ba5f007eeff@usma1ex-dag1mb2.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.114.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Draft minutes from IETF 92 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:33:29 -0000 Draft minutes; please post corrections. Swap two agenda items (0RTT and OPTLS) Draft status update; see pages 5 and 6 of http://tools.ietf.org/agenda/92/s= lides/slides-92-tls-1.pdf WG chairs intend to ask if WG wants to adopt draft-mavrogiannopoulos-chacha-tls, draft-josefsson-tls-curve25519 and draf= t-bmoeller-tls-falsestart as documents (starting points,=20 Backward compatibility: reviewed github pull request 107; no controversy, = going to adopt it. =20 Changes since -03 draft http://www.ietf.org/proceedings/92/slides/slides-92= -tls-3.pdf Point format negotiation removed; add context to signatures (to= prevent re-use); remove renegotiation; remove ChangeCipherSpec; extendedMa= sterSecret draft is included; remove ability to negotiate sslv3 0RTT; client has "static" ephemeral key, encrypts first part using that, se= rver reply has its ephemeral, and now rest of data is PFS. This is well-un= derstood key exchange. Issues arise with anti-reply, based on each side pr= oviding random value mixed into keying material. With 0RTT client anti-repl= y guaranteed, but not server. Protect this with server cache. But that d= oesn't work; see p8-10, and mail list thread. Propose concept of a special= API to set or read the 0RTT payload. Strong consensus to do this, to be c= onfirmed on the list. There are concerns about how/when other protocols cou= ld use this. Sean to take up initial conversations. Ekr, dkg, agl to post s= omething to the list based on "option 3" on p11. DH-based handshake. First brought up in Paris Interim, discussed in HI, Se= attle Interim, etc. Moving to static DH based (two DH key exchanges) unif= ies 0RTT, 1RTT, PSK ciphers. There are some extra costs; server that doesn'= t do 0RTT it can make both keys the same and avoid the extra modexp Hugo pr= esented slides on the rationale for this approach; see http://www.ietf.org/= proceedings/92/slides/slides-92-tls-4.pdf . Basically since TLS 1.3 has P= FS 0RTT and EC-centric, there can be a unified approach (two dh keys). Also= benefit of simpler protocol to analyze and (perhaps only brand new) implem= entations. Discussion of possible loss of resumption. Should we move to = OPtls (pull request 90). Consensus hum was to do this. Move to HKDF. (Is there anything wrong with TLS PRF? Hugo: Yes, initially = keyed with a secret that is not necessarily strongly random; okay with RSA)= . HKDF has better properties. Strong consensus to do this. AEAED IV. Strong consensus to do nothing; some support for per-sesion XOR m= ask. To go to the list . -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Mar 26 09:44:34 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 258731A8798 for ; Thu, 26 Mar 2015 09:44:34 -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 bODXvYtgob2j for ; Thu, 26 Mar 2015 09:44:32 -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 8A4D61A8766 for ; Thu, 26 Mar 2015 09:44:31 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 4DF7A401A; Thu, 26 Mar 2015 18:44:27 +0200 (EET) Date: Thu, 26 Mar 2015 18:44:27 +0200 From: Ilari Liusvaara To: Michael StJohns Message-ID: <20150326164427.GA15103@LK-Perkele-VII> References: <20150326072440.GB6108@LK-Perkele-VII> <55141DF4.2070906@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55141DF4.2070906@nthpermutation.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:44:34 -0000 On Thu, Mar 26, 2015 at 10:55:48AM -0400, Michael StJohns wrote: > On 3/26/2015 3:24 AM, Ilari Liusvaara wrote: > >Turns out you can't even implement TLS fully in design that does not > >know about TLS, > > This is true for TLS1.2 and before, mainly because of the master secret > expansion and the PRF. Everything else is bog standard crypto. > > >nor does it seem one can even change TLS so that > >would be possible (at least without introducing gaping security holes). > > I don't know that I believe that. TLS is a protocol wrapped around a set of > cryptographic constructs. There are ways to use standard constructs in TLS > to build a secure protocol. It will require some surgery on TLS1.2, but I > think that's well underway. The problem is that TLS includes values that are potentially: - Exportable - Channel Binding - Secret All at the same time. Such value needs to chain to MS, and is exportable. -Ilari From nobody Thu Mar 26 12:48: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 5EA4E1B2B61; Thu, 26 Mar 2015 12:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, 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 VHRqavnN94ba; Thu, 26 Mar 2015 12:48:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 3AAD61B2DE2; Thu, 26 Mar 2015 12:48:37 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2QJmYcv026627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Mar 2015 21:48:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2QJmYeV007694; Thu, 26 Mar 2015 21:48:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21780.25234.61519.90042@fireball.kivinen.iki.fi> Date: Thu, 26 Mar 2015 21:48:34 +0200 From: Tero Kivinen To: tls@ietf.org, draft-ietf-tls-negotiated-ff-dhe@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 99 min Archived-At: Subject: [TLS] Draft-ietf-tls-negotited-ff-dhe-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:48:42 -0000 In Honolulu I verified that the primes generated in the draft-ietf-tls-negotited-ff-dhe correctly, i.e. I generated them again, and got same results. I also verified that they are primes using primo. This morning I checked that the new 2048 bit group added after that is also correct, but found problem there. The actual hex number in the draft is correct, but the formula for the numebr is wrong. I.e. A.1. ffdhe2048 says: The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560315 } * 2^64 - 1 but that does not match the hex number, there is off-by-one error. The number 560315 should be 560316 instead. https://www.wolframalpha.com/input/?i=2^2048+-+2^1984+++{trunc(2^1918+*+e)+++560315+}+*+2^64++++-+1+in+hex https://www.wolframalpha.com/input/?i=2^2048+-+2^1984+++{trunc(2^1918+*+e)+++560316+}+*+2^64++++-+1+in+hex I also put all the primo primality proof certificates on my web page (along with the IKE primality certificates): https://kivinen.iki.fi/primes/ -- kivinen@iki.fi From nobody Thu Mar 26 14:46: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 5A2AB1B2F8E for ; Thu, 26 Mar 2015 14:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_8q_Pt2d0NS for ; Thu, 26 Mar 2015 14:46:19 -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 4809D1B2F88 for ; Thu, 26 Mar 2015 14:46:19 -0700 (PDT) Received: by oicf142 with SMTP id f142so52056507oic.3 for ; Thu, 26 Mar 2015 14:46:18 -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=oa890gO0AlKB7AU9PQviQSONtE89OU47qCJ6gn8ALA8=; b=cZeCCv5RR/HY34SFMLUlhtiq4uZUUJW73sJ4onnHY2EZqu/UHS46KN3YMQIE7PxYBZ yG+JSquray3mNhD4yUSgkyaPeMdj7XBQO8VjDEIooBfywFZ6btGJYLkcwQXO48WjojV9 XISs5A/hTIEHSYK43yENN+5CgISGjpj9Rii1/HjBHNKDLuIks/Ukbf75uMk7TEMPrrOB D7fHxMa4wmNdu05228afqn1G2e6qcl/p64xLbFZgj4gE6A6JZVT0eo8LFGxeoP5tzfBL JHkp5JzqOTASqrsNfbqOrUl2b6LkkOpr5L4oGKJ+Owgvb5OImqDgABjLmaha9MYZTN46 ddlw== MIME-Version: 1.0 X-Received: by 10.60.134.237 with SMTP id pn13mr13977643oeb.59.1427406378849; Thu, 26 Mar 2015 14:46:18 -0700 (PDT) Sender: richmoore44@gmail.com Received: by 10.182.116.166 with HTTP; Thu, 26 Mar 2015 14:46:18 -0700 (PDT) In-Reply-To: <201503231615.26528.davemgarrett@gmail.com> References: <201503231615.26528.davemgarrett@gmail.com> Date: Thu, 26 Mar 2015 21:46:18 +0000 X-Google-Sender-Auth: sR5PDcJx198jR3z6XK9sXIKNYIY Message-ID: From: Richard Moore To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7b471e3a295eb5051237f241 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:46:23 -0000 --047d7b471e3a295eb5051237f241 Content-Type: text/plain; charset=ISO-8859-1 On 23 March 2015 at 20:15, Dave Garrett wrote: > Adding support for SHA-3 hashes seems like a good idea at this point. > Since SHA-3 hasn't yet been released this isn't currently possible. Rich. --047d7b471e3a295eb5051237f241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 23 March 2015 at 20:15, Dave Garrett <davemgarrett@gmail.com= > wrote:
Adding support fo= r SHA-3 hashes seems like a good idea at this point.

Since SHA-3 hasn't y= et been released this isn't currently possible.

Rich.


--047d7b471e3a295eb5051237f241-- From nobody Thu Mar 26 14:51: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 C3F0E1B2EFB for ; Thu, 26 Mar 2015 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcYNNXffHf5y for ; Thu, 26 Mar 2015 14:51:45 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.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 2EB3C1A8A0B for ; Thu, 26 Mar 2015 14:51:45 -0700 (PDT) Received: by wgs2 with SMTP id 2so79687734wgs.1 for ; Thu, 26 Mar 2015 14:51: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:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=bBFJ7NApNTvKMchTgTGMmE5AUX9oHJrM1qSssWto/OQ=; b=ePTht4nUm5gTnKcxyWnA0UMPDjaogme3pKG27t72kcD31B874uskOev9G6aDfnqWFV uYP7rOKAwf5jVKZnoGgRpwSABOXGkDKmhF719COXJOPeBBvJPoWWEqUZuEGSubdpx6h1 Ev+RkKk7wg2I+zk0bJ/EqCxirJ+u7VmQDO2NtKCe4Af/402EN7vrsIpU0WBeulmwQWHB mLVAa+rnEygbRBnFL8jJCLJDK4T2tE7eS9EN8M91xGz2k+JQRaHQZpLjvmeWBaiFNSkS 7pLYke8jeGH4QhIhjW1B+gFeWWuxvsMctaZrd0ENun8sRk1mDHFKFol7Ouj7FaEz8Yd0 kywA== X-Gm-Message-State: ALoCoQlDpZ+OfcfutxVE4AgEyVimcrqbc9JGR/AkOaiDT4ezGjITZBZzR9uQOC6CUc0tk/Lgy7Py X-Received: by 10.194.85.233 with SMTP id k9mr31037558wjz.31.1427406703841; Thu, 26 Mar 2015 14:51:43 -0700 (PDT) Received: from [10.0.0.112] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id fo9sm675322wib.16.2015.03.26.14.51.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 14:51:42 -0700 (PDT) Message-ID: <55147F6A.4000103@azet.org> Date: Thu, 26 Mar 2015 22:51:38 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: TLS Mailing List X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF13C0F8976644EDFB30E4FFC" Archived-At: Subject: [TLS] comment on draft-ietf-tls-pwd-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:51:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF13C0F8976644EDFB30E4FFC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Sorry for being terse: I'm wondering why the Document still supports AES-CBC. Is compatibility down to TLS 1.0 or 1.1 desired? If not; Why not reduce the number of (vulnerable) ciphersuites by removing AES-CBC? Thanks, Aaron --------------enigF13C0F8976644EDFB30E4FFC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFH9rAAoJEOTbZJL9ubXVld8P/1xGXHQByPQB8Iba8wrK7Ac4 gh3JWJQHYCvvNmNfdbXSKVEFiYOTv3TRMSkfAMO8HqRnrzaWgulXKY+jA4kmi8+3 /inMGEZrEM9NdmbmKSeLFFQ/YD7IozX0GKEtexWpfcIYCcqO+gkk/C97Q36qPvWb o3GllVkc3DyrL8p+FUMKaggSEGQtAXnLSu1s45PED8wO64nBX0MCRh3NtF9ow0rK BW6CTZoh/32MG4uw7DJY4gotdepmKVBiK57GlaZu1Fu7XVknexF9q69C56qrvBXr Q0hFjrbt0xLKxdAfy+aP7j3EQl9KImJxCJcnQohYLvKTXlV1XNrZ3qSJ/Tktxzp6 FwXTCprJIRafAr4t0RwahQk9snuPFlKk0VNSuxNEbhf2eCyhO3sbilyo/s4US3Bz GwZKpgzQm/jElX3D1+GVPu5A2W3pX+CwxZo2Go6RKULgEVqQMCUpQFmd92aGKsxd PDGWJBqkiBixXdYdb1PydlW4MLVtyMB35LF6Mqg1b0BKTFrxwYS1q42LNxO3Jiac NsZxfyiIA4xJdu5x8/mOBxFMU9kSY2B8JSPCleMuF2ziObe6CaaA/DubHDnCHapd lL52Uvh4XU3IPPnwAWFVllwQv5pcrC9MRkdTzBikj2Tsy1vhN+X8HRAx2S2DdOob FIggaq9R5NOE3ACvkvTu =YYOb -----END PGP SIGNATURE----- --------------enigF13C0F8976644EDFB30E4FFC-- From nobody Thu Mar 26 18:58: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 900721A899C for ; Thu, 26 Mar 2015 18:58: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 douH3kmb3XPD for ; Thu, 26 Mar 2015 18:58:16 -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 995DD1A8993 for ; Thu, 26 Mar 2015 18:58:16 -0700 (PDT) Received: by igcau2 with SMTP id au2so8685136igc.0 for ; Thu, 26 Mar 2015 18:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=1IYjzsFfDkpqnttK1TqzbwDcyG9C0+ClH9XOBe7zTk0=; b=ISbPgE72rMdhT8LYLv8q7l+0S2R66AShLTWUNpTNC7uMS0oIxVO5cINWVnxji3Y1Mp ngwe8wKCc1I+EX4WU6LjkZRpJl1GK/YpBUX+mNrVVN29c0E8loQF9rGL95lpgBTWorMj iS9AULtSOGR/HSuRs4kt+OONCtnK37apfVpCFRjB2WYozSXtGcg7e0fqBRLX8YTVJCjc C7uL5B8istuo8NVR4ARnjujHZ/0rh1AL7Fa4G2gGKgS/b+/10+bw73Nq1vCvRP4Fx8h/ apas/2EN3CkHr81Q37ZUVdJub42getnlK2we+Kgm83b4VdnZy8e6SLGo1s885kEZi1Cd 13ow== MIME-Version: 1.0 X-Received: by 10.107.29.21 with SMTP id d21mr25955908iod.11.1427421495976; Thu, 26 Mar 2015 18:58:15 -0700 (PDT) Received: by 10.36.123.11 with HTTP; Thu, 26 Mar 2015 18:58:15 -0700 (PDT) Date: Thu, 26 Mar 2015 18:58:15 -0700 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Cipher suite values for ChaCha20/Poly1305? 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: Fri, 27 Mar 2015 01:58:18 -0000 http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml does not list cipher suite values for ChaCha20 and Poly1305. I hope the page is outdated and missing updates. Do we have cipher suite values for ChaCha20/Poly1305? If not, when can we expect them? Related: if not, does anyone know why it is taking so long? (I don't want to appear cynical, but I find it hard to believe it takes months and years to agree on an unsigned short value(s)). From nobody Thu Mar 26 20:04: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 E30EF1A90BA for ; Thu, 26 Mar 2015 20:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBppw-JZMAKj for ; Thu, 26 Mar 2015 20:04:16 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.59.2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8F91A90DD for ; Thu, 26 Mar 2015 20:04:10 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 36BEBBA7B8B9B; Thu, 26 Mar 2015 22:04:10 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 256DCBA7B8B10 for ; Thu, 26 Mar 2015 22:04:10 -0500 (CDT) Received: from [173.200.48.34] (port=60744 helo=[10.111.111.125]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YbKZ7-0001q6-BV; Thu, 26 Mar 2015 22:04:09 -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: Thu, 26 Mar 2015 22:04:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> References: To: noloader@gmail.com 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: 173.200.48.34 X-Exim-ID: 1YbKZ7-0001q6-BV X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.111.111.125]) [173.200.48.34]:60744 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values for ChaCha20/Poly1305? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 03:04:18 -0000 We=92re going to be doing a WG call for adoption shortly. spt On Mar 26, 2015, at 20:58, Jeffrey Walton wrote: > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml > does not list cipher suite values for ChaCha20 and Poly1305. I hope > the page is outdated and missing updates. >=20 > Do we have cipher suite values for ChaCha20/Poly1305? If not, when can > we expect them? >=20 > Related: if not, does anyone know why it is taking so long? (I don't > want to appear cynical, but I find it hard to believe it takes months > and years to agree on an unsigned short value(s)). >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 27 03:43: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 ED9EA1ACD4C for ; Fri, 27 Mar 2015 03:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL_7cU6teKu5 for ; Fri, 27 Mar 2015 03:43:17 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE9B1ACD4B for ; Fri, 27 Mar 2015 03:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1427452996; x=1458988996; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RwL+pwqnVnVi2DBaUwCCwYuuJQ2bivaLrOdasuSXmyM=; b=cIZYz/4WXeB/CCyfY8igIp4Pd0a2L7HnIfhUCrDfZcpqWMvvPUwSNn/n 3R4Gn2HTCpjT24yIQGG+ZVyuyxsDbJYs/7PoI4EI02AybT8AHsiYctfKF Wb1FVXLa5X0BRDzU77VwEeJ8anaCEnWicWx7sMnOEvKy9kKQ/Rh6xVpth 4=; X-IronPort-AV: E=Sophos;i="5.11,478,1422874800"; d="scan'208";a="317282318" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Mar 2015 23:43:15 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.82]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Fri, 27 Mar 2015 23:43:15 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] comment on draft-ietf-tls-pwd-06 Thread-Index: AdBoetQXaZIQwLXAQom728tSNILZPQ== Date: Fri, 27 Mar 2015 10:43:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFC29C6@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] comment on draft-ietf-tls-pwd-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 10:43:18 -0000 Aaron Zauner writes:=0A= =0A= >Sorry for being terse: I'm wondering why the Document still supports AES-= =0A= >CBC. Is compatibility down to TLS 1.0 or 1.1 desired? If not; Why not =0A= >reduce the number of (vulnerable) ciphersuites by removing AES-CBC?=0A= =0A= Given that AES-CBC with EtM is a lot less vulnerable to problems than AES-G= CM=0A= (and arguably even without EtM it's a lot less brittle than GCM is), why wo= uld=0A= you remove it? It's a much more robust mode than GCM.=0A= =0A= Peter.= From nobody Fri Mar 27 05:51: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 116451ACDA8 for ; Fri, 27 Mar 2015 05:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elPqBOU5peQ9 for ; Fri, 27 Mar 2015 05:51:38 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 9FD331ACDB9 for ; Fri, 27 Mar 2015 05:51:37 -0700 (PDT) Received: by obbld8 with SMTP id ld8so18172541obb.3 for ; Fri, 27 Mar 2015 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nSEmOlD7rabWDM3ApkYXKncBYGXwW3YZ4/OkT0i6J60=; b=L5HhxnK48eXqL+dn2IVyvfGsPJ1B6i61Cf/l/8Bt/vBr0CycpF05xPKOE7/pZ89zPH auWCKl+q3q7VfmfodT+DaIFS8jY6g5lAO6eZaEYdOAhKBfMzSKfkryClsdvr5037p6qf unqZt0ot0zMOLx4BP4vo5NtMgklkmadhskfB4j3kAsXN6/11c2ySvyIT1CmlvzDoCaY/ ZU67ugOPsENqvOQJx4fhpHPw0bsmilgq85Z8TAgJ6o3VV5mzOAnVjDNFMonS0PaZeuHg xFXjm0dXWrh2L9zsXsxQdFL8GDvn37W5BUkp6Ghgbtc65CBv1VQdDQ8jAjgh/Qgs2pGc n+eg== X-Received: by 10.182.230.132 with SMTP id sy4mr16260007obc.29.1427460697156; Fri, 27 Mar 2015 05:51:37 -0700 (PDT) Received: from [10.111.111.12] ([173.200.48.34]) by mx.google.com with ESMTPSA id jg4sm969040obb.15.2015.03.27.05.51.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 05:51:35 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> Date: Fri, 27 Mar 2015 07:51:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> References: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cipher suite values for ChaCha20/Poly1305? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 12:51:40 -0000 And if/when the WG adopts, we might want to ask for early assignment of = code points. Yoav > On Mar 26, 2015, at 10:04 PM, Sean Turner wrote: >=20 > We=92re going to be doing a WG call for adoption shortly. >=20 > spt >=20 > On Mar 26, 2015, at 20:58, Jeffrey Walton wrote: >=20 >> http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml >> does not list cipher suite values for ChaCha20 and Poly1305. I hope >> the page is outdated and missing updates. >>=20 >> Do we have cipher suite values for ChaCha20/Poly1305? If not, when = can >> we expect them? >>=20 >> Related: if not, does anyone know why it is taking so long? (I don't >> want to appear cynical, but I find it hard to believe it takes months >> and years to agree on an unsigned short value(s)). >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 27 06:49: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 A401B1ACE33 for ; Fri, 27 Mar 2015 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwtLCNOiRzxE for ; Fri, 27 Mar 2015 06:49:47 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010: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 F2A421ACDDB for ; Fri, 27 Mar 2015 06:49:46 -0700 (PDT) Received: by lboc7 with SMTP id c7so7108430lbo.1 for ; Fri, 27 Mar 2015 06:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3lg/Ecuiy8dvhEZhroKdfiSd2rlxCZjckzyMQMYhOts=; b=Z+HJTD94qVOg6wbUKU+Me/pPq/9BD9sAbLEphCSaFw6VgAKuI0rttmTXkU69++S5mN 3AfpEt7/R0NEp4fdCJcJk1/ccqlZ0UfdZbByhaQhVrvAaOpZxjgi+KHWoG2QbV2Kpioi roQDmIE06R6ehS9Y4UV17ussH9eg4dLlzT15UrKmqycQWgIq/Aloi7qxiV+whemO2Hg2 Mmlx+zPS0W5rwXVLlrn2RZZzzHlH0sVsM8BLQxqqZl+lbsnl1kn8EorXR5JRsgDiSxHG lSdJV6Xy+zzIVFwyE0uMQ5667LQlr8wvikUuGlI1GiuFvRh/rGYuIVjKMTr/oDq5O2kZ jYOA== MIME-Version: 1.0 X-Received: by 10.112.17.8 with SMTP id k8mr17888034lbd.26.1427464185561; Fri, 27 Mar 2015 06:49:45 -0700 (PDT) Received: by 10.112.204.5 with HTTP; Fri, 27 Mar 2015 06:49:45 -0700 (PDT) In-Reply-To: <201503260330.43588.davemgarrett@gmail.com> References: <201503260330.43588.davemgarrett@gmail.com> Date: Fri, 27 Mar 2015 14:49:45 +0100 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New TLS version negotiation mechanism, take 2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 13:49:48 -0000 On Thu, Mar 26, 2015 at 8:30 AM, Dave Garrett wrot= e: > Based on feedback in the previous discussion, I think I've cobbled togeth= er a > framework that might be good to use. Please state the problem that you attempt to fix. > * A new extension that contains a single ProtocolVersion, with its value = named max_version > * Rename ClientHello.client_version to min_version > * Rename ServerHello.server_version to negotiated_version > * Convert ProtocolVersion to a 16-bit enum, with equivalent values to exi= sting struct format > * The values are as follows: > > 1) record layer version frozen to TLS_version_1_0(0x0301) (PR #107) > 2) ClientHello.min_version set to TLS_version_1_2(0x0303) > (for clients supporting TLS 1.2, this is a constant; > clients not supporting TLS 1.x set this to their higher min version) > 3) Both endpoints set their max_version (in ext) to their max supported v= ersion > (all clients send; all servers reply if clients send; these values ar= e constant based on config) > 4) ServerHello.negotiated_version is picked in a manner similar to now, b= ut from the endpoints' > max_version fields. If the new extension is not supported, it transpa= rently falls back to > TLS 1.2, and old servers will fall back to TLS 1.0/1.1 if needed. > > Servers now have a min_version from client to not offer to fall back too = far at all. ... And prior TLS servers will still fall back further... I don't see any benefit at all with this scheme. 1) Any server that implements it will by definition support TLS 1.3 or la= ter, and will with the current version negotiation scheme presumably select min(ClientHello.version, max_supported_version) as protocol version an= yway, so what's the point with min_version? 2) In case the server selects a version that the client doesn't like, thi= s will be noticed by the client in the first packet that it receives, at which point it can terminate the connection, but the same is true for your scheme, as the server is free to select TLS 1.2 (or any earlier, as it may pretend not to understand your extension). > Version IDs 0x0304 through 0x03FF can be assigned as IDs for upcoming dra= ft > versions. The final version will be assigned 0x0400. As there's no longer= an attempt > to do something vaguely akin to major.minor, the values are arbitrary and= can be > assigned for draft/experimental versions as needed. Negotiation logic spe= cifies that > servers picking a lower version must pick a stable version if the client = did not > explicitly offer a supported experimental version. Might the above be the problem you want to fix? Ie you want to support negotiation of (incompatible) draft versions of TLS 1.3? > This seems to get pretty much what we want here: > + TLS 1.3+ version intolerance is not an issue, unless the client refuses= to negotiate > TLS 1.x, in which case it doesn't matter. (it won't work regardless of = the server > responding ideally or not) Please remind me, but wasn't the observed TLS 1.3 version intolerance mostl= y limited to the version in the packet layer? I also expect such intolerances to quickly disappear as soon as TLS 1.3 clients become available. > + Only one extension with one fixed length value But here you lose the benefit, as the client can't inform the server that it supports multiple TLS 1.3 drafts if the field is of fixed length. > + Both stable and draft/experimental versions can use the same negotiatio= n > mechanism (and get tested) > + It's more or less as simple as can be, given that we're hacking in a ne= w > mechanism on top of the old. Yeah, lots of version fields, but almost a= ll are > constants. As the current version negotiation scheme is quite simple, and people still get it wrong, I expect your scheme to be handled even worse. I do see a potential need for an extension for informing about which draft version(s) that the client (and server) support. > + All the various version fields are now named so as to indicate what the= y're actually for Except for when they aren't. Eg ClientHello.min_version will be handled as if it were ClientHello.max_version by TLS 1.2 and earlier servers. > Ditching the version field from the encrypted records is a very good idea= to go > along with this, as it's useless and yet another version field to confuse= things. This I can agree with. /grubba --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Fri Mar 27 07:13: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 B1C181A897E for ; Fri, 27 Mar 2015 07:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arssaTtITG5g for ; Fri, 27 Mar 2015 07:13:14 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.21.16]) (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 850DA1A1A0B for ; Fri, 27 Mar 2015 07:13:14 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id DB2F0B59C8DA6; Fri, 27 Mar 2015 08:13:13 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id C844DB59C8D2B for ; Fri, 27 Mar 2015 08:13:13 -0600 (CST) Received: from [31.133.182.133] (port=60867 helo=dhcp-b685.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YbV0b-0005DI-A0 for tls@ietf.org; Fri, 27 Mar 2015 09:13:13 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFC29C6@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 27 Mar 2015 09:13:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73AAFC29C6@uxcn10-5.UoA.auckland.ac.nz> 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: 31.133.182.133 X-Exim-ID: 1YbV0b-0005DI-A0 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-b685.meeting.ietf.org) [31.133.182.133]:60867 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] comment on draft-ietf-tls-pwd-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 14:13:15 -0000 We should keep in mind that this document is parked (i.e., it lack = consensus to move forward). spt= From nobody Fri Mar 27 08:00:43 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 DCECC1ACE8A for ; Fri, 27 Mar 2015 08:00:41 -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 XejrasTIBEUU for ; Fri, 27 Mar 2015 08:00:38 -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 4B5971ACEE0 for ; Fri, 27 Mar 2015 08:00:36 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 226346996F; Fri, 27 Mar 2015 17:00:33 +0200 (EET) Date: Fri, 27 Mar 2015 17:00:32 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20150327150032.GA27825@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] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 15:00:42 -0000 Sorry, this is quite long. Some background: Be very vary about "security proofs". The scope of how TLS is used is very broad. There have been numerious papers about "TLS proven secure" or "part X of TLS proven secure", that have later turned out to be irrelevant in practice due to insufficient scope (then there are ocassional security proofs that are just plain wrong). E.g. number of papers that overlooked that TLS MS is not CRK and the screwyness that this causes. E.g. breaking authentication. Or paper that proved that "BEAST" is impossible... Only to turn out that it had made an assumption that BEAST attack broke. This problem is compounded by the fact that TLS is often used in environments like WWW, where attackers have unusual powers to exploit weaknesses that normally are not exploitable. The consequence is that even if some "security proof" says that it is okay to simplify system in some way, that simplification might still introduce vulernabilities. E.g. Consider TLS 1.3 draft -03 (I picked this because it is the earliest version that I think is implementable at all). It is a bit simpler than -04, and I think that it in some scope can be proven "secure". But it also has a known security hole (fixed in -04). OTOH, security proofs that produce conterexamples to security are useful to look at. The counterexample may or may not be relevant (telling which is likely nontrivial). If it is relevant or might be relevant, fixing the problem is worth it. Symmetric crypto is very fast, so a bit of extra hashing, PRFing or somesuch is pretty much insignificant compared to asymmeric things like computing signatures, DHFs or DHKGs. Short summary: Security proofs are useful, but relying on them is a very bad idea. On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote: > Folks, > > As an outcome of the interim, I was asked to write up an initial draft > of what this would all look like and post it to the list. You can find > such a draft at: > > Git branch: > https://github.com/ekr/tls13-spec/tree/WIP_dh_based > > Text file: > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt > > HTML diff: > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.html > > > Please note that this is a very rough draft and no doubt contains > a number of major errors (and certainly has seen no security review). > Please point these out to me if you find them, especially if they > impede understanding. Assuming that people are happy with this > general direction, I will clean it up and turn it into a PR. Okay, let's analyze what goes wrong (and fix the thing so it is easy to analyze): - For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs, not two. 1) PSK input. 2) PFS diffie-hellman input 3) Static Diffie-Hellman input. -> 1 and 3 are not the same, even if they can't appear simultaneously! - For chaining keys from 0RTT (optional), you need _fourth_ input: 4) Static diffie-hellman from 0RTT. -> Only computable if server accepts 0RTT. -> Needed for gradual static-DH rollover. - The "handshake master secret" needs to be CR function of: 1) PFS diffie-hellman iput. 2) PSK input. 3) Static diffie-hellman from 0RTT (if exists) 4) Hash of *Hello and *KeyShare packets. -> The reason for last is to defend against class of attacks including Triple Handshake. - The "application master secret" needs to be CR function of: 1) handshake master secret. 2) Static Diffie-Hellman input. -> The hash is not needed here (but can be included). -> Can be different in both directions (which has some benefits, in this case, the hash should be included). - The "exporter master secret" needs to be CR function of: 1) hanshake master secret. 2) Static Diffie-Hellman input. 3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is carrying the server static DH key packets (more can be included for a good measure). -> The reason why EncryptedExtensions needs to be included is in case it contains some extensions affecting TLS-Extractor. The reason server static DH key is needed is again to guard against attacks like THS. - The "resume premaster secret" needs to be CR function of: 1) hanshake master secret. 2) Static Diffie-Hellman input. 3) Hash of entiere handshake. -> The reason why last needs needs to be entiere handshake is that otherwise session may be resumed in inocnsistent state. -> Also so that resumption doesn't destroy forward security. - Online signature (if present) TBS needs to include: 1) *Random 2) Purpose of signature (e.g. server PoP) 3) Ciphersuite # 4) Prf-hash of messages so far -> *Random is to support privsep. Which is extremely useful even with pure SW if you have MMU available (and most of the time you do). -> Ciphersuite # is to pin the prf-hash algorithm (I think that is just the simplest way). The "function of" listings above are what I consider the absolute minimum, that's the reason why "application master secret" hash input is not marked as needed. It can (and should) be included. Also, one should take care that none of the different secrets may end up being same (except by very bad luck). The only thing above -05 fails is "exporter master secret", which is the same as handshake master secret nor does it hash enough state. Also, other comments: - I consider HKDF-HMAC-SHA256 to be too weak. -> I think it needs at least HMAC-SHA384 (also would just give one prf-hash). -> SHA384 is FASTER than SHA256 on modern hardware (that's why SHA-512/256 exists). But SHA3-384 is slower than SHA3-256. - There is no need to intermingle static DH key with signature, even if statid DH key exists. -> Signatures work like in -05. -> Can completely eliminate signature if one has fixed-DH cert (DHF is WAY simpler than signature primitive). Also, will *server* 0RTT be supported, even with client authentication? It would set the following boundary conditions: - Server application keys can't include hashes of client certificate, as those need to be computable immediately on server finished. - The same for exporter master secret. The restrictions here are: - Replay protection is provoded. - There is no authentication (the server hasn't heard client's certificate, which keeps misuse potential way down). Usecases: - Protocol banners, feature negoitiation (ALPN doesn't scale!), etc... Also regarding splitting application keys to directional ones: - Allows JIT derivation, eliminating temporarily invalid keys. - Allows rekeying (since requirement is no dead time and arbitrarily delayed responses, as breaking this causes problems for all applications). -Ilari From nobody Fri Mar 27 08:30: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 E45311AD0C9 for ; Fri, 27 Mar 2015 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfXKr_j958BI for ; Fri, 27 Mar 2015 08:29:58 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 324CF1AD0C8 for ; Fri, 27 Mar 2015 08:29:58 -0700 (PDT) Received: by wibbg6 with SMTP id bg6so30919102wib.0 for ; Fri, 27 Mar 2015 08:29:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hmm/2PrjkI5NSnP6Ngu77PBXPiGfFNpRzNVWc+Yp7Aw=; b=aWJlm9OWrvZWTlWGWvOWHJ9xcCYgystMa9YrXZIZjJf3hrNlLgYMM/RYWz5EJRm1lO Nf6A1fsNM8UEKawiw175OmpaK6lxkHuG0CUvPS7RKgt0E3z57H4XG7D0HPPbkBe6FZGi OCdPn+KsGfIYQFRlO598bZ/iF8k++hKfFVVd6q+3INpQK0JLx/u/GuPcyCjDMwkdBt66 T9etc6STMR02Cvif5mlYPieA27v2UJE7UgH9ZBNHDlIFzR7l0Z0ABTRfCWhm3g1ePyIq I1GV73Vk20oM1/5Mh4/8wWk4CIa1QAtP2EFYCV/gKcNO235AJ4gdCSc/t29OfynE6qAo k7+A== X-Gm-Message-State: ALoCoQnaHpx0Y9rgeP6Sh7hfDGoYm11SUWa2Rdm8zZ3CMQZ+CXqPc7RdROwu1ueL1ZV+z+xmRb73 X-Received: by 10.180.106.68 with SMTP id gs4mr58181262wib.39.1427470196943; Fri, 27 Mar 2015 08:29:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Fri, 27 Mar 2015 08:29:16 -0700 (PDT) In-Reply-To: <20150327150032.GA27825@LK-Perkele-VII> References: <20150327150032.GA27825@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 27 Mar 2015 10:29:16 -0500 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d04451a11043fc4051246cefb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 15:30:00 -0000 --f46d04451a11043fc4051246cefb Content-Type: text/plain; charset=UTF-8 On Fri, Mar 27, 2015 at 10:00 AM, Ilari Liusvaara > > The only thing above -05 fails is "exporter master secret", which > is the same as handshake master secret nor does it hash enough state. > This was an editorial error in -04 but should be the final master secret in -05: https://github.com/tlswg/tls13-spec/commit/ee4a437d0824efaa7e0c952a4af960bdc304a2f3 -Ekr --f46d04451a11043fc4051246cefb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 27, 2015 at 10:00 AM, Ilari Liusvaara=C2=A0
The only thing above -05 fails is "exporter master secret", which=
is the same as handshake master secret nor does it hash enough state.

This was an editorial error in -04 but shoul= d be the final master secret
in -05:



= -Ekr
=C2=A0
--f46d04451a11043fc4051246cefb-- From nobody Fri Mar 27 08:31: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 709291ACE88 for ; Fri, 27 Mar 2015 08:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLwYIPltSeUO for ; Fri, 27 Mar 2015 08:31:39 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0699.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::699]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665011AD0D0 for ; Fri, 27 Mar 2015 08:31:21 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 27 Mar 2015 15:27:54 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 15:27:54 +0000 From: "Paterson, Kenny" To: Ilari Liusvaara , Eric Rescorla Thread-Topic: [TLS] Initial draft of DH-based key exchange Thread-Index: AQHQZW6JbdaeS/vEFE+Md9lDgM4HC50wcq0A//+zyYA= Date: Fri, 27 Mar 2015 15:27:54 +0000 Message-ID: References: <20150327150032.GA27825@LK-Perkele-VII> In-Reply-To: <20150327150032.GA27825@LK-Perkele-VII> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.136.113] authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(479174004)(51704005)(43544003)(24454002)(19580405001)(2900100001)(2950100001)(46102003)(122556002)(19580395003)(87936001)(92566002)(83506001)(2656002)(106116001)(36756003)(15975445007)(102836002)(86362001)(76176999)(50986999)(54356999)(62966003)(77156002)(66066001)(74482002)(77096005); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB381; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB381; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="us-ascii" Content-ID: <448581E96C0FD244A8A6F4B687BBF6DD@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 15:27:54.0797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 15:31:50 -0000 Hi Ilari, On 27/03/2015 10:00, "Ilari Liusvaara" wrote: >Sorry, this is quite long. > >Some background: > >Be very vary about "security proofs". The scope of how TLS is used is >very broad. There have been numerious papers about "TLS proven secure" >or "part X of TLS proven secure", that have later turned out to be >irrelevant in practice due to insufficient scope (then there are >ocassional security proofs that are just plain wrong). > >E.g. number of papers that overlooked that TLS MS is not CRK and >the screwyness that this causes. E.g. breaking authentication. No, the papers that I think you are referring to did not overlook that TLS MS is not CRK. The problem is that they did not include renegotiation and resumption in their scope, thereby not excluding the renegotiation attack and the subsequent triple Handshake attack. So, yes, it's a scoping issue. But no, it's not the thing you point to, it's that thing in combination with other things. Recent papers on this topic (one of which [0] I am a co-author on) are, I believe, quite clear about their limitations of scope (my own paper [0], for example, contains a whole section explaining what is not included in the model and why that matters). The limitation of scope does not mean the papers are useless. As you write above, one just needs to be wary of over-interpreting what they say. >Or >paper that proved that "BEAST" is impossible... Only to turn out >that it had made an assumption that BEAST attack broke. I'm pretty familiar with the TLS and the relevant symmetric crypto literature, but can't immediately identify your source here. If you can give an exact reference, then we can debate what it did and did not say, and thereby discuss the value of proofs and the limitations of models. However, one thing I can say immediately is that the symmetric crypto literature is pretty clear that IVs for CBC mode need to be random (see [1], from 1997), and exhibited on-paper distinguishing attacks when they are not (see Section 9 of [2], dating from 1995). TLS 1.0 used predictable IVs despite clear warnings from the crypto community. And predictable IVs enabled BEAST. Please don't shoot the messengers. > >This problem is compounded by the fact that TLS is often used in >environments like WWW, where attackers have unusual powers to >exploit weaknesses that normally are not exploitable. > >The consequence is that even if some "security proof" says that >it is okay to simplify system in some way, that simplification >might still introduce vulernabilities. > >E.g. Consider TLS 1.3 draft -03 (I picked this because it is the >earliest version that I think is implementable at all). It is a >bit simpler than -04, and I think that it in some scope can be >proven "secure". But it also has a known security hole (fixed in >-04). > >OTOH, security proofs that produce conterexamples to security >are useful to look at. The counterexample may or may not be >relevant (telling which is likely nontrivial). If it is relevant >or might be relevant, fixing the problem is worth it. > > >Symmetric crypto is very fast, so a bit of extra hashing, PRFing >or somesuch is pretty much insignificant compared to asymmeric >things like computing signatures, DHFs or DHKGs. > > >Short summary: Security proofs are useful, but relying on them >is a very bad idea. This I can almost agree with. I would put it this way: they provide a form of assurance, but they should not be the only thing we rely on for assurance. Cheers Kenny [0] H. Krawczyk, K.G. Paterson and H. Wee. On the Security of the TLS Protocol: A Systematic Analysis. In R. Canetti, J.A. Garay (eds.), CRYPTO 2013 (1), Lecture Notes in Computer Science Vol. 8042, pp. 429-448, Springer, 2013 [1] M. Bellare, A. Desai, E. Jokipii, P. Rogaway. A Concrete Security Treatment of Symmetric Encryption. FOCS 1997: 394-403 [2] P. Rogaway. Problems with proposed IP cryptography. Unpublished manuscript, 1995.=20 http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.t xt > > >On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote: >> Folks, >>=20 >> As an outcome of the interim, I was asked to write up an initial draft >> of what this would all look like and post it to the list. You can find >> such a draft at: >>=20 >> Git branch: >> https://github.com/ekr/tls13-spec/tree/WIP_dh_based >>=20 >> Text file: >>=20 >>https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tl >>s13-dh-based.txt >>=20 >> HTML diff: >>=20 >>https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tl >>s13-dh-based-diff.html >>=20 >>=20 >> Please note that this is a very rough draft and no doubt contains >> a number of major errors (and certainly has seen no security review). >> Please point these out to me if you find them, especially if they >> impede understanding. Assuming that people are happy with this >> general direction, I will clean it up and turn it into a PR. > >Okay, let's analyze what goes wrong (and fix the thing so it is easy >to analyze): > >- For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs, not >two. > 1) PSK input. > 2) PFS diffie-hellman input > 3) Static Diffie-Hellman input. > -> 1 and 3 are not the same, even if they can't appear simultaneously! >- For chaining keys from 0RTT (optional), you need _fourth_ input: > 4) Static diffie-hellman from 0RTT. > -> Only computable if server accepts 0RTT. > -> Needed for gradual static-DH rollover. >- The "handshake master secret" needs to be CR function of: > 1) PFS diffie-hellman iput. > 2) PSK input. > 3) Static diffie-hellman from 0RTT (if exists) > 4) Hash of *Hello and *KeyShare packets. > -> The reason for last is to defend against class of attacks including > Triple Handshake. >- The "application master secret" needs to be CR function of: > 1) handshake master secret. > 2) Static Diffie-Hellman input. > -> The hash is not needed here (but can be included). > -> Can be different in both directions (which has some benefits, > in this case, the hash should be included). >- The "exporter master secret" needs to be CR function of: > 1) hanshake master secret. > 2) Static Diffie-Hellman input. > 3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is > carrying the server static DH key packets (more can be included > for a good measure). > -> The reason why EncryptedExtensions needs to be included is in case > it contains some extensions affecting TLS-Extractor. The reason > server static DH key is needed is again to guard against attacks > like THS. >- The "resume premaster secret" needs to be CR function of: > 1) hanshake master secret. > 2) Static Diffie-Hellman input. > 3) Hash of entiere handshake. > -> The reason why last needs needs to be entiere handshake is that > otherwise session may be resumed in inocnsistent state. > -> Also so that resumption doesn't destroy forward security. >- Online signature (if present) TBS needs to include: > 1) *Random > 2) Purpose of signature (e.g. server PoP) > 3) Ciphersuite # > 4) Prf-hash of messages so far > -> *Random is to support privsep. Which is extremely useful even with > pure SW if you have MMU available (and most of the time you do). > -> Ciphersuite # is to pin the prf-hash algorithm (I think that is > just the simplest way). > > >The "function of" listings above are what I consider the absolute >minimum, that's the reason why "application master secret" hash input >is not marked as needed. It can (and should) be included. > >Also, one should take care that none of the different secrets may >end up being same (except by very bad luck). > >The only thing above -05 fails is "exporter master secret", which >is the same as handshake master secret nor does it hash enough state. > > >Also, other comments: >- I consider HKDF-HMAC-SHA256 to be too weak. > -> I think it needs at least HMAC-SHA384 (also would just give one > prf-hash). > -> SHA384 is FASTER than SHA256 on modern hardware (that's why > SHA-512/256 exists). But SHA3-384 is slower than SHA3-256. >- There is no need to intermingle static DH key with signature, even if > statid DH key exists. > -> Signatures work like in -05. > -> Can completely eliminate signature if one has fixed-DH cert (DHF > is WAY simpler than signature primitive). > > >Also, will *server* 0RTT be supported, even with client authentication? >It would set the following boundary conditions: >- Server application keys can't include hashes of client certificate, > as those need to be computable immediately on server finished. >- The same for exporter master secret. > >The restrictions here are: >- Replay protection is provoded. >- There is no authentication (the server hasn't heard client's > certificate, which keeps misuse potential way down). > >Usecases: >- Protocol banners, feature negoitiation (ALPN doesn't scale!), > etc... > > >Also regarding splitting application keys to directional ones: >- Allows JIT derivation, eliminating temporarily invalid keys. >- Allows rekeying (since requirement is no dead time and arbitrarily > delayed responses, as breaking this causes problems for all > applications). > > > >-Ilari > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Fri Mar 27 08:53:43 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 01CBE1A0373 for ; Fri, 27 Mar 2015 08:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUpd2qzFyeoE for ; Fri, 27 Mar 2015 08:53:41 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d: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 C5C751A066B for ; Fri, 27 Mar 2015 08:53:36 -0700 (PDT) Received: by qgf60 with SMTP id 60so118971928qgf.3 for ; Fri, 27 Mar 2015 08:53:36 -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=izllTF/p7zy6/RJL51Yeq0m51rM3bNpw4l3gzdCDxVE=; b=HrEDzy7d8U8OWt2b6/yOTYMGOTxAV9oK0ZJkEHY3iVug3biWyCMaD4CErEFnK7SsuW uDox9zcAEGRE9Q9S499T9KyhOtz02IjjQKawqPi4upaSVButyKLzuy6rhjg0KXgop2cS 8+CW6xETbyFSOuC+R8ff7/6o9exR6IrHUrM86qJ2e80QIQk/XQ2csVHfNSEX3CkpZz1y FyhUUwxHRvZHNPomkEmOFZwI6fupa+xNMls7sWM6x8YHTJ21Y4OAk+oGuCLJNX5xhj8j 3nS2apO8fjXoF18T5vExm0CXy/pC6QYeQzFs5kt976p4z/mZd2/cAwf117ufsOkWkmEb obZQ== X-Received: by 10.55.23.84 with SMTP id i81mr40967688qkh.51.1427471616060; Fri, 27 Mar 2015 08:53:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id d49sm1708994qge.19.2015.03.27.08.53.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Mar 2015 08:53:35 -0700 (PDT) From: Dave Garrett To: Henrik =?utf-8?q?Grubbstr=C3=B6m?= Date: Fri, 27 Mar 2015 11:53:34 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503260330.43588.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201503271153.34569.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New TLS version negotiation mechanism, take 2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 15:53:43 -0000 On Friday, March 27, 2015 09:49:45 am Henrik Grubbstr=C3=B6m wrote: > On Thu, Mar 26, 2015 at 8:30 AM, Dave Garrett wr= ote: > > Based on feedback in the previous discussion, I think I've cobbled toge= ther a > > framework that might be good to use. >=20 > Please state the problem that you attempt to fix. Well, it's been discussed in the previous discussion. Brian's comments on f= irst proposal: https://www.ietf.org/mail-archive/web/tls/current/msg15470.html The problem is that 1.5% of the Internet is TLS 1.3 version intolerant, eve= n with a record layer fix. Attempting to adopt even a draft version of TLS = 1.3 would require insecure fallback, which we are very much trying to get r= id of. Releasing a new major version of TLS that cannot interop with 1.6% (= incl. 0.1% TLS 1.2 intolerant) of the Internet would seriously hamper adopt= ion, or more likely solidify insecure fallback. The second problem is that there is not currently a way to negotiate the us= age of any draft versions. Attempting to do so via a separate extension ris= ks using a scheme separate from the final version, meaning the actual negot= iation mechanism wouldn't properly get tested until release. > ... And prior TLS servers will still fall back further... Yes, that's the idea. For servers supporting then new method, the server is= capable of always picking a version within the range supported by the clie= nt. The range could be non-continuous, but my initial proposal to deal with= this more generically was considered to complex. Old servers will of cours= e fall back to the old mechanism, but they are at least guaranteed to fall = back rather than choke on a version number they can't properly handle. It s= houldn't be an issue, but it is. > Please remind me, but wasn't the observed TLS 1.3 version intolerance mos= tly > limited to the version in the packet layer? =46reezing the record layer version (PR #107) fixes about 5.3%. Freezing th= e ClientHello version fixes another 1.5%. https://www.ietf.org/mail-archive/web/tls/current/msg15486.html citing the survey from https://www.ietf.org/mail-archive/web/tls/current/msg15141.html > I also expect such intolerances to quickly disappear as soon as TLS > 1.3 clients become available. I do not. > > + Only one extension with one fixed length value >=20 > But here you lose the benefit, as the client can't inform the server > that it supports multiple TLS 1.3 drafts if the field is of fixed > length. Yes. If we'd like to go back to the list idea, I'm not wholly against it. In this mechanism, the client may support only one draft, but the server ma= y support multiple just fine. > As the current version negotiation scheme is quite simple, and people > still get it wrong, I expect your scheme to be handled even worse. TLS version intolerance mainly started because sloppy implementations did n= ot account for the fact that there would be multiple versions. There are mu= ltiple versions now. I expect the situation to be much better, and I intend= to put a few simple test parameters in an appendix to cover current and fu= ture cases. > I do see a potential need for an extension for informing about which > draft version(s) that the client (and server) support. >=20 > > + All the various version fields are now named so as to indicate what t= hey're actually for >=20 > Except for when they aren't. Eg ClientHello.min_version will be > handled as if it were ClientHello.max_version by TLS 1.2 and earlier > servers. Within the context of TLS 1.3+, all the various version fields are now for = what they're actually for. An old server will be able to parse it as TLS 1.= 2 compatible, and reply in a manner the client can reject if needed. (in th= e same way that an SSL3 server can still parse a TLS 1.2 hello and reply co= herently) There is no way to make every server know everything here. This s= cheme provides a hello that both old and new can fully understand and handl= e properly based on the version negotiation mechanisms they are capable of.= That's the goal here. > > Ditching the version field from the encrypted records is a very good id= ea to go > > along with this, as it's useless and yet another version field to confu= se things. >=20 > This I can agree with. From nobody Fri Mar 27 09:17: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 4E99D1A03B3 for ; Fri, 27 Mar 2015 09:17: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 EhanodGY--iR for ; Fri, 27 Mar 2015 09:17:48 -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 18CC71A00F1 for ; Fri, 27 Mar 2015 09:17:47 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 28D8C699E6; Fri, 27 Mar 2015 18:17:46 +0200 (EET) Date: Fri, 27 Mar 2015 18:17:46 +0200 From: Ilari Liusvaara To: "Paterson, Kenny" Message-ID: <20150327161746.GA28742@LK-Perkele-VII> References: <20150327150032.GA27825@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] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 16:17:50 -0000 On Fri, Mar 27, 2015 at 03:27:54PM +0000, Paterson, Kenny wrote: > > The limitation of scope does not mean the papers are useless. As you write > above, one just needs to be wary of over-interpreting what they say. Well, not useless, but... There are different kinds of problems arising for over-interpreting security proofs: Take some protocol X that is designed to use TLS feature Y for purpose Z (e.g. SPDY used TLS-Extractor for channel binding). This can be outright broken (like the example is in TLS 1.2 without extensions). This calls for documenting limiations of various TLS features. And preferably not provoding "attractive nuisances". But that doesn't mean the features provoded won't be used in strange ways. More nasty case is if there is a security proof that some strengthening A is unnecressary given assumptions B (which seems quite broadly applicable). Then TLS removes A as "unnecressary". Except that using Y for Z breaks B and relies on A, so now X is insecure. This is obviously highly attractive for crypto sabotage projects. E.g. suppose TLS had renego-fix-like fix for resumption. Now remove session-hash because it is unnecressary given proper certificate authentication. Except now TLS-Extractor for channel binding is broken. This calls for being conservative with strengthening. -Ilari From nobody Fri Mar 27 09:22: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 6FC511ACE89 for ; Fri, 27 Mar 2015 09:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-99kZ6d8J4v for ; Fri, 27 Mar 2015 09:22:44 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1946D1A2130 for ; Fri, 27 Mar 2015 09:22:44 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.1.125.19; Fri, 27 Mar 2015 16:10:44 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0118.022; Fri, 27 Mar 2015 16:10:44 +0000 From: "Paterson, Kenny" To: Ilari Liusvaara Thread-Topic: [TLS] Importance of ECDSA for TLS (was: PSS for TLS 1.3) Thread-Index: AQHQaKiUb7Jp+fMmD0GHobQoqWfyIA== Date: Fri, 27 Mar 2015 16:10:44 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.136.113] authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(51704005)(102836002)(36756003)(110136001)(86362001)(92566002)(2656002)(83506001)(106116001)(74482002)(77096005)(54356999)(50986999)(77156002)(66066001)(62966003)(2900100001)(46102003)(19580405001)(87936001)(122556002)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR03MB381; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB381; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="us-ascii" Content-ID: <07EA779809058F458DEECEEE826BE14C@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 16:10:44.4230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Importance of ECDSA for TLS (was: PSS for TLS 1.3) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:22:51 -0000 Dear Ilari, On 24/03/2015 12:11, "Ilari Liusvaara" wrote: >On Mon, Mar 23, 2015 at 07:42:26PM +0000, Paterson, Kenny wrote: >> >>=20 >> Just a quick heads-up with my CFRG hat on. We should soon be making a >> start over there on defining signature schemes for use with the curves >> that we have now selected; our DH deliberations are nearing completion. >>=20 >> One quick question for this group: how important is it to you to have >> ECDSA - or something very close to it (e.g. a derandomised version) - >>for >> TLS use, and how much appetite is there for adopting schemes that >>deviate >> more significantly from ECDSA (e.g. EdDSA)? > >My personal view (I have also looked at what this would take): >Not important, I would very much like a modern signature system (esp. >inversion-free[1]). Thanks for this feedback. This was also the view at the CFRG meeting this week in Dallas, but we will take it to the CFRG list for further discussion in the near future. >But I would want: >- Both curves usable in the same signature framework. >- Only use common hash function propeties for both curves[2], especially > for verification interop[3]. > > >Assignments required: >- TLS signaturealgorithm codepoint >- TLS namedcurve codepoints >- OIDs for the signature curves >- OIDs for PKIX (Signature,Hash) algorithm pair. > >All can be done with RFC & expert review. > > >[1] Inversions are not only highly annoying to implement safe way, >but are also pretty slow. > >[2] Good test: Does this work with standard-issue SHA-512? > >[3] This is for the case if anything happens to the primary algorithm. All noted. Best wishes, Kenny=20 > > >-Ilari From nobody Fri Mar 27 12:46: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 1ECF21A92B5 for ; Fri, 27 Mar 2015 12:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB7dXCJTRIP1 for ; Fri, 27 Mar 2015 12:46:07 -0700 (PDT) Received: from BAY004-OMC3S28.hotmail.com (bay004-omc3s28.hotmail.com [65.54.190.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007231AD190 for ; Fri, 27 Mar 2015 12:46:05 -0700 (PDT) Received: from BAY180-W16 ([65.54.190.187]) by BAY004-OMC3S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 27 Mar 2015 12:46:05 -0700 X-TMN: [URYpZIHXH2kwTneXiCFA1+rT0bx/OHOS] X-Originating-Email: [xiaoyin.l@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_91d5d13e-f1b7-46a7-a71f-65dcc0fa1640_" From: Xiaoyin Liu To: Dave Garrett , "tls@ietf.org" Date: Fri, 27 Mar 2015 15:46:05 -0400 Importance: Normal In-Reply-To: <201503271153.34569.davemgarrett@gmail.com> References: <201503260330.43588.davemgarrett@gmail.com>, , <201503271153.34569.davemgarrett@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2015 19:46:05.0792 (UTC) FILETIME=[A9F45600:01D068C6] Archived-At: Subject: Re: [TLS] New TLS version negotiation mechanism, take 2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 19:46:10 -0000 --_91d5d13e-f1b7-46a7-a71f-65dcc0fa1640_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support this version negotiation proposal=2C but I prefer the old one=2C = i.e. listing all supported TLS versions. See some inline comments: =20 > From: davemgarrett@gmail.com > To: grubba@gmail.com > Date: Fri=2C 27 Mar 2015 11:53:34 -0400 > CC: tls@ietf.org > Subject: Re: [TLS] New TLS version negotiation mechanism=2C take 2 >=20 > Well=2C it's been discussed in the previous discussion. Brian's comments = on first proposal: > https://www.ietf.org/mail-archive/web/tls/current/msg15470.html >=20 > The problem is that 1.5% of the Internet is TLS 1.3 version intolerant=2C= even with a record layer fix. Attempting to adopt even a draft version of = TLS 1.3 would require insecure fallback=2C which we are very much trying to= get rid of. Releasing a new major version of TLS that cannot interop with = 1.6% (incl. 0.1% TLS 1.2 intolerant) of the Internet would seriously hamper= adoption=2C or more likely solidify insecure fallback. >=20 > The second problem is that there is not currently a way to negotiate the = usage of any draft versions. Attempting to do so via a separate extension r= isks using a scheme separate from the final version=2C meaning the actual n= egotiation mechanism wouldn't properly get tested until release. I agree. > Freezing the record layer version (PR #107) fixes about 5.3%. Freezing th= e ClientHello version fixes another 1.5%. >=20 > https://www.ietf.org/mail-archive/web/tls/current/msg15486.html > citing the survey from > https://www.ietf.org/mail-archive/web/tls/current/msg15141.html >=20 > > I also expect such intolerances to quickly disappear as soon as TLS > > 1.3 clients become available. >=20 > I do not. I do not either. Even TLS 1.2 intolerant servers haven't disapp= eared yet. > > > + Only one extension with one fixed length value > >=20 > > But here you lose the benefit=2C as the client can't inform the server > > that it supports multiple TLS 1.3 drafts if the field is of fixed > > length. >=20 > Yes. If we'd like to go back to the list idea=2C I'm not wholly against i= t. >=20 > In this mechanism=2C the client may support only one draft=2C but the ser= ver may support multiple just fine. I support the list idea. Besides being = able to support draft versions=2C there is another benefit. If=2C for insta= nce=2C after TLS 1.5 is released=2C someone finds a weakness that only exis= ts in TLS 1.4=2C which makes TLS 1.4 insecure. But TLS 1.3 and TLS 1.5 are = still secure to use=2C and TLS 1.5 is better than TLS 1.3. Then with this v= ersion negotiation mechanism=2C clients can very easily mitigate the TLS 1.= 4 vulnerability by removing TLS 1.4 from the supported version list. But wi= th the current version negotiation=2C clients would have to either set high= est client version to TLS 1.3 or set to TLS 1.5 but fallback to TLS 1.3 if = servers try to negotiate TLS 1.4. I know this is quite unlikely to happen= =2C but I don't think we can safely assume this will never happen. Also thi= s mechanism enables implementations to skip versions for whatever reasons= =2C such as that some versions are not widely negotiated=2C like TLS 1.1 to= day. > > As the current version negotiation scheme is quite simple=2C and people > > still get it wrong=2C I expect your scheme to be handled even worse. I don't think this negotiation mechanism adds too much complexity. This mec= hanism is similar to listing supported cipher suites=2C elliptic curves=2C = signature algorithms=2C etc. If implementations can handle those extensions= right=2C I don't worry they will handle this version negotiation wrong. Best=2CXiaoyin = --_91d5d13e-f1b7-46a7-a71f-65dcc0fa1640_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I support this version negotiati= on proposal=2C but I prefer the =3Bold one=2C i.e. listing all supporte= d =3BTLS versions. =3BSee some inline comments:
 =3B
>=3B From: davemgarrett@gmail.com
>=3B To: grubba@gmail.com
>= =3B Date: Fri=2C 27 Mar 2015 11:53:34 -0400
>=3B CC: tls@ietf.org
&= gt=3B Subject: Re: [TLS] New TLS version negotiation mechanism=2C take 2>=3B
>=3B Well=2C it's been discussed in the previous discussion. = Brian's comments on first proposal:
>=3B https://www.ietf.org/mail-arc= hive/web/tls/current/msg15470.html
>=3B
>=3B The problem is that= 1.5% of the Internet is TLS 1.3 version intolerant=2C even with a record l= ayer fix. Attempting to adopt even a draft version of TLS 1.3 would require= insecure fallback=2C which we are very much trying to get rid of. Releasin= g a new major version of TLS that cannot interop with 1.6% (incl. 0.1% TLS = 1.2 intolerant) of the Internet would seriously hamper adoption=2C or more = likely solidify insecure fallback.
>=3B
>=3B The second problem = is that there is not currently a way to negotiate the usage of any draft ve= rsions. Attempting to do so via a separate extension risks using a scheme s= eparate from the final version=2C meaning the actual negotiation mechanism = wouldn't properly get tested until release.
 =3B
I = agree.

>=3B Freezing the record layer version (PR #107) fix= es about 5.3%. Freezing the ClientHello version fixes another 1.5%.
>= =3B
>=3B https://www.ietf.org/mail-archive/web/tls/current/msg15486.h= tml
>=3B citing the survey from
>=3B https://www.ietf.org/mail-ar= chive/web/tls/current/msg15141.html
>=3B
>=3B >=3B I also expe= ct such intolerances to quickly disappear as soon as TLS
>=3B >=3B 1= .3 clients become available.
>=3B
>=3B I do not.
 = =3B
I do not either. Even TLS 1.2 intolerant servers haven't disa= ppeared yet.

>=3B >=3B >=3B + Only one extension with one fixe= d length value
>=3B >=3B
>=3B >=3B But here you lose the ben= efit=2C as the client can't inform the server
>=3B >=3B that it supp= orts multiple TLS 1.3 drafts if the field is of fixed
>=3B >=3B leng= th.
>=3B
>=3B Yes. If we'd like to go back to the list idea=2C I= 'm not wholly against it.
>=3B
>=3B In this mechanism=2C the cli= ent may support only one draft=2C but the server may support multiple just = fine.
 =3B
I support the list idea. Besides being a= ble to support draft versions=2C there is another benefit. If=2C for instan= ce=2C after TLS 1.5 is released=2C someone finds a weakness that only exist= s in TLS 1.4=2C which makes TLS 1.4 insecure. =3BBut TLS 1.3 and TLS 1.= 5 are still =3Bsecure to use=2C and TLS 1.5 is better than TLS 1.3. The= n with this version negotiation mechanism=2C clients can very =3Beasily= mitigate the TLS 1.4 vulnerability by removing TLS 1.4 from the supported = version list. But with the current version negotiation=2C clients would hav= e to either set highest client version to TLS 1.3 or set to TLS 1.5 but fal= lback to TLS 1.3 if servers try to negotiate TLS 1.4.
 =3B
I know this is quite unlikely to happen=2C but =3BI don't think= we can =3Bsafely assume =3Bthis will never happen.
 = =3B
Also this mechanism enables =3Bimplementations to skip ve= rsions for whatever reasons=2C =3Bsuch as that =3Bsome versions are= not widely negotiated=2C like TLS 1.1 today.

>=3B >=3B A= s the current version negotiation scheme is quite simple=2C and people
&= gt=3B >=3B still get it wrong=2C I expect your scheme to be handled even = worse.
I don't think this negotiation mechanism adds too much= complexity. This mechanism is similar to listing supported cipher suites= =2C elliptic curves=2C signature algorithms=2C etc. If implementations can = handle those extensions right=2C I don't worry they will handle =3Bthis= version negotiation =3Bwrong.
Best=2C
Xiaoyin<= /div>
= --_91d5d13e-f1b7-46a7-a71f-65dcc0fa1640_-- From nobody Fri Mar 27 14:45: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 A908E1B2B16 for ; Fri, 27 Mar 2015 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzV96EB3Bsgk for ; Fri, 27 Mar 2015 14:45:09 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1B97E1B2B14 for ; Fri, 27 Mar 2015 14:45:09 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7A7429A401A; Fri, 27 Mar 2015 17:44:58 -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 A6QuGqZSBoFu; Fri, 27 Mar 2015 17:44:37 -0400 (EDT) Received: from [172.16.34.135] (unknown [199.227.111.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 585B39A4014; Fri, 27 Mar 2015 17:44:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-51-361388687 From: Russ Housley In-Reply-To: Date: Fri, 27 Mar 2015 17:44:30 -0400 Message-Id: <27B74C98-C6B2-4AD0-A90A-4528DB50B904@vigilsec.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 21:45:10 -0000 --Apple-Mail-51-361388687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eric: > At the interim discussed transitioning to a DH-based handshake (rather > than a signature-based one) like that proposed by Hugo Krawczyk and > Hoeteck Wee. The major rationale for this change is that any 0-RTT > mode is inherently DH-based and so if we make that our basic mode, > then we can simplify the protocol logic and key derivation model. This > model also allows us to pull in PSK modes under the same basic > structure. I was not at the interim, but I was at the TLS session at IETF 92 in = Dallas. I was watching your presentation pretty carefully, and I do not recall a = slide on support for PSK. Can you point me to a description of "PSK = modes under the same basic structure"? Russ --Apple-Mail-51-361388687 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
At the = interim discussed transitioning to a DH-based handshake = (rather
than a signature-based one) like that proposed by Hugo = Krawczyk and
Hoeteck Wee. The major rationale for this change = is that any 0-RTT
mode is inherently DH-based and so if we = make that our basic mode,
then we can simplify the protocol = logic and key derivation model. This
model also allows us to = pull in PSK modes under the same = basic
structure.

I was = not at the interim, but I was at the TLS session at IETF 92 in = Dallas.

I was watching your presentation pretty = carefully, and I do not recall a slide on support for PSK.  Can you = point me to a description of "PSK modes under the same basic = structure"?

Russ

= --Apple-Mail-51-361388687-- From nobody Fri Mar 27 14:53: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 4E30A1B2B1D for ; Fri, 27 Mar 2015 14:53: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 UK4jSU16P4dd for ; Fri, 27 Mar 2015 14:53:20 -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 EF7231B2B1B for ; Fri, 27 Mar 2015 14:53:19 -0700 (PDT) Received: by qgep97 with SMTP id p97so145952373qge.1 for ; Fri, 27 Mar 2015 14:53:19 -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=2f+MMn0D7Y+eBt0IxQfqya4NN/9jiA+IzqSkef5zrwU=; b=WJxPH9k7oPL4xujuzfuGYizm4E1Boq0rLW5qyyjo8M9mfsUOYIpqC+NKA6r5c1JCg1 m7aZKTkR8Zaq71nrbL/5YosL0Vgd7qpxp/udAPeU+YyjKLmcQCtVQqT9muxyrMhiIrUy 1gxi2fqc/o3lfLYxCcet0yd2lWMC5m6zrIv1ShixOb5X27+RcFHXSHFxbljJ8amGra1P 7fwlvl3xOCI2t+8El0jUbOl0wwFvqwCugcwqzwwou0OJegCkEvf2lWISav5w/UykfdgR z3ak7n5Ic0bre3R8Z3SlJpXrN4oZvWzCKePLjB26SQNvQY55CkC8zIotgsi+BtBq3Lll OHrg== X-Received: by 10.229.122.70 with SMTP id k6mr11997387qcr.27.1427493199244; Fri, 27 Mar 2015 14:53:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id d49sm2380936qge.19.2015.03.27.14.53.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Mar 2015 14:53:18 -0700 (PDT) From: Dave Garrett To: Xiaoyin Liu Date: Fri, 27 Mar 2015 17:53:17 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503260330.43588.davemgarrett@gmail.com> <201503271153.34569.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503271753.17526.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New TLS version negotiation mechanism, take 2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 21:53:22 -0000 On Friday, March 27, 2015 03:46:05 pm Xiaoyin Liu wrote: > > > > + Only one extension with one fixed length value > > > > > > But here you lose the benefit, as the client can't inform the server > > > that it supports multiple TLS 1.3 drafts if the field is of fixed > > > length. > > > > Yes. If we'd like to go back to the list idea, I'm not wholly against > > it. > > > > In this mechanism, the client may support only one draft, but the > > server may support multiple just fine. > > I support the list idea. Besides being able to support draft versions, > there is another benefit. If, for instance, after TLS 1.5 is released, > someone finds a weakness that only exists in TLS 1.4, which makes TLS 1.4 > insecure. But TLS 1.3 and TLS 1.5 are still secure to use, and TLS 1.5 is > better than TLS 1.3. Then with this version negotiation mechanism, > clients can very easily mitigate the TLS 1.4 vulnerability by removing > TLS 1.4 from the supported version list. But with the current version > negotiation, clients would have to either set highest client version to > TLS 1.3 or set to TLS 1.5 but fallback to TLS 1.3 if servers try to > negotiate TLS 1.4. > >I know this is quite unlikely to happen, but I don't think we can safely >assume this will never happen. > >Also this mechanism enables implementations to skip versions for whatever >reasons, such as that some versions are not widely negotiated, like TLS >1.1 today. This was my exact reasoning for my first proposal: https://www.ietf.org/mail-archive/web/tls/current/msg15441.html Brian Smith posted a detailed review here: https://www.ietf.org/mail-archive/web/tls/current/msg15470.html His argument against the list method is that: 1) The client should not be announcing support for old versions that may be weaker than its highest supported version, and that this constitutes an unnecessary security risk. 2) The added complexity of negotiating with potentially non-continuous version support lists is not worth the risk of implementors botching it. Personally, every time the general argument that announcing specific versions of something gives an attacker too much information, I'm not really convinced. That said, I don't really oppose limiting announced information, either. I don't think the added complexity would make things significantly more likely to break, but I don't dispute that it's a valid argument. The complexity differences between the current proposal and a list based proposal are that: a) The ClientHello version field would be frozen and meaningless in a list negotiation, whereas the current proposal recycles it in a manner that avoids clients offering TLS 1.2 without supporting it. b) List negotiation would vary the size of the extension. An arbitrary list size limit would not be a bad idea. It would nonetheless increase bandwidth usage slightly. c) Clients will undoubtedly not all send the lists ordered properly and servers will have to sort through it to hunt for a best match to negotiate. d) On the plus side, a list based negotiation would not be checking any version ranges anymore. It would be only looking for the highest overlapping value between the client and server's lists. I would also add the argument that TLS should not make it more than a few major versions into the future. (DTLS is another story, and there may not even be a need for a new version negotiation mechanism there) TCP needs to be replaced with something that is reliable, fast, and secure. Something QUIC based will probably be the start, eventually. Based on that logic, super future-proofing TLS is counter-productive. Honestly, I think the list based route could be done cleaner, though. Yeah, we might not really need things generalized this much, and non-continuous version support may not in demand, but it might work better. I'm not really opposed to the single max version route either. That said, as I think about and work on the current WIP changeset, I am noting pitfalls that need mentioning that I think can be side-stepped with a list based solution (which might end up with its own, of course :p ). Dave From nobody Fri Mar 27 16: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 595E71A01A5 for ; Fri, 27 Mar 2015 16:33:56 -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 V0BS8mML2ULC for ; Fri, 27 Mar 2015 16:33:52 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::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 8746C1A0187 for ; Fri, 27 Mar 2015 16:33:51 -0700 (PDT) Received: by lagg8 with SMTP id g8so81708577lag.1 for ; Fri, 27 Mar 2015 16:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=sVhyWAXuq7/IphZ/XujP0XXWtO2Ge+YT1Rdx3Leyz7o=; b=OK7yO4koxD1FPyYN03yWZpucZoTQORodgWaUNhWx4ViZKx+7m4x4Lrwgtf+T8UFyAY ziPBtga2j5CrQuJBTF69CkJYh/+WPAezsRr6fAFWyrdcbolPHlsJ7PXWngaD4DlvTNMu 3b58JjHcMwlt3/Zm3VBMs8SiWeqtB3Z6ZN7ZTBw3zyUlEz8ck961ARVSis8IcCHt4Sag M/Z/1/0Q0nWj1VAHLYzGHdUyNsLy4QLpyAslrdQdZgX9UdZdw4ZxsefKIravYtUvuIXV PiQMaHkXdL8ew3vfPqLBNtWkgp8i7YFH3BnajtyffPil7muycrZUyQuKe+CHhMNsuOCC iq0w== X-Received: by 10.112.201.231 with SMTP id kd7mr19978572lbc.35.1427499229916; Fri, 27 Mar 2015 16:33:49 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.9 with HTTP; Fri, 27 Mar 2015 16:33:19 -0700 (PDT) In-Reply-To: <20150327150032.GA27825@LK-Perkele-VII> References: <20150327150032.GA27825@LK-Perkele-VII> From: Hugo Krawczyk Date: Fri, 27 Mar 2015 19:33:19 -0400 X-Google-Sender-Auth: y6uv5SZnf66WlyvCRMQud0uoR50 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c32cda8435e505124d9054 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 23:33:56 -0000 --001a11c32cda8435e505124d9054 Content-Type: text/plain; charset=UTF-8 Illari (I wrote this offline as a response to your email below - it may not address issues raised in follow up email) As usual you raise good questions, even when I don't agree with your answers or conclusions. Let me refer to what I believe is the most important point in your email, namely, the reliance on theoretical analysis of cryptographic protocols. I agree with warnings about total reliance on theoretical analysis or its interpretation as demonstrating the absolute lack of attack venues against a protocol. Any mathematical model that attempts to capture real-world phenomena is prone to fail in some circumstances, and this is certainly the case for systems of the complexity of TLS and the Internet. Add to this that the attacker being modeled in the case of cryptography is as malicious as only humans can be (how do you design an airplane against an insane pilot purposely crashing it into the Alps or a building that needs to withstand the impact of a jet guided by suicide terrorists?) and you can ensure without doubt that no model will be full proof. However, I cannot agree with the unqualified conclusion that "relying on [these models] is a very bad idea". Relying on the theoretical models developed and refined over the years is a major source of confidence in the soundness of the core design of a cryptographic protocol, a core that may miss essential specification and implementation details and semantics but that tells us that the very foundation of the building is sound. Many things can fail in that building at higher levels but not at the most basic foundational cryptographic aspect. Moreover, contrary to what you indicate, cryptographic analysis while imperfect has been remarkably successful in predicting attacks, particularly against TLS. This is the case for CCA attacks against RSA, the essential role of unpredictable IVs in CBC mode, the shortcomings of mac-then-encrypt, the potential exploits from packet compression, etc. It is true that theoreticians (like me) don't always have the knowledge or skills to translate the failures demonstrated in our proofs into real-world attacks, but the world eventually catches up and finishes what we started. One way to look at cryptographic analysis is as a debugging process. Any such process is successful when it helps spotting problems and potential failures but you never really trust that any of these problems is the *last* bug to be found. Yet everyone agrees on the usefulness of such tools. Fortunately, the analysis tools at our disposal increase over time and so is the number of problems we can spot before they become practical ones. The recent works from INRIA and Microsoft on automated tools for analyzing not only the core cryptographic protocol but also its fuller specifications and implementation are great examples. With respect to the point that "The consequence is that even if some "security proof" says that it is okay to simplify system in some way, that simplification might still introduce vulnerabilities.", This is of course a possibility. It falls under "keep it simple but not simpler" principle, but it is in no way a demonstration that simplifications aren't important. They are and if they can be founded on formal analysis then the better. A simpler protocol is easier to specify, implement and maintain (e.g., adopting it to new settings and requirements). Safety margins are necessary but we need to understand what is their role, or else we will end with impractical or unnecessarily complex schemes that are likely to fail in many other ways. In the particular case of OPTLS, I strongly believe that it contributes significantly to the simplification of TLS 1.3 and to a sound cryptographic design (although we need the proofs to move this from a personal belief to something others can verify). I am also under the impression that implementers and specifiers do appreciate the simplification of the protocol, and future designers will do as well when coming to evolve the protocol into new realities. Hugo On Fri, Mar 27, 2015 at 11:00 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > Sorry, this is quite long. > > Some background: > > Be very vary about "security proofs". The scope of how TLS is used is > very broad. There have been numerious papers about "TLS proven secure" > or "part X of TLS proven secure", that have later turned out to be > irrelevant in practice due to insufficient scope (then there are > ocassional security proofs that are just plain wrong). > > E.g. number of papers that overlooked that TLS MS is not CRK and > the screwyness that this causes. E.g. breaking authentication. Or > paper that proved that "BEAST" is impossible... Only to turn out > that it had made an assumption that BEAST attack broke. > > This problem is compounded by the fact that TLS is often used in > environments like WWW, where attackers have unusual powers to > exploit weaknesses that normally are not exploitable. > > The consequence is that even if some "security proof" says that > it is okay to simplify system in some way, that simplification > might still introduce vulernabilities. > > E.g. Consider TLS 1.3 draft -03 (I picked this because it is the > earliest version that I think is implementable at all). It is a > bit simpler than -04, and I think that it in some scope can be > proven "secure". But it also has a known security hole (fixed in > -04). > > OTOH, security proofs that produce conterexamples to security > are useful to look at. The counterexample may or may not be > relevant (telling which is likely nontrivial). If it is relevant > or might be relevant, fixing the problem is worth it. > > > Symmetric crypto is very fast, so a bit of extra hashing, PRFing > or somesuch is pretty much insignificant compared to asymmeric > things like computing signatures, DHFs or DHKGs. > > > Short summary: Security proofs are useful, but relying on them > is a very bad idea. > > > On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote: > > Folks, > > > > As an outcome of the interim, I was asked to write up an initial draft > > of what this would all look like and post it to the list. You can find > > such a draft at: > > > > Git branch: > > https://github.com/ekr/tls13-spec/tree/WIP_dh_based > > > > Text file: > > > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt > > > > HTML diff: > > > https://github.com/ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.html > > > > > > Please note that this is a very rough draft and no doubt contains > > a number of major errors (and certainly has seen no security review). > > Please point these out to me if you find them, especially if they > > impede understanding. Assuming that people are happy with this > > general direction, I will clean it up and turn it into a PR. > > Okay, let's analyze what goes wrong (and fix the thing so it is easy > to analyze): > > - For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs, not two. > 1) PSK input. > 2) PFS diffie-hellman input > 3) Static Diffie-Hellman input. > -> 1 and 3 are not the same, even if they can't appear simultaneously! > - For chaining keys from 0RTT (optional), you need _fourth_ input: > 4) Static diffie-hellman from 0RTT. > -> Only computable if server accepts 0RTT. > -> Needed for gradual static-DH rollover. > - The "handshake master secret" needs to be CR function of: > 1) PFS diffie-hellman iput. > 2) PSK input. > 3) Static diffie-hellman from 0RTT (if exists) > 4) Hash of *Hello and *KeyShare packets. > -> The reason for last is to defend against class of attacks including > Triple Handshake. > - The "application master secret" needs to be CR function of: > 1) handshake master secret. > 2) Static Diffie-Hellman input. > -> The hash is not needed here (but can be included). > -> Can be different in both directions (which has some benefits, > in this case, the hash should be included). > - The "exporter master secret" needs to be CR function of: > 1) hanshake master secret. > 2) Static Diffie-Hellman input. > 3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is > carrying the server static DH key packets (more can be included > for a good measure). > -> The reason why EncryptedExtensions needs to be included is in case > it contains some extensions affecting TLS-Extractor. The reason > server static DH key is needed is again to guard against attacks > like THS. > - The "resume premaster secret" needs to be CR function of: > 1) hanshake master secret. > 2) Static Diffie-Hellman input. > 3) Hash of entiere handshake. > -> The reason why last needs needs to be entiere handshake is that > otherwise session may be resumed in inocnsistent state. > -> Also so that resumption doesn't destroy forward security. > - Online signature (if present) TBS needs to include: > 1) *Random > 2) Purpose of signature (e.g. server PoP) > 3) Ciphersuite # > 4) Prf-hash of messages so far > -> *Random is to support privsep. Which is extremely useful even with > pure SW if you have MMU available (and most of the time you do). > -> Ciphersuite # is to pin the prf-hash algorithm (I think that is > just the simplest way). > > > The "function of" listings above are what I consider the absolute > minimum, that's the reason why "application master secret" hash input > is not marked as needed. It can (and should) be included. > > Also, one should take care that none of the different secrets may > end up being same (except by very bad luck). > > The only thing above -05 fails is "exporter master secret", which > is the same as handshake master secret nor does it hash enough state. > > > Also, other comments: > - I consider HKDF-HMAC-SHA256 to be too weak. > -> I think it needs at least HMAC-SHA384 (also would just give one > prf-hash). > -> SHA384 is FASTER than SHA256 on modern hardware (that's why > SHA-512/256 exists). But SHA3-384 is slower than SHA3-256. > - There is no need to intermingle static DH key with signature, even if > statid DH key exists. > -> Signatures work like in -05. > -> Can completely eliminate signature if one has fixed-DH cert (DHF > is WAY simpler than signature primitive). > > > Also, will *server* 0RTT be supported, even with client authentication? > It would set the following boundary conditions: > - Server application keys can't include hashes of client certificate, > as those need to be computable immediately on server finished. > - The same for exporter master secret. > > The restrictions here are: > - Replay protection is provoded. > - There is no authentication (the server hasn't heard client's > certificate, which keeps misuse potential way down). > > Usecases: > - Protocol banners, feature negoitiation (ALPN doesn't scale!), > etc... > > > Also regarding splitting application keys to directional ones: > - Allows JIT derivation, eliminating temporarily invalid keys. > - Allows rekeying (since requirement is no dead time and arbitrarily > delayed responses, as breaking this causes problems for all > applications). > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c32cda8435e505124d9054 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Illari

(I wrote this offline as a respo= nse to your email below -
it may not address issues raised in follow up= email)

As usual you raise good questions, even when I don't agr= ee with your answers or
conclusions. Let me refer to what I believe is t= he most important point in your
email, namely, the reliance on theoretic= al analysis of cryptographic protocols.

I agree with warnings about = total reliance on theoretical analysis or its
interpretation as demonstr= ating the absolute lack of attack venues against a
protocol. Any mathema= tical model that attempts to capture real-world phenomena
is prone to fa= il in some circumstances, and this is certainly the case for
systems of = the complexity of TLS and the Internet. Add to this that the attacker
be= ing modeled in the case of cryptography is as malicious as only humans can = be
(how do you design an airplane against an insane pilot purposely cras= hing it
into the Alps or a building that needs to withstand the impact o= f a jet guided
by suicide terrorists?) and you can ensure without doubt = that no model will be
full proof.

However, I cannot agree with t= he unqualified conclusion that
=C2=A0 "relying on [these models] i= s a very bad idea".=C2=A0
Relying on the theoretical models develo= ped and refined over the years is a
major source of confidence in the so= undness of the core design of a
cryptographic protocol, a core that may = miss essential specification and
implementation details and semantics bu= t that tells us that the very foundation
of the building is sound.=C2=A0= Many things can fail in that building at higher
levels but not at the m= ost basic foundational cryptographic aspect. Moreover,
contrary to what = you indicate, cryptographic analysis while imperfect has been
remarkably= successful in predicting attacks, particularly against TLS. This is
the= case for CCA attacks against RSA, the essential role of unpredictable IVs = in
CBC mode, the shortcomings of mac-then-encrypt, the potential exploit= s from
packet compression, etc.=C2=A0 It is true that theoreticians (lik= e me) don't always
have the knowledge or skills to translate the fai= lures demonstrated in our
proofs into real-world attacks, but the world = eventually catches up and finishes
what we started.

One way to lo= ok at cryptographic analysis is as a debugging process. Any such
process= is successful when it helps spotting problems and potential failures butyou never really trust that any of these problems is the *last* bug to be= found.
Yet everyone agrees on the usefulness of such tools. Fortunately= , the analysis
tools at our disposal increase over time and so is the nu= mber of problems we can
spot before they become practical ones. The rece= nt works from INRIA and
Microsoft on automated tools for analyzing not o= nly the core cryptographic
protocol but also its fuller specifications a= nd implementation are great
examples.

With respect to the point t= hat
=C2=A0 "The consequence is that even if some "security pr= oof" says that it is okay to
=C2=A0 simplify system in some way, th= at simplification might still introduce
=C2=A0 vulnerabilities.", <= br>This is of course a possibility. It falls under "keep it simple but= not simpler"
principle, but it is in no way a demonstration that s= implifications aren't
important. They are and if they can be founded= on formal analysis then the
better. A simpler protocol is easier to spe= cify, implement and maintain (e.g.,
adopting it to new settings and requ= irements). Safety margins are necessary but
we need to understand what i= s their role, or else we will end with impractical
or unnecessarily comp= lex schemes that are likely to fail in many other ways.

In the parti= cular case of OPTLS, I strongly believe that it contributes
significantl= y to the simplification of TLS 1.3 and to a sound cryptographic
design (= although we need the proofs to move this from a personal belief to
somet= hing others can verify). I am also under the impression that implementersand specifiers do appreciate the simplification of the protocol, and futu= re
designers will do as well when coming to evolve the protocol into new= realities.

Hugo


<= div class=3D"gmail_quote">On Fri, Mar 27, 2015 at 11:00 AM, Ilari Liusvaara= <ilari.liusvaara@elisanet.fi> wrote:
Sorry, this is quite long.

Some background:

Be very vary about "security proofs". The scope of how TLS is use= d is
very broad. There have been numerious papers about "TLS proven secure&= quot;
or "part X of TLS proven secure", that have later turned out to b= e
irrelevant in practice due to insufficient scope (then there are
ocassional security proofs that are just plain wrong).

E.g. number of papers that overlooked that TLS MS is not CRK and
the screwyness that this causes. E.g. breaking authentication. Or
paper that proved that "BEAST" is impossible... Only to turn out<= br> that it had made an assumption that BEAST attack broke.

This problem is compounded by the fact that TLS is often used in
environments like WWW, where attackers have unusual powers to
exploit weaknesses that normally are not exploitable.

The consequence is that even if some "security proof" says that it is okay to simplify system in some way, that simplification
might still introduce vulernabilities.

E.g. Consider TLS 1.3 draft -03 (I picked this because it is the
earliest version that I think is implementable at all). It is a
bit simpler than -04, and I think that it in some scope can be
proven "secure". But it also has a known security hole (fixed in<= br> -04).

OTOH, security proofs that produce conterexamples to security
are useful to look at. The counterexample may or may not be
relevant (telling which is likely nontrivial). If it is relevant
or might be relevant, fixing the problem is worth it.


Symmetric crypto is very fast, so a bit of extra hashing, PRFing
or somesuch is pretty much insignificant compared to asymmeric
things like computing signatures, DHFs or DHKGs.


Short summary: Security proofs are useful, but relying on them
is a very bad idea.


On Mon, Mar 23, 2015 at 08:36:41AM -0500, Eric Rescorla wrote:
> Folks,
>
> As an outcome of the interim, I was asked to w= rite up an initial draft
> of what this would all look like and post it to the list. You can find=
> such a draft at:
>
> Git branch:
> https://github.com/ekr/tls13-spec/tree/WIP_dh_based
>
> Text file:
> https://github.com/ekr/tl= s13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based.txt
>
> HTML diff:
> https://github.com/= ekr/tls13-spec/blob/ietf92_materials/draft-ietf-tls-tls13-dh-based-diff.htm= l
>
>
> Please note that this is a very rough draft and no doubt contains
> a number of major errors (and certainly has seen no security review).<= br> > Please point these out to me if you find them, especially if they
> impede understanding. Assuming that people are happy with this
> general direction, I will clean it up and turn it into a PR.

Okay, let's analyze what goes wrong (and fix the thing so it is = easy
to analyze):

- For PSK/PFS/Static-DH "unified" scheme, there is _three_ inputs= , not two.
=C2=A0 1) PSK input.
=C2=A0 2) PFS diffie-hellman input
=C2=A0 3) Static Diffie-Hellman input.
=C2=A0 -> 1 and 3 are not the same, even if they can't appear simult= aneously!
- For chaining keys from 0RTT (optional), you need _fourth_ input:
=C2=A0 4) Static diffie-hellman from 0RTT.
=C2=A0 -> Only computable if server accepts 0RTT.
=C2=A0 -> Needed for gradual static-DH rollover.
- The "handshake master secret" needs to be CR function of:
=C2=A0 1) PFS diffie-hellman iput.
=C2=A0 2) PSK input.
=C2=A0 3) Static diffie-hellman from 0RTT (if exists)
=C2=A0 4) Hash of *Hello and *KeyShare packets.
=C2=A0 -> The reason for last is to defend against class of attacks incl= uding
=C2=A0 =C2=A0 =C2=A0Triple Handshake.
- The "application master secret" needs to be CR function of:
=C2=A0 1) handshake master secret.
=C2=A0 2) Static Diffie-Hellman input.
=C2=A0 -> The hash is not needed here (but can be included).
=C2=A0 -> Can be different in both directions (which has some benefits,<= br> =C2=A0 =C2=A0 =C2=A0in this case, the hash should be included).
- The "exporter master secret" needs to be CR function of:
=C2=A0 1) hanshake master secret.
=C2=A0 2) Static Diffie-Hellman input.
=C2=A0 3) The hash of *Hello, *Keyshare EncryptedExtensions and whatever is=
=C2=A0 =C2=A0 =C2=A0carrying the server static DH key packets (more can be = included
=C2=A0 =C2=A0 =C2=A0for a good measure).
=C2=A0 -> The reason why EncryptedExtensions needs to be included is in = case
=C2=A0 =C2=A0 =C2=A0it contains some extensions affecting TLS-Extractor. Th= e reason
=C2=A0 =C2=A0 =C2=A0server static DH key is needed is again to guard agains= t attacks
=C2=A0 =C2=A0 =C2=A0like THS.
- The "resume premaster secret" needs to be CR function of:
=C2=A0 1) hanshake master secret.
=C2=A0 2) Static Diffie-Hellman input.
=C2=A0 3) Hash of entiere handshake.
=C2=A0 -> The reason why last needs needs to be entiere handshake is tha= t
=C2=A0 =C2=A0 =C2=A0otherwise session may be resumed in inocnsistent state.=
=C2=A0 -> Also so that resumption doesn't destroy forward security.<= br> - Online signature (if present) TBS needs to include:
=C2=A0 1) *Random
=C2=A0 2) Purpose of signature (e.g. server PoP)
=C2=A0 3) Ciphersuite #
=C2=A0 4) Prf-hash of messages so far
=C2=A0 -> *Random is to support privsep. Which is extremely useful even = with
=C2=A0 =C2=A0 =C2=A0pure SW if you have MMU available (and most of the time= you do).
=C2=A0 -> Ciphersuite # is to pin the prf-hash algorithm (I think that i= s
=C2=A0 =C2=A0 =C2=A0just the simplest way).


The "function of" listings above are what I consider the absolute=
minimum, that's the reason why "application master secret" ha= sh input
is not marked as needed. It can (and should) be included.

Also, one should take care that none of the different secrets may
end up being same (except by very bad luck).

The only thing above -05 fails is "exporter master secret", which=
is the same as handshake master secret nor does it hash enough state.


Also, other comments:
- I consider HKDF-HMAC-SHA256 to be too weak.
=C2=A0 -> I think it needs at least HMAC-SHA384 (also would just give on= e
=C2=A0 =C2=A0 =C2=A0prf-hash).
=C2=A0 -> SHA384 is FASTER than SHA256 on modern hardware (that's wh= y
=C2=A0 =C2=A0 =C2=A0SHA-512/256 exists). But SHA3-384 is slower than SHA3-2= 56.
- There is no need to intermingle static DH key with signature, even if
=C2=A0 statid DH key exists.
=C2=A0 -> Signatures work like in -05.
=C2=A0 -> Can completely eliminate signature if one has fixed-DH cert (D= HF
=C2=A0 =C2=A0 =C2=A0is WAY simpler than signature primitive).


Also, will *server* 0RTT be supported, even with client authentication?
It would set the following boundary conditions:
- Server application keys can't include hashes of client certificate, =C2=A0 as those need to be computable immediately on server finished.
- The same for exporter master secret.

The restrictions here are:
- Replay protection is provoded.
- There is no authentication (the server hasn't heard client's
=C2=A0 certificate, which keeps misuse potential way down).

Usecases:
- Protocol banners, feature negoitiation (ALPN doesn't scale!),
=C2=A0 etc...


Also regarding splitting application keys to directional ones:
- Allows JIT derivation, eliminating temporarily invalid keys.
- Allows rekeying (since requirement is no dead time and arbitrarily
=C2=A0 delayed responses, as breaking this causes problems for all
=C2=A0 applications).



-Ilari

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

--001a11c32cda8435e505124d9054-- From nobody Fri Mar 27 16:50: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 1E6131A028A for ; Fri, 27 Mar 2015 16:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAIO4bZwCh0E for ; Fri, 27 Mar 2015 16:50:15 -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 A55C21A0276 for ; Fri, 27 Mar 2015 16:50:14 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so50876069wib.1 for ; Fri, 27 Mar 2015 16:50:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ylslXsOd/J8P7q1Dx38OqcYLQe0+17xAHBhDpAGs+Fo=; b=MFz9QWotvdpULikExRPIGuHQQk7SGKewW1xBu8mgr1UrJH3VwWhRso8WI288CCJsO0 IlBxXsL2CY1hU6eMnLDgpSRdhL8Sd9S28N538afc3fN5UFiNIPiHCAyfk3aGhGUmJ0jt mNPZgU6BvZfTNoQViLJTIPYoxitfdNpEEbLsQIp8GrWKOGpKnPip9ZxcdMMpAHFgnzOJ e/84CfwPHJZWljTuDopIf64QDXuVob9O4Eq1jWIzKa/UQ89RTIowoLKXjSLm2dZ1Bq9Z dpVVfVs30y47FzYJoSfalJWLcuSOZECoI/WJkzYe/JrDjng5/pIEAuVPS72t16pip5D+ NUyg== X-Gm-Message-State: ALoCoQlK6e59mSoE0/p0K0jXau8D7Cw32SxJ1/k9MoUn3Whr3iL4vuUrtBZkRMDCyndxDbxbt5ZF X-Received: by 10.181.13.133 with SMTP id ey5mr1947542wid.59.1427500213424; Fri, 27 Mar 2015 16:50:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.198 with HTTP; Fri, 27 Mar 2015 16:49:33 -0700 (PDT) In-Reply-To: <27B74C98-C6B2-4AD0-A90A-4528DB50B904@vigilsec.com> References: <27B74C98-C6B2-4AD0-A90A-4528DB50B904@vigilsec.com> From: Eric Rescorla Date: Fri, 27 Mar 2015 18:49:33 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=f46d04388fe123880405124dcbab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 23:50:16 -0000 --f46d04388fe123880405124dcbab Content-Type: text/plain; charset=UTF-8 On Fri, Mar 27, 2015 at 4:44 PM, Russ Housley wrote: > Eric: > > At the interim discussed transitioning to a DH-based handshake (rather > than a signature-based one) like that proposed by Hugo Krawczyk and > Hoeteck Wee. The major rationale for this change is that any 0-RTT > mode is inherently DH-based and so if we make that our basic mode, > then we can simplify the protocol logic and key derivation model. This > model also allows us to pull in PSK modes under the same basic > structure. > > > I was not at the interim, but I was at the TLS session at IETF 92 in > Dallas. > > I was watching your presentation pretty carefully, and I do not recall a > slide on support for PSK. Can you point me to a description of "PSK modes > under the same basic structure"? > The document I pointed to upthread contains a description of the key schedule. I still have to write up the PSK negotiation syntax. -Ekr > Russ > > --f46d04388fe123880405124dcbab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 27, 2015 at 4:44 PM, Russ Housley <housley@vigilsec.com= > wrote:
Eric:

At the int= erim discussed transitioning to a DH-based handshake (rather
than= a signature-based one) like that proposed by Hugo Krawczyk and
H= oeteck Wee. The major rationale for this change is that any 0-RTT
mode is inherently DH-based and so if we make that our basic mode,
then we can simplify the protocol logic and key derivation model. This
model also allows us to pull in PSK modes under the same basic
structure.

I was not = at the interim, but I was at the TLS session at IETF 92 in Dallas.

I was watching your presentation pretty carefully, and I d= o not recall a slide on support for PSK.=C2=A0 Can you point me to a descri= ption of "PSK modes under the same basic structure"?
<= /blockquote>

The document I pointed to upthread contains= a description of the key schedule. I still have to write up the PSK negoti= ation syntax.


-Ekr
=C2=A0=
Russ

=

--f46d04388fe123880405124dcbab-- From nobody Fri Mar 27 16:52: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 A4B421A00DB for ; Fri, 27 Mar 2015 16:52:28 -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 74KzGosR1ITQ for ; Fri, 27 Mar 2015 16:52:27 -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 704FD1A0023 for ; Fri, 27 Mar 2015 16:52:26 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so74176471lbc.0 for ; Fri, 27 Mar 2015 16:52:25 -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:from:date:message-id :subject:to:cc:content-type; bh=od6y+Ff7wRpShFnUyzAW6KZG5WL7DiqGR/AoDkZVHf8=; b=p3x6Qn0zR5Gjx4zGukNbPq3W4yezl1vMTeiUhOWTWzloDQ/1YErgQX+kY9FnR23bW6 fuelVsfrzP2o+HYQ18y+YnmQAcGp+ydzypr6TWcmZH8y1beX9PlwdttVVIhKQeaSiVGo wairdHB/xe8FJLTalxd3IRTM38LdJfwtFWdgCHefd10C6ZJD0QxtY0P/YQil3hRh8XWx Gq7DrnpI6CHTSjJmHZMnbGddkQ8ksLi8ojQbaWmNUbb2y6QZX4yGsVBLb0pmiQ3nJMRk Q/EwUIn1pe9H+q+FDBEG1pvJAh9vxt+WBPKjuHFrLGyi85b3d85jAXTdNdoYq4qZndUk rhSg== X-Received: by 10.152.198.170 with SMTP id jd10mr19543949lac.60.1427500344979; Fri, 27 Mar 2015 16:52:24 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.78.9 with HTTP; Fri, 27 Mar 2015 16:51:54 -0700 (PDT) In-Reply-To: <20150327161746.GA28742@LK-Perkele-VII> References: <20150327150032.GA27825@LK-Perkele-VII> <20150327161746.GA28742@LK-Perkele-VII> From: Hugo Krawczyk Date: Fri, 27 Mar 2015 19:51:54 -0400 X-Google-Sender-Auth: Mc653C4Hccp-MAimYRYKv2T-FlI Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11349c0afab76405124dd243 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Mar 2015 23:52:28 -0000 --001a11349c0afab76405124dd243 Content-Type: text/plain; charset=UTF-8 The theme of simplification applies to your concerns below too. The simpler the protocol the closer it stays to its underlying cryptographic core hence the closer it stays to the cryptographic semantics. Actually, the issue of simplifying semantics is of utmost importance. For example, the hierarchical key derivation scheme in TLS 1.3/OPTLS bind terminal keys (those used for data protection either inside the handshake or output for record protection) to a unique context encompassing a label defining the key's functionality and information that ties the key to particular handshake session (including nonces, negotiated parameters, identities, etc.). That defines the semantics and provenance of keys which should be the only thing that consumers of the TLS handshake need to know about these keys. One thing to double check when specifying the handshake protocol is that context and intended semantics match indeed. (I wonder, for example, if we should label keys derived with PFS from those derived without PFS.) Hugo On Fri, Mar 27, 2015 at 12:17 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Fri, Mar 27, 2015 at 03:27:54PM +0000, Paterson, Kenny wrote: > > > > The limitation of scope does not mean the papers are useless. As you > write > > above, one just needs to be wary of over-interpreting what they say. > > Well, not useless, but... > > There are different kinds of problems arising for over-interpreting > security proofs: > > Take some protocol X that is designed to use TLS feature Y for purpose > Z (e.g. SPDY used TLS-Extractor for channel binding). > > This can be outright broken (like the example is in TLS 1.2 without > extensions). > > This calls for documenting limiations of various TLS features. And > preferably not provoding "attractive nuisances". But that doesn't > mean the features provoded won't be used in strange ways. > > > More nasty case is if there is a security proof that some strengthening > A is unnecressary given assumptions B (which seems quite broadly > applicable). > Then TLS removes A as "unnecressary". Except that using Y for Z breaks B > and relies on A, so now X is insecure. This is obviously highly attractive > for crypto sabotage projects. > > E.g. suppose TLS had renego-fix-like fix for resumption. Now remove > session-hash because it is unnecressary given proper certificate > authentication. Except now TLS-Extractor for channel binding is broken. > > This calls for being conservative with strengthening. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11349c0afab76405124dd243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The theme of simplification applies to your con= cerns below too.
The simpler the protocol the closer it= stays to its underlying cryptographic core hence the closer it stays to th= e cryptographic semantics.
Actually, the issue of simpl= ifying semantics is of utmost importance.

For examp= le, the hierarchical key derivation scheme in TLS 1.3/OPTLS bind terminal k= eys (those used for data protection either inside the handshake or output f= or record protection) to a unique context encompassing a label defining the= key's functionality and information that ties the key to particular ha= ndshake session (including nonces, negotiated parameters, identities, etc.)= . That defines the semantics and provenance of keys which should be the onl= y thing that consumers of the TLS handshake need to know about these keys.<= br>
One thing to double check when specifying the hands= hake protocol is that context and intended semantics match indeed.
(I wonder, for example, if we should label keys derived with PF= S from those derived without PFS.)

Hugo


On Fri, Mar 27, 2015 at 12:17 PM, Ilari Liusva= ara <ilari.liusvaara@elisanet.fi> wrote:
On Fri, Mar 27, 2015 at 03:27:54P= M +0000, Paterson, Kenny wrote:
>
> The limitation of scope does not mean the papers are useless. As you w= rite
> above, one just needs to be wary of over-interpreting what they say.
Well, not useless, but...

There are different kinds of problems arising for over-interpreting
security proofs:

Take some protocol X that is designed to use TLS feature Y for purpose
Z (e.g. SPDY used TLS-Extractor for channel binding).

This can be outright broken (like the example is in TLS 1.2 without
extensions).

This calls for documenting limiations of various TLS features. And
preferably not provoding "attractive nuisances". But that doesn&#= 39;t
mean the features provoded won't be used in strange ways.


More nasty case is if there is a security proof that some strengthening
A is unnecressary given assumptions B (which seems quite broadly applicable= ).
Then TLS removes A as "unnecressary". Except that using Y for Z b= reaks B
and relies on A, so now X is insecure. This is obviously highly attractive<= br> for crypto sabotage projects.

E.g. suppose TLS had renego-fix-like fix for resumption. Now remove
session-hash because it is unnecressary given proper certificate
authentication. Except now TLS-Extractor for channel binding is broken.

This calls for being conservative with strengthening.


-Ilari

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

--001a11349c0afab76405124dd243-- From nobody Fri Mar 27 19:53: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 8EDA01A1B6D for ; Fri, 27 Mar 2015 19:53: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 g0_bYcWEJVDN for ; Fri, 27 Mar 2015 19:53:33 -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 6E5991A1B69 for ; Fri, 27 Mar 2015 19:53:33 -0700 (PDT) Received: by qgf60 with SMTP id 60so131486568qgf.3 for ; Fri, 27 Mar 2015 19:53:32 -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=1S52AmwwbgOMYejhF4jJ0+yqZR0dBpf4+Guj7Lcf4vA=; b=sth8hRiEsCAOtUp+9uSlyYX/or09qJVHSIRAr7uNdSKuD6+LG1SVrX96I+y+KB96Df 1GdV79rUYnU+gppBxZnxsnncHe+D8Ls84IHwd+t5p3opZ3eNYm2vBp+KhByTA8oIoJuP n8a4UrEpHS6GR55l8cHLfNVoQenjZ8/HGF/MQP6wU5xlfnswiRvYcGa5bgRYbi/4S7oM rC9Bq5JtJsMqPWiN4uXdXcG6UI7IJ5W8OtSN1z57zgra1TBwuRM5m4nptcHNstObAHJ2 z/qdZQZu5X8Tb8sfz4mqgxtux2PtmzSf0YEX8d3kPqclV78CtfJET6TCsgayh+KCkd2f AVsA== X-Received: by 10.140.132.197 with SMTP id 188mr29520055qhe.24.1427511212775; Fri, 27 Mar 2015 19:53:32 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 78sm1568033qks.47.2015.03.27.19.53.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Mar 2015 19:53:32 -0700 (PDT) From: Dave Garrett To: Xiaoyin Liu , Brian Smith Date: Fri, 27 Mar 2015 22:53:30 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503260330.43588.davemgarrett@gmail.com> <201503271153.34569.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201503272253.30495.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] New TLS version negotiation mechanism extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 02:53:35 -0000 On Sunday, March 08, 2015 01:39:47 pm Dave Garrett wrote: > A basic proposal for a new TLS version negotiation mechanism for TLS 1.3+= =2E It'll be needed to handle draft implementations, if desired, and I thin= k it might just be wanted for all negotiation. TLS 1.3 version intolerance = is currently surveyed to be in the ~1.5% range [1]. The simplest method is = to do so via a new mandatory extension, as has been suggested by people bef= ore. On Tuesday, March 10, 2015 10:08:27 am Brian Smith wrote: > I agree that that seems like the best way forward. [...] > Anyway, I support your proposal, if it is simplified. On Friday, March 27, 2015 03:46:05 pm Xiaoyin Liu wrote: > I support this version negotiation proposal, but I prefer the old one, i.= e. listing all supported TLS versions. Ok, I've written out the bulk of main changes that would be needed to do bo= th potential new methods: #1: an extension providing full lists of version support which the server f= ind the highest common value of #2: an extension using basically the same method as previously, but bumping= the value to the extension =46or others on the mailing list, the reasons for this are the irritatingly= high rate of TLS 1.3+ version intolerance that would seriously hamper adop= tion of a new version, as well as the desire to negotiate draft versions to= get widespread testing (similar to how HTTP/2 did things). My initial idea was for method #1, however upon scrutiny by Brian and mysel= f, I decided to work on fleshing out #2. The potential complexity did sound= like a larger risk. After doing so, I think that whilst #2 ~sounds~ simple= r because it's very similar to the current negotiation method, in reality, = #1 is far more straightforward and has fewer potential pitfalls in implemen= ting. I have two WIP branches, one for each method: #1: https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett= :EVN #2: https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett= :NVN (compare links because patch-3/PR#107 is approved, but not yet merged into = trunk) Comparing between the two branches, the main difference is that whilst the = list method has more info for the server to deal with, it's simpler to hand= le and explain in fewer words more clearly. With the simple proposed value,= the server has to pick the highest version it supports less than the propo= sed version. When throwing draft versions into the mix, a server needs to m= ake sure not to offer an draft version if the client did not offer support = for one. (alternatively we could have another extension for drafts, but tha= t's more complicated overall and I really want a single method that gets pr= operly tested prior to release) In enumerating the pitfalls I see, the erro= rs that need to checked for in the list method can be explained more simply= =2E I can lay out the entire list based algorithm in a handful of lines of = pseudocode, whereas for the simple proposed value method it's a sprinkling = of "MUST" instructions throughout the spec. This completely new method also= ensures that nobody just uses whatever old algorithm they had with potenti= ally problematic changes to handle the new. Note, that while I say "complet= ely new", I mean new to TLS versioning. It's similar to ALPN in concept. Note that in the current version of #2 (NVN branch) I'm recycling the hello= version to use as a min_version to add the ability for servers to never ev= en offer to downgrade further than the client wants. This could be dropped = to simplify things, though I don't think it's worth it. The draft of #1 (EV= N branch) does not need anything like that to have the server pick a viable= version every time (if one exists), and can also handle non-continuous sup= ported version lists easily. (e.g. support 1.2 and 1.4 but not 1.3, and hav= e a 1.4 server negotiate 1.2 instead of offer 1.3 and fail) In that case, t= he hello version is frozen. Both branches rename the ServerHello version to= negotiated_version to make it clear what it actually means. (with PR #107,= the record layer version is also frozen) So, now I think #1 is the way forward, after giving #2 a shot. Still a WIP,= but any feedback would be greatly appreciated. Dave From nobody Sat Mar 28 02:55: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 1C56E1A700C for ; Sat, 28 Mar 2015 02:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TK25znXATmpE for ; Sat, 28 Mar 2015 02:55:27 -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 8D28C1A700A for ; Sat, 28 Mar 2015 02:55:26 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 2C88B402E; Sat, 28 Mar 2015 11:55:23 +0200 (EET) Date: Sat, 28 Mar 2015 11:55:22 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150328095522.GA21290@LK-Perkele-VII> References: <20150327150032.GA27825@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] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 09:55:31 -0000 On Fri, Mar 27, 2015 at 07:33:19PM -0400, Hugo Krawczyk wrote: > > I agree with warnings about total reliance on theoretical analysis or its > interpretation as demonstrating the absolute lack of attack venues against a > protocol. Any mathematical model that attempts to capture real-world > phenomena > is prone to fail in some circumstances, and this is certainly the case for > systems of the complexity of TLS and the Internet. Add to this that the > attacker > being modeled in the case of cryptography is as malicious as only humans > can be > (how do you design an airplane against an insane pilot purposely crashing it > into the Alps or a building that needs to withstand the impact of a jet > guided > by suicide terrorists?) and you can ensure without doubt that no model will > be > full proof. At one level one can consider mathematical idealities. But because real world affects the assumptions (e.g. that TLS-Extractor outputs have to be suitable for channel binding), full analysis becomes an impossiblity (there are probably much nastier real-world assumptions in proving the security of real-world protocols using TLS). Also, sometimes even at this level, the answer to "how to protect against X?" is "you can't". Like TLS (and QUIC) designers realized with replay resistant 0-RTT. Then there is real-world implementation. Can't even be reliably modelled. However, there are many kinds of constructs that are asking for trouble here. An example might be to first MAC the ciphertext, then pad it with deterministic rule and finally encrypt the whole thing (TLS block ciphers anyone?). This is the construct that gave rise to LUCKY 13 and POODLE TLS. > However, I cannot agree with the unqualified conclusion that > "relying on [these models] is a very bad idea". > Relying on the theoretical models developed and refined over the years is a > major source of confidence in the soundness of the core design of a > cryptographic protocol, a core that may miss essential specification and > implementation details and semantics but that tells us that the very > foundation > of the building is sound. Many things can fail in that building at higher > levels but not at the most basic foundational cryptographic aspect. > Moreover, > contrary to what you indicate, cryptographic analysis while imperfect has > been > remarkably successful in predicting attacks, particularly against TLS. This > is > the case for CCA attacks against RSA, the essential role of unpredictable > IVs in > CBC mode, the shortcomings of mac-then-encrypt, the potential exploits from > packet compression, etc. It is true that theoreticians (like me) don't > always > have the knowledge or skills to translate the failures demonstrated in our > proofs into real-world attacks, but the world eventually catches up and > finishes > what we started. Sure, if you have "negative" security result, and it appears it could apply with primitives used in real world, that is something worth fixing. My post was about cauntion about "positive" security results. (Then there is "elusive" result, where one can't prove something either secure or insecure). > With respect to the point that > "The consequence is that even if some "security proof" says that it is > okay to > simplify system in some way, that simplification might still introduce > vulnerabilities.", > This is of course a possibility. It falls under "keep it simple but not > simpler" > principle, but it is in no way a demonstration that simplifications aren't > important. They are and if they can be founded on formal analysis then the > better. A simpler protocol is easier to specify, implement and maintain > (e.g., > adopting it to new settings and requirements). Safety margins are necessary > but > we need to understand what is their role, or else we will end with > impractical > or unnecessarily complex schemes that are likely to fail in many other ways. I don't think the simplest protocol is optimal. This is because such protcol likely will have security arising from subtle intreactions, which causes several undesirable things: - It is likely hard to analyze (doesn't modularze well). - It likely can't handle loosening assumptions well. - Implementation errors tend to have bad consequences. OTOH, too complex protocol is also very undesirable: - It is hard to to analyze due to number of things that can go wrong. - Implementation errors tend to be inevitable. I think the optimum is at simple side but not at the simplest, having stregthening at carefully chosen places. - Easy to analyze (modular structure). - Minimize chances it breaks horribly on loosening assumptions. - Minimize chances of implementation error. And as for implemenation, it should be designed in a way that there are very few or none tempting shortcuts that compromise security. That includes minimizing number of checks performed, since each that is needed for security is a potential vulernability waiting to happen. If you have strict set of assumptions, correct implementations and can handle hard proving work, you don't need any security margins here. Unfortunately, you don't have that, so you need security margin. And then the question becomes, in what places one puts that security margin, so it defends against wrong assumptions and implementation errors and simplifies the analysis the best. > In the particular case of OPTLS, I strongly believe that it contributes > significantly to the simplification of TLS 1.3 and to a sound cryptographic > design (although we need the proofs to move this from a personal belief to > something others can verify). I am also under the impression that > implementers > and specifiers do appreciate the simplification of the protocol, and future > designers will do as well when coming to evolve the protocol into new > realities. It is also very useful for security analysis to modularize, giving useful results about various parts. Such tends to be very helpful in generalizing security analysis when it turns out you need looser assumptions. And, well, the "simplificiations" for implementation I had in mind are more about encouraging implementations to do the right thing by removing tempting "shortcuts" like handshake message type info (Java got screwed over hard by that "shortcut"). -Ilari From nobody Sat Mar 28 03:06: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 653261A70FE for ; Sat, 28 Mar 2015 03:06: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 UVqSNjrbNaeQ for ; Sat, 28 Mar 2015 03:06:49 -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 DD7A01A702E for ; Sat, 28 Mar 2015 03:06:48 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id D44A5402E; Sat, 28 Mar 2015 12:06:46 +0200 (EET) Date: Sat, 28 Mar 2015 12:06:46 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20150328100646.GB21290@LK-Perkele-VII> References: <20150327150032.GA27825@LK-Perkele-VII> <20150327161746.GA28742@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] Initial draft of DH-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 10:06:50 -0000 On Fri, Mar 27, 2015 at 07:51:54PM -0400, Hugo Krawczyk wrote: > The theme of simplification applies to your concerns below too. > The simpler the protocol the closer it stays to its underlying > cryptographic core hence the closer it stays to the cryptographic semantics. > Actually, the issue of simplifying semantics is of utmost importance. > > For example, the hierarchical key derivation scheme in TLS 1.3/OPTLS bind > terminal keys (those used for data protection either inside the handshake > or output for record protection) to a unique context encompassing a label > defining the key's functionality and information that ties the key to > particular handshake session (including nonces, negotiated parameters, > identities, etc.). That defines the semantics and provenance of keys which > should be the only thing that consumers of the TLS handshake need to know > about these keys. > > One thing to double check when specifying the handshake protocol is that > context and intended semantics match indeed. I consider it important to: 1) Ensure that there are point where entiere context is captured. E.g. Handshake master secret not being in every key derivation chain or not including transcript so far makes security analysis quite a bit harder. This is from attackers being able to penetrate deeper into structure in less well defined ways. See the session_hash I-D for example of things potentially going wrong due lack of such point ("attacks [...] are not yet known"). To be fair to session_hash, TLS 1.2 structure is the problem. But TLS 1.3 has very natural point of doing so: The place where handshake goes encrypted and associated handshake MS. 2) Capture entiere relevant context for anything potentially used for authentication. TLS-Extractor MS needs to incorporate EncryptedExtensions in case there is some extension affecting TLS-Extractor. 3) Mix in input keys at the earliest available stage. The PSK and static-DH inputs are not the same! 4) Keep separate keys separate Using application MS as exporter MS seems like a bad idea. -Ilari From nobody Sat Mar 28 08:39: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 E22681A892C for ; Sat, 28 Mar 2015 08:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVlFocZlkehN for ; Sat, 28 Mar 2015 08:39:39 -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 7739C1A892B for ; Sat, 28 Mar 2015 08:39:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45064BEB1 for ; Sat, 28 Mar 2015 15:39:37 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSuoKrw7l3qt for ; Sat, 28 Mar 2015 15:39:36 +0000 (GMT) Received: from [10.32.65.98] (unknown [31.221.87.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E61BBEAF for ; Sat, 28 Mar 2015 15:39:36 +0000 (GMT) Message-ID: <5516CB38.4050609@cs.tcd.ie> Date: Sat, 28 Mar 2015 15:39:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tls@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] AD review of draft-ietf-tls-session-hash-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 15:39:40 -0000 Nothing to say really:-) I've asked for IETF LC. Thanks, S. From nobody Sat Mar 28 11:53:34 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 547701A8F39; Sat, 28 Mar 2015 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOqsBqp2Z7rn; Sat, 28 Mar 2015 11:53:25 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A0A041A8F40; Sat, 28 Mar 2015 11:53:25 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1C178F991; Sat, 28 Mar 2015 14:53:23 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B4F60218DC; Sat, 28 Mar 2015 11:43:00 -0500 (CDT) From: Daniel Kahn Gillmor To: Tero Kivinen , tls@ietf.org, draft-ietf-tls-negotiated-ff-dhe@ietf.org In-Reply-To: <21780.25234.61519.90042@fireball.kivinen.iki.fi> References: <21780.25234.61519.90042@fireball.kivinen.iki.fi> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sat, 28 Mar 2015 12:43:00 -0400 Message-ID: <87oandt6nf.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] Draft-ietf-tls-negotited-ff-dhe-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 18:53:31 -0000 On Thu 2015-03-26 15:48:34 -0400, Tero Kivinen wrote: > In Honolulu I verified that the primes generated in the > draft-ietf-tls-negotited-ff-dhe correctly, i.e. I generated them > again, and got same results. I also verified that they are primes > using primo. This morning I checked that the new 2048 bit group added > after that is also correct, but found problem there. > > The actual hex number in the draft is correct, but the formula for the > numebr is wrong. > > I.e. A.1. ffdhe2048 says: > > The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560315 } * 2^64 > - 1 > > but that does not match the hex number, there is off-by-one error. The > number 560315 should be 560316 instead. Yikes, I can confirm this. Thanks to Tero for verifying the formulas as well as the hex numbers. It appears i had rounded instead of flooring when computing ffdhe2048, how embarrassing. I plan to submit -08 when i get back on-network that will have this piece corrected. > I also put all the primo primality proof certificates on my web page > (along with the IKE primality certificates): > https://kivinen.iki.fi/primes/ I've also calculated primo primality proofs and placed them here: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ Regards, --dkg From nobody Sat Mar 28 12:02:34 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 355BB1A9034 for ; Sat, 28 Mar 2015 12:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E3hDKBgq28e for ; Sat, 28 Mar 2015 12:02:32 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4AB1A9006 for ; Sat, 28 Mar 2015 12:02:31 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t2SJ2SWJ003260; Sat, 28 Mar 2015 15:02:28 -0400 Date: Sat, 28 Mar 2015 15:02:27 -0400 (EDT) From: Nikos Mavrogiannopoulos To: tls@ietf.org Message-ID: <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> In-Reply-To: <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> References: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: interop checking for ChaCha20/Poly1305 Thread-Index: hntWrEi947Zu5rkMfXYBQ1rC3iTOyQ== Archived-At: Subject: [TLS] interop checking for ChaCha20/Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 19:02:33 -0000 ----- Original Message ----- > And if/when the WG adopts, we might want to ask for early assignment of code > points. I've implemented the drafts in gnutls and created a temporary server which negotiates the following ciphersuites: TLS_RSA_CHACHA20_POLY1305 { 0xCD, 0x30 } TLS_ECDHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x31 } TLS_ECDHE_ECDSA_CHACHA20_POLY1305 { 0xCD, 0x32 } TLS_DHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x33 } TLS_DHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x34 } TLS_PSK_CHACHA20_POLY1305 { 0xCD, 0x35 } TLS_ECDHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x36 } TLS_RSA_PSK_CHACHA20_POLY1305 { 0xCD, 0x37 } If you successfully (or unsuccessfully) checked interoperability drop me a line. regards, Nikos From nobody Sat Mar 28 12:03: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 642441A904F for ; Sat, 28 Mar 2015 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAQAdC_QxkTt for ; Sat, 28 Mar 2015 12:03:30 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (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 6284C1A9039 for ; Sat, 28 Mar 2015 12:03:30 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2SJ3UKF006986 for ; Sat, 28 Mar 2015 15:03:30 -0400 Date: Sat, 28 Mar 2015 15:03:30 -0400 (EDT) From: Nikos Mavrogiannopoulos To: tls@ietf.org Message-ID: <390055189.4261813.1427569410011.JavaMail.zimbra@redhat.com> In-Reply-To: <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> References: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: interop checking for ChaCha20/Poly1305 Thread-Index: hntWrEi947Zu5rkMfXYBQ1rC3iTOyURDQa3U Archived-At: Subject: Re: [TLS] interop checking for ChaCha20/Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 19:03:31 -0000 ----- Original Message ----- > I've implemented the drafts in gnutls and created a temporary server which > negotiates the following ciphersuites: > > TLS_RSA_CHACHA20_POLY1305 { 0xCD, 0x30 } > TLS_ECDHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x31 } > TLS_ECDHE_ECDSA_CHACHA20_POLY1305 { 0xCD, 0x32 } > TLS_DHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x33 } > TLS_DHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x34 } > TLS_PSK_CHACHA20_POLY1305 { 0xCD, 0x35 } > TLS_ECDHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x36 } > TLS_RSA_PSK_CHACHA20_POLY1305 { 0xCD, 0x37 } > > If you successfully (or unsuccessfully) checked interoperability drop me a > line. I pressed sent before sending the server address :) The server is at: nikos.codelas.eu:4443 regards, Nikos From nobody Sat Mar 28 12:16: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 F087B1A8A6D; Sat, 28 Mar 2015 12:16:16 -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 sDZaiJJka9rd; Sat, 28 Mar 2015 12:16:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D58621A885F; Sat, 28 Mar 2015 12:16:15 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150328191615.28800.69049.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 12:16:15 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-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: Sat, 28 Mar 2015 19:16:17 -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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-08.txt Pages : 25 Date : 2015-03-28 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "EC Named Curve Registry" to establish common finite-field DH parameters with known structure and a mechanism for peers to negotiate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-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 Sat Mar 28 12:16: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 335611A8A6D; Sat, 28 Mar 2015 12:16:18 -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 sXudGAULe4h6; Sat, 28 Mar 2015 12:16:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5A1A8A44; Sat, 28 Mar 2015 12:16:16 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150328191616.28800.14710.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 12:16:16 -0700 Archived-At: Subject: [TLS] New Version Notification - draft-ietf-tls-negotiated-ff-dhe-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: Sat, 28 Mar 2015 19:16:18 -0000 A new version (-08) has been submitted for draft-ietf-tls-negotiated-ff-dhe: http://www.ietf.org/internet-drafts/draft-ietf-tls-negotiated-ff-dhe-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-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. IETF Secretariat. From nobody Sat Mar 28 12:37: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 694241A87F0 for ; Sat, 28 Mar 2015 12:37:28 -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 1eLJ0L45CKYy for ; Sat, 28 Mar 2015 12:37:26 -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 67C141A8A42 for ; Sat, 28 Mar 2015 12:37:26 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 226CA1A25F5; Sat, 28 Mar 2015 21:37:24 +0200 (EET) Date: Sat, 28 Mar 2015 21:37:23 +0200 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20150328193723.GA5974@LK-Perkele-VII> References: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] interop checking for ChaCha20/Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 19:37:28 -0000 On Sat, Mar 28, 2015 at 03:02:27PM -0400, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > And if/when the WG adopts, we might want to ask for early assignment of code > > points. > > I've implemented the drafts in gnutls and created a temporary server which > negotiates the following ciphersuites: > > TLS_RSA_CHACHA20_POLY1305 { 0xCD, 0x30 } > TLS_ECDHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x31 } > TLS_ECDHE_ECDSA_CHACHA20_POLY1305 { 0xCD, 0x32 } > TLS_DHE_RSA_CHACHA20_POLY1305 { 0xCD, 0x33 } > TLS_DHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x34 } > TLS_PSK_CHACHA20_POLY1305 { 0xCD, 0x35 } > TLS_ECDHE_PSK_CHACHA20_POLY1305 { 0xCD, 0x36 } > TLS_RSA_PSK_CHACHA20_POLY1305 { 0xCD, 0x37 } > > If you successfully (or unsuccessfully) checked interoperability drop me a line. Uh, Is this "old" Chacha20-Poly1305 or the "new" one (AEAD #29)? These two compute tags differently. -Ilari From nobody Sat Mar 28 14:04: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 D36EA1A8A57 for ; Sat, 28 Mar 2015 14:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSnKDiscExXQ for ; Sat, 28 Mar 2015 14:04:33 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486F51A8A52 for ; Sat, 28 Mar 2015 14:04:33 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t2SL4MDo018985; Sat, 28 Mar 2015 17:04:23 -0400 Date: Sat, 28 Mar 2015 17:04:20 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Message-ID: <720500104.4267761.1427576660363.JavaMail.zimbra@redhat.com> In-Reply-To: <20150328193723.GA5974@LK-Perkele-VII> References: <969A9DF8-707D-4842-AABE-672356397490@ieca.com> <627F7B4B-32B5-4A5E-9C8A-D98CDCDBD471@gmail.com> <1115333675.4261811.1427569347574.JavaMail.zimbra@redhat.com> <20150328193723.GA5974@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [94.112.138.148, 10.5.101.182] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: interop checking for ChaCha20/Poly1305 Thread-Index: yfVQ6HnQ+hjhYr9RJ0aq8yBk5bWDpw== Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] interop checking for ChaCha20/Poly1305 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Mar 2015 21:04:35 -0000 ----- Original Message ----- > Uh, > Is this "old" Chacha20-Poly1305 or the "new" one (AEAD #29)? > These two compute tags differently. It follows the latest drafts: http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-04 https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-10 regards, Nikos From nobody Sat Mar 28 23:04: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 5668F1A9240 for ; Sat, 28 Mar 2015 23:04:53 -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 EOfWhJdhIQQ7 for ; Sat, 28 Mar 2015 23:04:52 -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 D71981A924B for ; Sat, 28 Mar 2015 23:04:51 -0700 (PDT) Received: by qgep97 with SMTP id p97so164747626qge.1 for ; Sat, 28 Mar 2015 23:04: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=Fs8jAMqsfcUpeyQSTM6S9SofELAHwztb69LsG2ve6AQ=; b=rIuqjJIK/p2r3GxYd98F66T4xTfDcAoCaWDKIMI8EgrIdECItz5ZF58el/lj4XwdHt ntdOlLBtOFLL0teZtqEJujuIdTZA6fwWvt0di8t813lhHxhnFQp4gcD89m9ER8TQYMrX tkWHI55dBnU0vvRe4wumUQx3AxK+QDEgex+BNCyFGNzU+aAf8+X0912NhqI0ZtJZ4gvE 6+eFL1GoViqfQRbcHEtqTmbNT+KoPxOoGsFcEk3nmatu60LLHIIaevc7dvkwjg4yS7+e uSsX7xgrQ+cJUK6Lo7UQ8TzsoOsM+YaTm6BMQQEig+mkGKzDo5gVR/LUhA8wArA6x1db VS7Q== X-Received: by 10.140.146.68 with SMTP id 65mr35519207qhs.101.1427609091155; Sat, 28 Mar 2015 23:04:51 -0700 (PDT) Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id g51sm5184690qgg.23.2015.03.28.23.04.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 28 Mar 2015 23:04:50 -0700 (PDT) From: Dave Garrett To: "tls@ietf.org" Date: Sun, 29 Mar 2015 02:04:49 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; ) References: <201503260330.43588.davemgarrett@gmail.com> <201503272253.30495.davemgarrett@gmail.com> In-Reply-To: <201503272253.30495.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201503290204.49549.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] New TLS version negotiation mechanism extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 06:04:53 -0000 After rewriting the list based approach, I think it really is the best way forward. I've updated my WIP branch. It's simpler and far more thorough than the prior drafts. https://github.com/davegarrett/tls13-spec/compare/patch-3...davegarrett:EVN This simplifies the handling of backward capable version negotiation and does everything through the extension. I think it's overall easier to follow in comparison to the other approach, or the prior spec. I think that by requiring implementations to switch over to a general list comparison approach and drop their old logic, this can create a far more reliable process. (the basic list comparison mechanism is done for plenty of other areas in TLS) Note that the little pseudocode bit is really only there to point out the simplicity. It's probably not needed. Dave From nobody Sun Mar 29 04:06: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 1DFDC1A6EE1 for ; Sun, 29 Mar 2015 04:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, 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 bsnmek-uzHzL for ; Sun, 29 Mar 2015 04:06:50 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 F01201A3B9F for ; Sun, 29 Mar 2015 04:06:49 -0700 (PDT) Received: by labe2 with SMTP id e2so98659269lab.3 for ; Sun, 29 Mar 2015 04:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4G537qTdk11w65mDhPFQU87YWX0nPj4tZ3zaAfIScG4=; b=L1dA89C1PGfssfDLqKzHJHRP5bAqHXbQ7hXJiSu9BhkdJX36U8MM3yxE9a8DowZScp ycZQopc7ikZ5FREcmEvaYa+AqrtKomGMm5+GxPJORzb408SdQVu9WXypYesvYcBaUeOf tYZUN40gLTJk0N/J1oMnjbbsC69hGkYZjVzO5Nq8u5vqpq/76G8YQKUfVc6S6ROOk0um VnSciP9neJgo2MzkUMr+1jXOz6SYQH+9Im/0WLlFn3f62gQ/iWWVIycDWf0csfABNUww NQIW0OrwXI0t02tB+Y8Ese6Bt3lrqQHPsM4ebtCtRJPiQsQEYKmYTxWqpI+U/sA0RqHX 1m8A== X-Gm-Message-State: ALoCoQk3sk9PfkNicsAsWXEJdfwNgWzOsg3fdd8f48RlP8pBQBpL0XhgHQEggwBKPfkLYg6pbFIj MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr24844298lab.20.1427627208416; Sun, 29 Mar 2015 04:06:48 -0700 (PDT) Received: by 10.25.143.4 with HTTP; Sun, 29 Mar 2015 04:06:48 -0700 (PDT) X-Originating-IP: [190.247.34.93] In-Reply-To: <55124CC3.80708@shiftleft.org> References: <55124CC3.80708@shiftleft.org> Date: Sun, 29 Mar 2015 08:06:48 -0300 Message-ID: From: Sergio Demian Lerner To: Mike Hamburg Content-Type: multipart/alternative; boundary=001a11c3540ca134d205126b5c77 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 11:06:53 -0000 --001a11c3540ca134d205126b5c77 Content-Type: text/plain; charset=UTF-8 Yes, you're right that the MAC construction in GCM allows the key owner to find colissions. I was thinking that the auditing mode would be used in combination with an emulated AEAD mode, such as AES_CBC + HMAC. Best regards, Sergio. On Wed, Mar 25, 2015 at 2:50 AM, Mike Hamburg wrote: > Hi Sergio, > > It is worth noting that MAC functions are not generally strong enough > here. For one thing, the MAC is meaningless to a party who doesn't know > the key. But even if you reveal the key afterwards, unless you're using a > sufficiently long HMAC mode, a party who knows the key can probably find a > message with the same MAC value. > > Cheers, > -- Mike > > > On 03/24/2015 08:09 PM, Sergio Demian Lerner wrote: > > Hi, > This is my first post to this mailing list and I if I break some > prestablished rule, I apologize in advance. > > One of our clients requires the notarization of TLS sessions. One > interesting application I found is the TLSNotary project, but it only > partially solves this problem: is only allows auditing a single stream > direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers > considerably the protocol security. Of course he wants transparent > notarization for eavy website, not a higher-level protocol provided by a > website on purpose, and this is completely logical and coherent with the > attributes of a notary. > > I would be interesting if TLS 1.3 could allow optional and easy > notarization of the streams. TLS 1.3 has eliminated renegotiation, which > may be a bulding block for notarization, so I hope in incorporates another > way of providing that functionality. > > For example: if every MAC computed included the the MAC digest of each > previous message sent in that stream, then a single signature of the last > MAC would be enought to validate one of the streams. Or in AEAD > terminology, every packet payload additional_data would include the > authentication tag of the previous packet. > > If key renegocitation is allowed, then a renegotiation done by a third > party after a protocol interaction would be enought to notariaze all > previous interactions. > > To get a join notarization of both streams, TLS in notarization could add > a new message GetMAC that should be responded with the message SendMAC, > containing the sequence number and MAC of the the last packet decrypted in > the other stream (client->server). Since the MAC on one stream would > contain the previous packet MAC digest, then the MAC sent with sendMAC > would provide a MAC validating both streams (client->server and > servcer->client) > > A full communication would be > > Client Server > > ClientHello --------> > (client specifies a NOTARY extension somehow) ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > Now the client gives the notary the control of the streams. > > The server does a renegotiation to obtain a signature of the > > previuously sent data. > > > Notary tunneled over Client Server > > ClientHello --------> > ServerHello > ..... > [ChangeCipherSpec] > Finished --------> > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > getMAC --------> > > <-------- sendMAC > > > This "notarization" can only convince the notary of the encrypted > information exchange, but cannot convince a third party. Also it gives the > notary some control over the streams. So better than this would be that > instead of getMAC/sendMAC there can be two messages > getSignature/SendSignature that send a digitally signed MAC using a > server's pubkey, instead of only the MAC. > > Another option is that in notarization mode, each MAC sent would include > the nseq and the MAC of the last packets received/sent of both streams. > Then an exact reproduction of the message interaction would be available > for notarization, but the seq_num of the opposed stream would need to be > transmitted in the header or encrypted in the payload (it cannot be part of > the additional_data because it is not known to the client, because of the > delay of the network) > > In AEAD terminology the first idea would be done by modifying the > additional_data: > > additional_data = seq_num +* prev_authentication_tag* + > TLSPlaintext.type + > TLSPlaintext.version > > while the second would be: > > > additional_data = seq_num + *prev_authentication_tag + > opposite_stream_prev_authentication_tag* + > TLSPlaintext.type + > TLSPlaintext.version > > Again, this would be an optional mode, orthogonal with ciphersuite > chosen, extensions, etc. > > I hope you find this extension as usefull as we do. Last, we have > several use cases for key renegotiation, and it's a pity it will be > excluded from TLS 1.3. I will present my arguments in another e-mail. > > Best regards, > > -- > Sergio D. Lerner > Cryptocurrency Security Auditor > Coinspect.com > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > -- Sergio D. Lerner Cryptocurrency Security Auditor Coinspect.com --001a11c3540ca134d205126b5c77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, you're right that the MAC construction = in GCM allows the key owner to find colissions. I was thinking that the aud= iting mode would be used in combination with an emulated AEAD mode, such as= AES_CBC + HMAC.

Best regards,
=C2=A0Sergio.

On Wed, Mar 25, = 2015 at 2:50 AM, Mike Hamburg <mike@shiftleft.org> wrote:
=20 =20 =20
Hi Sergio,

It is worth noting that MAC functions are not generally strong enough here.=C2=A0 For one thing, the MAC is meaningless to a party who doesn't know the key.=C2=A0 But even if you reveal the key afterwar= ds, unless you're using a sufficiently long HMAC mode, a party who know= s the key can probably find a message with the same MAC value.

Cheers,
-- Mike


On 03/24/2015 08:09 PM, Sergio Demian Lerner wrote:
Hi,
This is my first post to this mailing list and I if I break some prestablished rule, I apologize in advance.
One of our clients requires the notarization of TLS sessions. One interesting application I found is the TLSNotary project, but it only partially solves this problem: is only allows auditing a single stream direction, is is not compatible with TLS 1.2 nor 1.3 and it lowers considerably the protocol security. Of course he wants transparent notarization for eavy website, not a higher-level protocol provided by a website on purpose, and this is completely logical and coherent with the attributes of a notary. =C2=A0

I would be interesting if TLS 1.3 could allow optional and easy notarization of the streams. TLS 1.3 has eliminated renegotiation, which may be a bulding block for notarization, so I hope in incorporates another way of providing that functionality.
=C2=A0
For example: if every MAC computed included the the MAC digest of each previous message sent in that stream, then a single signature of the last MAC would be enought to validate one of the streams. Or in AEAD=C2=A0 terminology, ever= y packet payload additional_data would include the authentication tag of the previous packet.=C2=A0

If key renegocitation is allowed, then a renegotiation done by a third party after a protocol interaction would be enought to notariaze all previous interactions.

To get a join notarization of both streams, TLS in notarization could add a new message GetMAC that should be responded with the message SendMAC, containing the sequence number and MAC of the the last packet decrypted in the other stream (client->server). Since the MAC on one stream would contain the previous packet MAC digest, then the MAC sent with sendMAC would provide a MAC validating both streams (client->server and servcer->client)

A full communication would be 
      Client                                               S=
erver

      ClientHello                  -------->
      (client specifies a NOTARY extension somehow)        ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      Now the client gives the notary the control of the str=
eams.

      The server does a renegotiation to obtain a signature =
of the=20

      previuously sent data.


      Notary tunneled over Client                     Server

      ClientHello                  -------->
                                                      ServerHello
      .....
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

      getMAC                       -------->

                                   <--------     sendMAC

This "notarization" can only convi= nce the notary of the encrypted information exchange, but cannot convince a third party. Also it gives the notary some control over the streams. So better than this would be that instead of getMAC/sendMAC there can be two messages getSignature/SendSignature that send a digitally signed MAC using a server'= s pubkey, instead of only the MAC.

Another option is that in notarization mode, each MAC sent would include the nseq and the MAC of the last packets received/sent of both streams. Then an exact reproduction of the message interaction would be available for notarization, but the seq_num of the opposed stream would need to be transmitted in the header or encrypted in the payload (it cannot be part of the additional_data because it is not known to the client, because of the delay of the network)

In AEAD terminology the first idea would be done by modifying the additional_data:
 additional_data =3D seq_num + prev_aut=
hentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version

while the second would be:

=C2=A0
 additional_data =3D seq_num + prev_authentication_tag +
                    opposite_stream_prev_authentication_tag +
                    TLSPlaintext.type +
                        TLSPlaintext.version
Again, this would be an optional mode, orthogonal with ciphersuite chosen, extensions, etc.

I hope you find this extension as usefull as we do.=C2=A0 Last, we have several use cases for key renegotiation, and it's a pity it will be excluded from TLS 1.3. I will present my arguments in another e-mail.

Best regards,

--
Sergio D. Lerner
Cryptocurrency Security Auditor
Coinspect.com 


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




--
Sergio D. Lerner
Cryptocurrency= Security Auditor
Coinspect.com
--001a11c3540ca134d205126b5c77-- From nobody Sun Mar 29 04:33: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 2D0B51A7007 for ; Sun, 29 Mar 2015 04:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6azfHW4NKM3 for ; Sun, 29 Mar 2015 04:33:56 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC031A7004 for ; Sun, 29 Mar 2015 04:33:55 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id C5AC981810; Sun, 29 Mar 2015 14:33:52 +0300 (EEST) Date: Sun, 29 Mar 2015 14:33:52 +0300 From: Ilari Liusvaara To: Sergio Demian Lerner Message-ID: <20150329113352.GA25692@LK-Perkele-VII> References: <55124CC3.80708@shiftleft.org> 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] Renegotiation and TLSNotary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 11:33:58 -0000 On Sun, Mar 29, 2015 at 08:06:48AM -0300, Sergio Demian Lerner wrote: > Yes, you're right that the MAC construction in GCM allows the key owner to > find colissions. I was thinking that the auditing mode would be used in > combination with an emulated AEAD mode, such as AES_CBC + HMAC. Maybe I don't quite understand what this is about, but doing certain things with partial key disclosure requires running two MACs. Perhaps this is one of those[1]? The issue there is that the main MAC key must be assumed to be the same as encryption key, so one needs a second MAC that one can disclose key for. [1] The first such thing I ran into was escrow decryption, where one needs an inner MAC to prevent tampering. -Ilari From nobody Sun Mar 29 11:55: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 2E5B41A802E for ; Sun, 29 Mar 2015 11:55:45 -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 b23F-Rh0DDXl for ; Sun, 29 Mar 2015 11:55:43 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c: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 881111A702C for ; Sun, 29 Mar 2015 11:55:43 -0700 (PDT) Received: by wicne17 with SMTP id ne17so6247649wic.0 for ; Sun, 29 Mar 2015 11:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SbLlX9h3FTYmKPmbhWv97/FSLLhPCZvvNdsuYEU8Mfw=; b=jW5MME/KKCT1kjWf5Bt/zDdINUkOYSb1chsBTCdtNHjJXeKCU7tOXWxPwcH62OBOKx 8Kun9OIhE6rxWkSGrz/ajEkq5s0ND6+Ie50XDnGHO3LQQny39b+ppu4V5SlMPUJfPhH2 Xvy3pt+QX/AWdfHSd0h85w00Pv3cJM0gg/I2GGK9jIA2TE0H7Aq+fZxGGzBORcCVeo66 1v+jXh6twjbdOClZS4z9mYw4Dh3zZ8ZvND+ACyGsVi1DvOgn+yiB+1/VbJLrok6Ek1hi +Z+T6Hg5rZTLayfUTXbaQDzans0D8RZqFnCqKhtYoMWO6HbKi+QA+Ct9XAS7LTNW5+Me vaYw== MIME-Version: 1.0 X-Received: by 10.180.80.101 with SMTP id q5mr15445330wix.83.1427655342197; Sun, 29 Mar 2015 11:55:42 -0700 (PDT) Received: by 10.194.136.233 with HTTP; Sun, 29 Mar 2015 11:55:42 -0700 (PDT) In-Reply-To: <55141DF4.2070906@nthpermutation.com> References: <20150326072440.GB6108@LK-Perkele-VII> <55141DF4.2070906@nthpermutation.com> Date: Sun, 29 Mar 2015 11:55:42 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] HKDF X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 18:55:45 -0000 On Thu, Mar 26, 2015 at 7:55 AM, Michael StJohns wrote: > On 3/26/2015 3:24 AM, Ilari Liusvaara wrote: >> >> Turns out you can't even implement TLS fully in design that does not >> know about TLS, > > > This is true for TLS1.2 and before, mainly because of the master secret > expansion and the PRF. Everything else is bog standard crypto. > >> nor does it seem one can even change TLS so that >> would be possible (at least without introducing gaping security holes). > > > I don't know that I believe that. TLS is a protocol wrapped around a set of > cryptographic constructs. There are ways to use standard constructs in TLS > to build a secure protocol. It will require some surgery on TLS1.2, but I > think that's well underway. It depends on what the guaranties of the crypto module are. If you provide AES-GCM, then you need a mechanism to ensure nonces aren't repeated, and that won't be generic. Sincerely, Watson Ladd > > Mike > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Mar 30 07:59: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 CDBF51AC414; Mon, 30 Mar 2015 07:58:59 -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 nFDWYIt5o6Mw; Mon, 30 Mar 2015 07:58:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 440581AC3EA; Mon, 30 Mar 2015 07:58:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150330145858.27263.63450.idtracker@ietfa.amsl.com> Date: Mon, 30 Mar 2015 07:58:58 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] Last Call: (Transport Layer Security (TLS) Session Hash and Extended Master Secret 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, 30 Mar 2015 14:59:00 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) Session Hash and Extended Master Secret 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-04-13. 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 The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ballot/ No IPR declarations have been submitted directly on this I-D. ID-NITs says this uses "NOT RECOMMENDED" but that that's not called out as a term. We'll fix that. From nobody Mon Mar 30 12:01: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 026A51AC3F9; Mon, 30 Mar 2015 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMEZLyi6Q1Ns; Mon, 30 Mar 2015 07:59:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 931841AC40D; Mon, 30 Mar 2015 07:58:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150330145859.27263.22511.idtracker@ietfa.amsl.com> Date: Mon, 30 Mar 2015 07:58:59 -0700 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Mon, 30 Mar 2015 12:01:21 -0700 Subject: [TLS] ID Tracker State Update Notice: 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, 30 Mar 2015 14:59:12 -0000 Last call has been made for draft-ietf-tls-session-hash and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ From nobody Mon Mar 30 16: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 510241A87D9; Mon, 30 Mar 2015 16:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 MOI7R80mDaLU; Mon, 30 Mar 2015 16:05:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B66AF1A882E; Mon, 30 Mar 2015 16:05:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 09F3A18046C; Mon, 30 Mar 2015 16:05:14 -0700 (PDT) To: pgut001@cs.auckland.ac.nz, pgut001@cs.auckland.ac.nz X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150330230514.09F3A18046C@rfc-editor.org> Date: Mon, 30 Mar 2015 16:05:14 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Verified] RFC7366 (4212) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 23:05:23 -0000 The following errata report has been verified for RFC7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7366&eid=4212 -------------------------------------- Status: Verified Type: Technical Reported by: Peter Gutmann Date Reported: 2014-12-27 Verified by: Stephen Farrell (IESG) Section: 3 Original Text ------------- In TLS [2] notation, the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + ENC(content + padding + padding_length)); and for TLS 1.1 and greater with an explicit IV is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + TLSCipherText.length + IV + ENC(content + padding + padding_length)); Corrected Text -------------- Note that the length value used for the MAC computation differs from the value of the 'uint16 length' field in the TLSCiphertext record as encoded on the wire. The encoded TLSCiphertext record contains both the ciphtertext and the MAC, while the MAC calculation is performed only over the ciphertext. The length value encoded in the TLSCiphertext record is therefore 'length' while the length value used in the MAC calculation is 'length - SecurityParameters.mac_length'. More formally, if: TLSCiphertext.enc_content = ENC(content + padding + padding_length) then in TLS notation the MAC calculation for TLS 1.0 without the explicit Initialization Vector (IV) is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (TLSCiphertext.enc_content) + TLSCiphertext.enc_content); and for TLS 1.1 and greater with an explicit IV is: MAC(MAC_write_key, seq_num + TLSCipherText.type + TLSCipherText.version + length of (IV + TLSCiphertext.enc_content) + IV + TLSCiphertext.enc_content); Notes ----- After the RFC was published a new set of implementers (who hadn't been part of the pre-publication interop testing) pointed out that the text covering the use of length values could be interpreted in two different ways. This correction attempts to remove the ambiguity by making explicit what's MACd vs. what's encoded on the wire. -------------------------------------- RFC7366 (draft-ietf-tls-encrypt-then-mac-03) -------------------------------------- Title : Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Publication Date : September 2014 Author(s) : P. Gutmann Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Mar 30 16:06: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 26FAF1A87D9; Mon, 30 Mar 2015 16:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 wt7F1SHc8fGo; Mon, 30 Mar 2015 16:06:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B7F6A1A8894; Mon, 30 Mar 2015 16:06:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0D5E718046C; Mon, 30 Mar 2015 16:06:11 -0700 (PDT) To: dottomi@gmail.com, pgut001@cs.auckland.ac.nz X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150330230611.0D5E718046C@rfc-editor.org> Date: Mon, 30 Mar 2015 16:06:11 -0700 (PDT) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Rejected] RFC7366 (4284) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 23:06:22 -0000 The following errata report has been rejected for RFC7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7366&eid=4284 -------------------------------------- Status: Rejected Type: Technical Reported by: Tomasz Sobczyk Date Reported: 2015-03-02 Rejected by: Stephen Farrell (IESG) Section: 3 Original Text ------------- The overall TLS packet [2] is then: struct { ContentType type; ProtocolVersion version; uint16 length; GenericBlockCipher fragment; opaque MAC; } TLSCiphertext; The equivalent DTLS packet [4] is then: struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; GenericBlockCipher fragment; opaque MAC; } TLSCiphertext; This is identical to the existing TLS/DTLS layout, with the only difference being that the MAC value is moved outside the encrypted data. Corrected Text -------------- The overall TLS packet [2] is then: struct { ContentType type; ProtocolVersion version; uint16 length; GenericBlockCipher fragment; opaque MAC[SecurityParameters.mac_length]; } TLSCiphertext; The equivalent DTLS packet [4] is then: struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; GenericBlockCipher fragment; opaque MAC[SecurityParameters.mac_length]; } TLSCiphertext; This is identical to the existing TLS/DTLS layout, with the only differences being that the MAC value is moved outside the encrypted data and the definition of TLSCiphertext.length changes to: length The length (in bytes) of the following TLSCiphertext.fragment and TLSCiphertext.MAC. The length MUST NOT exceed 2^14 + 2048. Notes ----- MAC array length is missing. Also, the new structure changes the definition of TLSCiphertext.length. As it currently stands, the length of the MAC is excluded from TLSCiphertext.length. This is a duplicate of erratum 4212 which is now verified. --VERIFIER NOTES-- This is a duplicate of erratum 4212 which is now verified. -------------------------------------- RFC7366 (draft-ietf-tls-encrypt-then-mac-03) -------------------------------------- Title : Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Publication Date : September 2014 Author(s) : P. Gutmann Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Mar 31 09: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 B4D501A005B for ; Tue, 31 Mar 2015 09:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1edQbYBiC2kJ for ; Tue, 31 Mar 2015 09:20:03 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.184.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991431A0052 for ; Tue, 31 Mar 2015 09:20:03 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 9F5FAF0251926; Tue, 31 Mar 2015 11:20:02 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 7F527F025184C for ; Tue, 31 Mar 2015 11:20:02 -0500 (CDT) Received: from [96.231.227.6] (port=61308 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YcytV-000198-Ny for tls@ietf.org; Tue, 31 Mar 2015 11:20:01 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Tue, 31 Mar 2015 12:20:00 -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.227.6 X-Exim-ID: 1YcytV-000198-Ny X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:61308 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:20:05 -0000 All, There=92s been some interested expressed in having = http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted = as a TLS WG item. If you would like for this draft to become a WG = document, and you are willing to review drafts as it moves through the = process please indicate as much on this thread. If you are opposed to = this being a WG document, please say so (and say why). Thanks in = advance. J&S= From nobody Tue Mar 31 09:22: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 714151A00B0 for ; Tue, 31 Mar 2015 09:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aj7yMDGb3yBN for ; Tue, 31 Mar 2015 09:22:22 -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 44B7D1A0099 for ; Tue, 31 Mar 2015 09:22:22 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 818ED165899; Tue, 31 Mar 2015 16:22:21 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 77209165893; Tue, 31 Mar 2015 16:22:21 +0000 (GMT) Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 5A9759803E; Tue, 31 Mar 2015 16:22:21 +0000 (GMT) Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com (172.27.123.102) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 31 Mar 2015 12:21:28 -0400 Received: from USMA1EX-DAG1MB2.msg.corp.akamai.com ([172.27.123.102]) by usma1ex-dag1mb2.msg.corp.akamai.com ([172.27.123.102]) with mapi id 15.00.0913.011; Tue, 31 Mar 2015 12:21:28 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart Thread-Index: AQHQa86QUK+mbb92xEKQkFma5HDakp02xbog Date: Tue, 31 Mar 2015 16:21:28 +0000 Message-ID: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> In-Reply-To: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.33.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:22:26 -0000 > If you would like for this draft to become a WG document, and > you are willing to review drafts as it moves through the process please > indicate as much on this thread. +1 From nobody Tue Mar 31 09:34: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 4A00E1A0140 for ; Tue, 31 Mar 2015 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgCE8sTPN_b for ; Tue, 31 Mar 2015 09:34:29 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [64.5.38.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147751A002D for ; Tue, 31 Mar 2015 09:34:29 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id F24DCD1783A40; Tue, 31 Mar 2015 11:34:27 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id E181AD17839C0 for ; Tue, 31 Mar 2015 11:34:27 -0500 (CDT) Received: from [96.231.227.6] (port=61332 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ycz7T-0002KM-9k for tls@ietf.org; Tue, 31 Mar 2015 11:34:27 -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: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Tue, 31 Mar 2015 12:34:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.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.227.6 X-Exim-ID: 1Ycz7T-0002KM-9k X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [96.231.227.6]:61332 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:34:30 -0000 I also meant to add please let us know by 2015-04-14. spt On Mar 31, 2015, at 12:20, Sean Turner wrote: > All, >=20 > There=92s been some interested expressed in having = http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted = as a TLS WG item. If you would like for this draft to become a WG = document, and you are willing to review drafts as it moves through the = process please indicate as much on this thread. If you are opposed to = this being a WG document, please say so (and say why). Thanks in = advance. >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 31 10:27: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 F2D9F1A1B22 for ; Tue, 31 Mar 2015 10:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khWzBTuHscFG for ; Tue, 31 Mar 2015 10:27:25 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (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 AA3D61A03AA for ; Tue, 31 Mar 2015 10:27:25 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2VHROGM028988 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Mar 2015 10:27:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Tue, 31 Mar 2015 10:27:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD5254C-89AA-46EA-BB03-93A250DD5CC7@vpnc.org> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> To: tls@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:27:27 -0000 On Mar 31, 2015, at 9:20 AM, Sean Turner wrote: > There=92s been some interested expressed in having = http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted = as a TLS WG item. If you would like for this draft to become a WG = document, and you are willing to review drafts as it moves through the = process please indicate as much on this thread. If you are opposed to = this being a WG document, please say so (and say why). Thanks in = advance. If the adopted draft becomes clearer that it is for TLS 1.2 (and = possibly 1.1) only, but not for 1.3 (since we don't know what that will = look like), I support its adoption. --Paul Hoffman= From nobody Tue Mar 31 10:52:43 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 9A6101A86E3 for ; Tue, 31 Mar 2015 10:52:41 -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 7nu0q63mMkLn for ; Tue, 31 Mar 2015 10:52:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CCC1A8700 for ; Tue, 31 Mar 2015 10:52:39 -0700 (PDT) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.125.19; Tue, 31 Mar 2015 17:52:36 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0125.002; Tue, 31 Mar 2015 17:52:36 +0000 From: Andrei Popov To: Sean Turner , "" Thread-Topic: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart Thread-Index: AQHQa86UN8vX3a2x/0CC27QImnfUo502yX0AgAAVo0A= Date: Tue, 31 Mar 2015 17:52:36 +0000 Message-ID: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: ieca.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51874003)(24454002)(377454003)(40100003)(77156002)(122556002)(99286002)(19580405001)(2900100001)(107886001)(106116001)(86362001)(15975445007)(2950100001)(62966003)(74316001)(50986999)(19580395003)(76576001)(87936001)(102836002)(92566002)(2656002)(33656002)(230783001)(54356999)(76176999)(46102003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1249; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0532BF6DC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2015 17:52:36.2787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249 Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:52:41 -0000 The draft is useful in that it documents existing practice and provides sec= urity considerations. I support adoption. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner Sent: Tuesday, March 31, 2015 9:34 AM To: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart I also meant to add please let us know by 2015-04-14. spt On Mar 31, 2015, at 12:20, Sean Turner wrote: > All, >=20 > There's been some interested expressed in having http://datatracker.ietf.= org/doc/draft-bmoeller-tls-falsestart/ adopted as a TLS WG item. If you wo= uld like for this draft to become a WG document, and you are willing to rev= iew drafts as it moves through the process please indicate as much on this = thread. If you are opposed to this being a WG document, please say so (and= say why). Thanks in advance. >=20 > J&S > _______________________________________________ > 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 Mar 31 10:53: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 D0C391A86E3 for ; Tue, 31 Mar 2015 10:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEqr85rSPNz0 for ; Tue, 31 Mar 2015 10:53:57 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::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 ED8121A8762 for ; Tue, 31 Mar 2015 10:53:55 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so36684507obb.1 for ; Tue, 31 Mar 2015 10:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sk+7ZZa8ED6mg3wrlMjLacd0wo5GxYNJNCwcJGW65rE=; b=RI7UgEXcVNEn9Tj5WtaM253Aiq14dUaUOLaOvgNvPDhisEjdrTRjazsENxy30TzCJb 3p7y1ttJwQhtCdsuYKzPAZLQiphBm/EtpEs3YB2u858OxkkFv8W310EhBGvbYb7neAKd V/CRPXjHz0ul8/Y1EHQvEMARyAlpG9w7LfptQgGp6sMb7ilZXZlLV2EjlznuZWXUHRz/ rZD8JVjvw5DUwC/rXk0mwVdsHhK5cMs65MRUzd2GZRV5OT99kQJ1F9GLFNIC1V66SHpg adcnQ2pjWa0c2uzf36vrymx3sj5zTlnEc94NHWej/WW7aKXeJHxchSqxnDM5D4zTcI6N Nl4w== MIME-Version: 1.0 X-Received: by 10.60.155.135 with SMTP id vw7mr34918182oeb.62.1427824431027; Tue, 31 Mar 2015 10:53:51 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Tue, 31 Mar 2015 10:53:50 -0700 (PDT) In-Reply-To: References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Tue, 31 Mar 2015 10:53:50 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:53:58 -0000 On 31 March 2015 at 10:52, Andrei Popov wrote: > The draft is useful in that it documents existing practice and provides security considerations. I support adoption. What Andrei said. From nobody Tue Mar 31 11:30: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 1AC721A90A0 for ; Tue, 31 Mar 2015 11:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esN8ZLrjesDW for ; Tue, 31 Mar 2015 11:30:04 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA2001A9059 for ; Tue, 31 Mar 2015 11:29:42 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 504C3F984; Tue, 31 Mar 2015 14:29:39 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7475220286; Tue, 31 Mar 2015 13:29:27 -0500 (CDT) From: Daniel Kahn Gillmor To: Sean Turner , "\" In-Reply-To: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> User-Agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 31 Mar 2015 14:29:27 -0400 Message-ID: <87oan9hvg8.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:30:07 -0000 On Tue 2015-03-31 12:20:00 -0400, Sean Turner wrote: > There’s been some interested expressed in having > http://datatracker.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted > as a TLS WG item. If you would like for this draft to become a WG > document, and you are willing to review drafts as it moves through the > process please indicate as much on this thread. If you are opposed to > this being a WG document, please say so (and say why). Thanks in > advance. I support working group adoption of this draft, since it documents existing practice and addresses a common concern about reducing latency. --dkg From nobody Tue Mar 31 16:56: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 3DE3E1A879A for ; Tue, 31 Mar 2015 16:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J_N-WQlCngf for ; Tue, 31 Mar 2015 16:56:12 -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 842FC1A877B for ; Tue, 31 Mar 2015 16:56:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 736E9BEBB; Wed, 1 Apr 2015 00:56:10 +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 p3fj_o64bRMV; Wed, 1 Apr 2015 00:56:09 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.29.244]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2CFABE50; Wed, 1 Apr 2015 00:56:08 +0100 (IST) Message-ID: <551B3415.5080105@cs.tcd.ie> Date: Wed, 01 Apr 2015 00:56:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "tls@ietf.org" , Daniel Kahn Gillmor OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 23:56:15 -0000 Hiya, I've done my AD review of this, and it's very good. I have two questions I'd like to check on before starting IETF last call. If the answers are already in the list archive, then just pointing there is entirely fine. If not, well, they're not such hard questions:-) #1 Have we tested in the wild that using elliptic_curves (10) in the ClientHello won't trigger some ECC code that causes handshakes to barf? #2 I've never quite gotten the reasoning behind not giving any names to any of the RFC3526 curves and I think that question deserves an answer (to be in the list archive). So - why not? Cheers, S. PS: I also have a bunch of nitty nits, feel free to handle those however is best. - intro: What is "Traditional TLS"? Ye olde something or other? :-) - intro: "p > 1024 bits" is fine by me but better would be to say "p is longer than 1024 bits" - s3, 2nd para: I suggest a para break before you get to the bit about both ECC and DHE. - s3, 3rd para: what is the "these" in here? This reads a bit oddly. - 5.1: "public key" is less common than "public value" I think, when talking about DH. FWIW, I prefer value as saying key confuses some people into thinking this is a long term value. - 5.2: 4419 has a reference to a Paul Van Oorschot paper that justifies the security here. Did we check there are no more recent results? (Esp ones that might invalidate the optimisation.) Could also be good to include whatever is today's best reference for this directly rather than just via 4419. From nobody Tue Mar 31 17:29: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 64E631B2B86 for ; Tue, 31 Mar 2015 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg98IUt95yYU for ; Tue, 31 Mar 2015 17:29:42 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 56A1D1B29C5 for ; Tue, 31 Mar 2015 17:29:42 -0700 (PDT) Received: by obvd1 with SMTP id d1so54533658obv.0 for ; Tue, 31 Mar 2015 17:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Spk5HEb/+eVj+Q5Bk717GH0jwwaPiMw1aVhqDSKHwMM=; b=pyvMwyLugw2fTU+7mRAa5griz/ae3kB3d4k50hzhWlYJeWbOvZReBiFdPM9cqKZ0CF J+nL8ukmu/m6Wv5JhDn3cFwbmQdTXoXFdZEYy0MxHu8zIwLdkKvw6vl32qyxQYOt5+Qu KkqtvqrFDHU/B5bD41DgVjfWrHahHzpudIJ3bM+01KzTMP4BFE8eiHCgpR5L0kAd8heL NcqyY+BMmR/pkWzv32q5jSmlsKxSC+lOjELuLThugEQY6LHKUfreK051h5ndaDnIQoBR ycwQytUJdMsxgedU7QvZ5n/ljyZ3mRZMnKCBeiNMTKcv04j8ukaOXjWy6+UKksY90Trt iHew== MIME-Version: 1.0 X-Received: by 10.60.244.165 with SMTP id xh5mr12436613oec.43.1427848181848; Tue, 31 Mar 2015 17:29:41 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Tue, 31 Mar 2015 17:29:41 -0700 (PDT) In-Reply-To: <551B3415.5080105@cs.tcd.ie> References: <551B3415.5080105@cs.tcd.ie> Date: Tue, 31 Mar 2015 17:29:41 -0700 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 00:29:43 -0000 On 31 March 2015 at 16:56, Stephen Farrell wrote: > #1 Have we tested in the wild that using elliptic_curves (10) > in the ClientHello won't trigger some ECC code that causes > handshakes to barf? Firefox sends the supported_curves extension in every handshake and so do most browsers. So for those, the risk of intolerance is obviously quite low. That's not hard numbers obviously, but that's a lot of ClientHello messages with the extension. From nobody Tue Mar 31 19:33: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 9DE701A066C for ; Tue, 31 Mar 2015 19:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_2EYJ9fNOtp for ; Tue, 31 Mar 2015 19:33:38 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.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 16F5A1A00E5 for ; Tue, 31 Mar 2015 19:33:38 -0700 (PDT) Received: by obvd1 with SMTP id d1so58186842obv.0 for ; Tue, 31 Mar 2015 19:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q4stnLKNQ3ivl4grI+8tv/E7tHBF1aEvKI5gsRTPhgU=; b=IL8jUXS89Z33UBY5NLO80ORNDciW+d+YL/UJfPITvb51wZqw/EJ9dDjGFoiU/j3M1H 2d5n5EfQrhW1ApxwRtIOvTpIB49PYDqlSlcTROUZkiWSUTyGBnYinGoGQbbKCyZqd+oC Aik/lriGcw2BkNcQjI9iNWLzOfZjhjA7EyrgOSDnCZGwBtozNyBbW3U5M1Pa/rNw3UIV qBWuvRQeiHu/aNY7a7ymTTECoL3EH1HRr+oDX9w+N5IKQ9CCg8fL6peWbAPBpxyv+Nfg t/OKPHIgzev2KK4PJDxbUNNS61epD3zkrJo0DaLMT690TfXSIVZIm75wCuYO7KPCpyOy JLuQ== X-Gm-Message-State: ALoCoQlN4N80WNDvog+Uvumoimpwmc7D00JZIGdPtHVOkHFLFUpLXb6zgDUoIxdmrXHPRAMo6ChA MIME-Version: 1.0 X-Received: by 10.60.35.102 with SMTP id g6mr37562310oej.7.1427855617438; Tue, 31 Mar 2015 19:33:37 -0700 (PDT) Received: by 10.76.20.146 with HTTP; Tue, 31 Mar 2015 19:33:37 -0700 (PDT) In-Reply-To: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> References: <813475A8-DC71-42BA-A27E-DF11B0155FD1@ieca.com> Date: Tue, 31 Mar 2015 16:33:37 -1000 Message-ID: From: Brian Smith To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 02:33:39 -0000 Sean Turner wrote: > There=E2=80=99s been some interested expressed in having http://datatrack= er.ietf.org/doc/draft-bmoeller-tls-falsestart/ adopted as a TLS WG item. I= f you would like for this draft to become a WG document, and you are willin= g to review drafts as it moves through the process please indicate as much = on this thread. If you are opposed to this being a WG document, please say= so (and say why). Thanks in advance. I support adopting a new version of this draft that has made the following changes: 1. The server-side False Start section is removed. I don't think it has received enough scrutiny and it isn't worth the working group's time to study and/or fix it. 2. The reference to TLS_FALLBACK_SCSV is removed and replaced with a requirement that False Start is to be done only for TLS 1.2--not earlier versions, and not later versions. As of Firefox 36, Firefox only does false start for TLS 1.2 [1][2][3]. Google Chrome will be doing similar soon [2], AFAICT for similar reasons to Firefox. 3. The text about doing False Start when sending client certificates is removed. Not only is it not worthwhile as a performance optimization, the whole idea of sending the client certificate in the clear at all is a terrible idea that shouldn't be encouraged. (Firefox has never done False Start when it sends a client certificate; I am not sure about other implementations.) 4. The references to (FF-)DHE key exchange being acceptable for False Start are removed. Although it may be possible to safely implement False start for FF-DHE, the current draft isn't a good starting point for specifying how that might be done. It's better to remove the references until an adequate description of doing False Start for FF-DHE key exchange is available, if ever. I believe we would save a lot of time if we adopted a draft that incorporates these changes, instead of adopting the current draft and then attempting to make these changes within the WG process. In particular, these changes usefully reduce the scope to what is generally understood to be safe and useful. Cheers, Brian [1] https://bugzilla.mozilla.org/show_bug.cgi?id=3D861310 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=3D952863 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=3D1109766 [4] https://code.google.com/p/chromium/issues/detail?id=3D427721 From nobody Tue Mar 31 21:27: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 CFDC21A8790 for ; Tue, 31 Mar 2015 21:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SCWdz0aEhone for ; Tue, 31 Mar 2015 21:27:34 -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 AD4DB1A878E for ; Tue, 31 Mar 2015 21:27:34 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 37D112AC42; Wed, 1 Apr 2015 06:27:31 +0200 (CEST) X-purgate-ID: 152705::1427862452-000007DF-6C5D491D/0/0 X-purgate-size: 1014 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 Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 468B9432C1; Wed, 1 Apr 2015 06:27:31 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 403F61B256; Wed, 1 Apr 2015 06:27:31 +0200 (CEST) In-Reply-To: To: Martin Thomson Date: Wed, 1 Apr 2015 06:27:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20150401042731.403F61B256@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08 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, 01 Apr 2015 04:27:37 -0000 Martin Thomson wrote: > Stephen Farrell wrote: >> >> #1 Have we tested in the wild that using elliptic_curves (10) >> in the ClientHello won't trigger some ECC code that causes >> handshakes to barf? > > Firefox sends the supported_curves extension in every handshake and so > do most browsers. So for those, the risk of intolerance is obviously > quite low. That's not hard numbers obviously, but that's a lot of > ClientHello messages with the extension. I think Stephen might have meant something else. RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.): https://tools.ietf.org/html/rfc4492#section-4 The client MUST NOT include these extensions in the ClientHello message if it does not propose any ECC cipher suites. and the above requirement seems to prohibit a non-ECC client from using the named FFDHE parameters through the ECC named curve extension _without_ accompanying ECC cipher suites. -Martin